Wiki Home

Stack Stuff


Namespace: WIN_COM_API
THE difference between a normal app calling functions etc., and a web-enabled app using HTML, is the stack not being really there in the latter; while the normal app has and uses (!) a hierarchy in it's functionalities. Instrinsically, a web-enabled app can only simulate this by "go to" HTML pages. A real OO-app may behave the same as a web-enabled app because of the event-driven stuff, but when this OO-app really behaves like this, all functionality is -at least virtually- on a one level hierarchy. This is exactly why OO is not really suitable for apps with thousands of functions; if they all operate on this same hierarchical level, they can't be found by the user. Therefore some hierarchy must be applied, which doesn't completely satisfy the definition of OO. Now, looking at some real web-enabled apps (like amazon.com), you'll see that somewhere such an app switches from the usual browser behaviour to "normal" app behaviour being hierarchical. Just try it, and you see what I mean.
This is not any scientific statement, but my own thoughts. Who else ? -- Peter Stordiau

I agree: I think that we usually refer to this design principal as "modality", or having "state" (as opposed to "statelessness"). Desktop applications usually involve states or modes of operation. Though event-driven window-based (whether Macintosh&tm; windows, or Microsoft Windows&tm;) are increasingly becoming more stateless (or "less stately" ;), they still have certain places where a "mode" is forced within the application, such as "Print Preview", or any modal dialog box, or editing "Headers and Footers".

Comparing this to web pages, the web is basically modeless; However one could easily argue that web applications are more modal than desktop applications: since all the nice widgets of pull down menues, popup calendars, toolbars and other such screen realestate saving controls, it would take several modal pages to accomplish something that in a desktop application may have been just a few clicks. This is because, without employing more difficult and complex technologies, a normal web page is really just a modal view, nothing you do to the page affect the server until you continue on to the next modal web page. This limitation is basically the driving force behind the Fat Client design model of MicrosoftDotNet. - ?wgcs

I'm not sure where you are coming from Peter, I agree with what wgcs has written here, so maybe I agree with you. But I feel like there is a bit of irrational OOP paranoia mixed in with your original statement. IMO, whether or not an app is stateful or not is completely orthogonal issue to whether it utilizes OOP techniques. It's not that: "OO is not really suitable for apps with thousands of functions", rather the point is, if you use OOP techniques, you don't focus on the functions, rather you focus on the entities that make up the application and the relationships between them. Sure, when you are done, you probably won't have thousands of UDF's but that's the whole idea behind OOP, the functions are encapsulated into classes that represent components in the application (at some level of granularity or other). OOP can be very hierarchical, (inheritance is a hierarchy) it all depends what you want to do. Having said that, I agree that there are times when a simple UDF is the most pragmatic way to go. That's one of the cool things about VFP you can pick your weapon. - ?lc

[2001.05.07 07:54:45 AM EST]
Lauren,

For argument's sake or interest only (for sure mine) I'll try to explain. And please remember I don't want to be right on this, but just wonder since I do come from this other world indeed, which allways was and will be the world of pioneers; Overhere we all do things the other way (around), originating from being too early for the (known) techniques available. Excuse me for -just therefore- not being able to express the things how they should, maybe leading to the implying of not ment things litterally.

From the beginning (OO was invented but hardly used) we designed our functions as real independed objects; we even called them like that. Since this was in FP2 of course technically they were not. Functionally however they were, even with the inheritance of data. Look at this as of each function technically being able to call any other at user's will. Thus, define the retrieval of Items as to be called by the press of Alt-I and when being in the adding of a Sales Order, Item Retrieval is brought forward. The Alt-I (defined by the user) was NOT treated as an event, though in FP2 this could have been the case (in FoxBase this wasn't possible).

Now with the above as a given fact, maybe you can start to understand why it is legitimate to think as we think here : The (data manipulation) functions were and are "object" already, and the event-stuff was already treaded like nowadays already. What better starting-point could there be to make all real-objects and let all be real event-driven. So, this was the basis for leaving the functional programs as they were, and writing an OS on top of them;
When I express my thoughts on subjects like this, of course I have this in / on my mind.

An app which originated from procedural coding, is highly hierarchical oriented, not being able to be stateless. Well, usually it isn't. However, thinking of the Alt-I example, with us it just is. I only want to make clear that we have the experience on this from long ago and ... now we can compare, also having the expercience on the real object-stuff. An example :

Looking at the W95 Startbutton, this is a great "feel" functionality for the user to explore the functionalities of a bigger system; just move the mouse and view all the menu-options very quickly. However, once you are somewhere (!) in an interesting branche and click a function to activate, your hierarchy has gone. And yes, the Start-menu object is (appears to be) separated from the activated object, and if you wish to go back to the lastly shown menu of the Start-menu, you have to start all over again. I suppose you know/feel what I mean.
We created this Start-menu class ourselves, and believe me, you can move your mouse a whole day around, to explore all menu's, without activating even one function. So that's how it is, and that is the big app;
Now in order to not only let the users explore the functionalities, but also to let them really use the functionalities, we created this small amendment to the normal W95 Start-menu : just let the menu-hierarchie lastly activated sit there, in order to "go back where you were". I can rephrase this by stating that this was an amendment to the normal modal - modeless behaviour of things (not exactly right, but you know what I mean);

Many Win-applications get me sick of not enabling me to go back where I came from. And yes, of course it is possible to enable this, but it takes much more effort to achieve this (by the developer).
Now IMO this has all been created by the nature of OOP, which is all too easy to activate an object (function), but just not knowing where it came from, not to speak of where to go back to;
IMO objects are there to be independent, and just not te be dependend on other objects. True or not ?!
Therefore there should be some hierarchycal layer that controls this when needed (when not needed, it's just not there - ref. your weapon). Now what is needed is in the business rules, and not in any technical thing;
When I make our app web-enabled, and just convert our forms to HTML and give it to the user, firstly my beautiful layer is still there, but the hyperlinks and back-buttons (and even forward buttons !) have their own rules, which conflict with mine. BTW this is exactly why the ha ha ha program in Click Here To Understand Recursion doesn't work by itself (I mention this in order to make even more clear what I mean).

Therefore my statement : let OO be OO as it was ment for, and you end up with users not knowing where they are or were, which only occurs on bigger systems. The latter is crucial ! First rule therefore is enabling a user to go back where he came from automatically. And that's the stack;
Directing the user where he's allowed to go to at any point in a process, is killing yourself by trying to apply this in class-hierarchies and inheritance rules which were so beautiful consistently implemented in the beginning;
If I may : Anyone who thinks that these consistent rules can be designed from the beginning and remain unadjusted, is too opportunistic or just doesn't know (what a big system is to this repect). Sorry.
I myself come from the world where the functionalities were a given fact, and afterwards the classes were designed on top of that. IOW I knew exactly what the dynamics were and should be for the future; since I also know the history, I am 100 % sure what would have gone wrong when the OO-stuff was designed from scratch.
And please beware, right at this moment there is not any single ERP package (being the biggest existing apps) existing which was created from cratch in OO. However, there exists -as far as my knowlegde goes- one being real OO apart from ours, and those guys did it the same as we did. No, this doesn't proove I am right at all, and I still don't want to be. But maybe, just maybe this world is a little different ...

-- Peter Stordiau

I'm sorry Peter, I just don't have the time to read all that, but a quick glance tells me you and I have some fundamental differences in our perceptions of how good software is designed and implemented. That's ok, but I'm thinking us hashing them out here in a low signal-to-noise conversation is not a very efficient use of the wiki. - ?lc
Agreed Lauren, over-and-out. -- Peter Stordiau
( Topic last updated: 2001.05.07 11:39:55 AM )