Sean, this may be the subtlety I was talking about in the last post - under the hood stuff so to speak =)

Sean Corfield wrote, On 4/4/2007 7:21 PM:
On 4/4/07, Jaime Metcher <[EMAIL PROTECTED]> wrote:
Am I missing some crucial distinction between static methods and class
methods?  I don't know Java well enough to be sure, but the Ruby docs
actually state that they are equivalent. I don't know Ruby, but can anyone
imagine Smalltalk without class methods and variables?

Well, it's a little bit more complex than it appears on the surface
(unfortunately).

In common parlance (read: Java), a static method is one that can be
executed just by knowing the class name, without needing an object
instance, e.g.,

result = MyClassName.someFunction();

A static method is really just like a regular old function - it's
merely "associated" with the class to which it belongs, like a library
function. In particular, it cannot reference "this" since it has no
object associated with its calls.

A non-static method can only be invoked on an object instance and the
object instance is bound to "this".

In ColdFusion, you really only have non-static methods (with "THIS"
scope and "VARIABLES" scope essentially bound into the object
instance).

C++ works pretty much the same way as Java (it has both static and
non-static methods).

In Java, however, you have reflection. You can get the class name of
any given object instance and - this is critically important - you can
get an object of type "java.lang.Class" which provides information
about an object's type. That "meta-object" allows you to create
instances and to call methods - both static and non-static (as I
recall - I'd have to consult the Java API docs to be 100% certain).

Now let's go to Smalltalk (I don't know Ruby well enough to go to that
first). In Smalltalk, a class has an associated "class object"
(representing its type) as well as actual instances of a given class.
That's similar to Java. When Smalltalk refers to a "class method", it
means a method defined on the "class object" that represents the type
of a given class or object. Those are similar to Java's static methods
in that they can be called without an instance of the specified class
type - however, they do require an instance of the "class object". In
other words, in Smalltalk, there really are no true static methods -
all methods require some sort of object instance, even if it is
actually an instance of the "Class" type.

Hope you're following me so far?

What would be the closest equivalent in CF if it had this sort of
thing? Well, imagine if getMetadata(obj) returned a CFC instance
instead of just a struct and you could somehow attach methods to it...
those would be "class methods" (or "static methods") in that once you
had the metadata, you could call them without needing an actual object
instance on hand. Of course, this analogy breaks down somewhat because
you can't actually get the metadata without having at least one object
instance!

So that's static methods / class methods.

What about static variables / class variables?

In Java, these exist as a single instance per class loader for each
class. In other words, if you have class MyThing and it has a static
int x; declared in it, then one instance of "x" exists for each class
loader into which "MyThing" is loaded - no matter how many instances
of "MyThing" you create.

In Smalltalk, these are variables in the "class object" - the metadata
object - and only one instance exists for each given class.

What would be the closest equivalent in CF? An application scope
variable (or a server scope variable). Or you could get the metadata
struct for a CFC type and store variables in there (not recommended
since that behaves "almost" like server scope data).

So... Is CF missing out by not having "static methods" and "static
variables"? Not really, we've had application scope and server scope
available for a long time and we're using to managing single instances
of UDFs and variables in those scopes. It might save us a little bit
of typing and be a slightly clearer way to organize our code but it
really isn't a big deal.

Hope that helps?



You are subscribed to cfcdev. To unsubscribe, please follow the instructions at 
http://www.cfczone.org/listserv.cfm

CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]

Reply via email to