--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Oct 2002, Michael Lazzaro wrote:
> : My temporary hack while writing the proto-recipes was that we'd
> have a
> : property that would simply declare a method to be a class method,
> but
> : I'm having a hard time coming up with an acceptable name to suggest
> for it:
> :
> : method foo is class_method { ... } # ???
> :
> : It feels, conceptually, like something that should be a property.
> The
> : other possibility is to use a keyword other than "method" for class
> : methods, but that would also require us to think of a word (and
> would
> : probably just be shorthand for a named property anyway). So, I
> haven't
> : been able to come up with a single decent noun or adjective that
> means
> : "class method", so far. (classwide? static? blind? classmeth?
> cmethod? classorific?)
>
> Doesn't feel like a property to me. Feels to me like a type-coercion
> on
> the invocant. Or if not a coercion exactly, a view of the desired
> type
> of the invocant.
An instance of class Class is wierd, because it defines two different
sets of things: internal bits, usually called "static", and
"interitable/delegatable" bits (both data and methods) which will be
present in all the instances of the type.
Javascript makes for a good thinking-about language here because the
constructors must explicitly attach each function and each member of
the new class.
Perl5 had some of this with bless'ing an anonymous, initialized hash --
the act of creating the data members was overt.
C++/Java, OTOH, fall into the trap of treating the class as a structure
definition -- once they've gone this route, there's the question of
"what secret word do we use to escape from the structure model" --
answer "static".
According to Java, there's four sets of "permissions" available for
members: private, package (no keyword), protected, public.
"Package" means anything in the same package, "Protected" is package
plus subclasses.
I wonder if there's actually another aspect here: That which is
accessible to instances. ("Particular"?)
Static members are usually considered "class-global, but uniformly
visible to the instances". Is it useful to talk about variables which
belong in the class object but which may or may not be visible to the
instances?
This may be more meaningful in the context of a tainted object, or in
conjunction with inheritance (we allow direct instances to access this
variable, but not instances of subclesses).
> : Regardless of how we declared it, my operating theory was that any
> : method declared as a class method would automatically be able to
> take
> : either a class or a class instance as it's invocant, and do the
> right
> : thing (i.e. when using an instance to invoke a class method, it
> would
> : automatically convert it to a class before assigning it as the
> topic, so
> : the implementing method wouldn't even notice, unless it went out of
> it's
> : way to look.)
>
> If every Object happens to implement the Class interface, merely
> declaring the invocant as a Class would presumably have this effect,
> whether or not MD was in effect. I don't know whether that's a good
> idea or a bad idea. I'm sure there are people out there with
> opinions
> on the subject, though.
That paragraph is a little counterintuitive? Wouldn't Class implement
the Object interface?
=Austin
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
