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.

: 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.

: This would DWIM, would mean we don't need multiple dispatch for it (at
: least not in visible form) and would be in line with the common perl5 strategy:
:       $class = ref $class if ref $class;
: 
: If you *did* want a method that treated invoke-by-classname and
: invoke-by-instance differently (i.e. a constructor), you simply wouldn't
: declare it as a class method, and have the method check the topic itself.

We haven't solved the problem of instance methods that want to
reject class invocants at compile time.  Though I suppose explicitly
declaring the type of the invocant would have that effect.  I'm sure
there are some who would argue (and I might be one of them) that an
implicit invocant should default to only accepting an instance, and
you have to declare an untyped invocant to get class-or-instance.
(Or declare it with a class superposition like (Class|Dog), which
presumably lets you pass either a Class instance or a Dog instance).

Larry

Reply via email to