Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are inheritable, but have the following
behaviors/attributes:
1) Autogenerated Class attribute accessors will be submethods.
This means that this code:
class Foo {
our $.bar;
}
will be functionally identical to this code:
class Foo {
our $.bar;
submethod bar (Class $c:) { $.bar }
}
This will ensure that class methods which are specifically tied to
some kind of state within the class will not be inherited. At least
not by default, if you want that behavior, then you can do this:
class Foo {
our $.bar;
method bar (Class $c:) { $.bar }
}
2) Class methods be defined more specifically
I think that "method (Class $c:) { ... }" is kind of ugly, and if we
use eigenclasses to implement class methods, is not even correct.
Ideally we have some kind of way to represent Larry's "Dog but undef"
concept. This could be thought of as being the prototypical instance
(for those who like prototype based OO), and it would also be the
invocant for all class methods for Dog.
So anyway, here are a few ideas, in no particular order:
method bark (::Dog $d:) { ... }
# not sure if this notation is already taken or not
method bark ($Dog $d:) { ... }
# not sure I like this one myself, but to me it helps to re-
enforce the singleton nature of the class instance
method bark (Dog) { ... }
# this would be similar to functional languages where the
parameter matches a value, not the type of a value.
# The user would then be forced to use $?CLASS inside (this one is
probably too much B&D)
classmethod bark { ... }
# you can't get more specific than this :)
Okay, thats all for now, however, be on the lookout for some other
mails on the specifics of class method dispatch. If we are going to
do it, we need to do it right.
Thanks,
Stevan
