I'm gonna get shot down in flames here, but I feel this may be a good way of looking at the differences between static and non-static methods.
If you look at the compiled code for any OO language at the bytes in memory level, you can clearly see the differences between the two. When a compiled program is loaded into memory, three (four) clearly defined areas are seen. [Cut down a bit as there are other areas, specific to the language used, see last paragraph (The one starting "Of-course...", not "Hope this ...")] The First (including the fourth :-) is the program byte code (and the start code, which is hit first when the program starts and is specific to your machine) which contains all your code. The second and third parts are the stack and heap which will hold all the data at run time. The difference in static and non-static in this layout is thus. ALL static classes, methods and variables remain within the byte code section and are run directly from there (and this is the reason static methods cannot be overridden but only hidden). Hidden static methods will reside here even if never called (and this is the reason static methods cannot be overridden but only hidden). ALL non-static classes, methods and variables will be instanciated within the heap, with pointers to any static classes, methods or variables that are required. These are run-time created 'images' of code within the byte code, and are built up to match their hierarchical tree from java.lang.Object down. And this is why they can override methods, as the methods are loaded into these 'instances' from the bottom of the brach backwards towards Object. All methods from the lowest class in the tree are created first, then up the branch one and all these methods are created. Any method in this second row, and those above, whose foot-print matches a method already created are ignored (or over-ridden) I'm afraid this is all ottomh (off the top of my head) but is accurate as a brief over-view. If anybody really cares about this subject that much, mail me and I'll write a full papaer on it ;-) [That's a joke, don't ask, I have enough work as it is :-)] Of-course, java that we write is in fact an interpreted language and is run within the JVM which strictly follows the memory layout above. How the JVM handles the code is specific to how it was programmed. Other OO languages like C++ et al. strictly adhere to this stucture in memory. PEARL is an interpretted language, so whether it is OO or not, it is handled by it's own interpretter which will handle the code as it is designed to do. Hope this has been enlightening, and I will follow this up with my long awaited lecture on "Struts for coffee makers 101" ;-) Cheers Simon ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, July 10, 2003 6:00 AM Subject: RE: [OT] Use of Static Methods > > > On Thu, 10 Jul 2003, Andrew Hill wrote: > > > Date: Thu, 10 Jul 2003 10:52:53 +0800 > > From: Andrew Hill <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > Subject: RE: [OT] Use of Static Methods > > > > Put them as methods of a Singleton instance instead of static methods. > > (Ive been using lots of static methods so the fact Im telling you to do it > > differently to that should indicate something ;->) > > > > -Especially when other people have to use these methods too. The number of > > times Ive cursed classes like PropertyUtils and BeanUtils for being statics > > and not singletons because I want to use a slightly different version in > > some places... > > Note that, at least in the case of PropertyUtils and BeanUtils, we have > learned the error of our ways, and are refactoring things to use the > singleton (per webapp, but the same philosophy) pattern :-). > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
