On Fri, Oct 14, 2005 at 01:43:39PM +1100, Stuart Cook wrote:
: On 14/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
: > 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.
:
: How about:
:
: method bark (Dog ::K:) { ... }
:
: Where ::K must hold a class that is a subclass of Dog. Or 'is a
: subtype of', or 'does', or whatever the most correct term is in this
: context.
Look guys, I want it to just consistently be
method bark (Dog $d) {...}
regardless of how instantiated the dog is. Think of partially
instantiated subroutines via .assuming. A sub is a sub regardless of
how much it's been curried. So who cares if it's a complete Dog or
a partial Dog, or a completely generic Dog? Nobody cares until you
try to call a specific method that relies on some specific attribute.
If you call a sub with an incomplete definition, you should be prepared
to handle the exception. If you call a method with an incomplete object,
you should be prepared to handle the exception.
Of course, by that argument, $d should be considered defined even if
it's a completely uninstantiated class object. With subs the final
proof of actual well-definedness (not to be confused with .defined())
is whether it can be bound to a particular set of arguments. It's a
rather lazy definition of well-definedness. I'm proposing that
all objects follow the same model of not caring how well they're
defined until you actually try to use them for something. I don't
think I care any more about whether classes test as defined or not.
It's like reality--there are a lot of complex problems where the
simplest way to simulate them is via reality itself, and all other
simulations are guaranteed to be slower.
But we have to think a bit more about the notion of currying class
objects into real objects, or something approaching real objects.
This only reinforces my view that all the meta stuff for Dog must
be via the .meta or the associated package. There is no Class object.
It's a false dichotomy. Class is a role that manages partially
instantiated objects, just as Routine (or whatever it is these
days) is a role that manages partially instantiated sub calls.
And they mostly manage by delegation to .meta.
Larry
