Class methods vs. Instance methods

Is this true? If it is, then I think it violates polymorphism as
demonstrated by the following:

class Dog {
method tail { "brown and short" }
};

class Chihuahua is Dog {
has $.color;
method tail { $.color _ " and short" }
};

You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
Chihuahua.tail. That's extremely counter-intuitive.

I think that class methods should be explicitly defined as class
methods and you cannot call a class method upon an instance, just as
you cannot call an instance method upon a class. Plus, this should be
determinable (for the most part) at compile time, which is a bonus,
imho.

Thanks,
Rob

I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.

: I think that class methods should be explicitly defined as class

I believe this is already determinble at compile time for the most part.

But I have a strong gut-feeling that over the long term it's going to
be important to be able to view a given object as either a partially
instantiated class or a partially undefined object, and for that we have
to break down the false class/instance dichotomy. And to the extent
that the dichotomy *isn't* false, we're trying to sweep classness into
the .meta object, which is the *real* class object in Perl 6.

Larry

Perhaps I am just being short sighted, but I never saw this as a false
dichotomy. In fact, every time I hear about these "partially
instatiated" I cringe in horror about the strange halfway lands we
might end up in... Oh no, this method can only be called on an object
that is 3/4 initialized, and you supplied one that is 2/3 initialized
that causes undefined behavior.

Could you provide a concrete example of the advantage of this approach
please? Failing that can you try and expand on your gut feeling a
bit?

Thanks,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Except there are no such things as classes in a prototype view of
reality. Everything is an instance and there are no such things as
class methods. The entire idea that an object (::Dog) can call methods
that are for another object ($fido) is ... well ... it's a little off.

That's like saying any object can call any method from any other
object so long as that method is invariant.

I'm sure you understand the distinction you're making. I know I don't
and I've been trying to follow this discussion for the past year. I'm
may not be the brightest bulb in the chandelier, but I'm no 15W dimmer
switch, either.

Frankly, you should be using people like me, Matt Fowles, and the
other programmers on the list as sounding boards. If we're having
problems understanding the concept, then how are we going to explain
"partially-instantiated classes" on Perlmonks or #perl or clmp? Like
it or not, we're the sergeants in the Perl army. We're the guys
explaining all this stuff to the privates coming up the ranks. It may
be a nice extension to have, but I'm not sure this should be part of
the standard MOP.

Rob

May or may not be of use, but Larry's view sounds a bit like reconcilling the
(again considered irreconcilable) gap between nominal and structural subtyping:

http://cakoose.com/wiki/type_system_terminology#13

Where the "empty" class object is the degenerate case of the smallest possible
structural type, so it can be fulfilled by anything more structurally
rich as long
as they share the same nominal constraint.

Audrey

"Any practical programming language with structural subtyping will
probably let you create and use aliases for type names (so you don't
have to write the full form everywhere). However, the underlying type
system will only consider the structure of the type when doing its
job."

What's wrong with Perl doing things that way? duck-typing with names
... sounds like a plan to me ...

Rob

The thing is that people using .does(Name) and .isa(Name) is probably
expecting a nominal answer, not a structural one.

Although I do think Visual Basic's explicit duck-subtypes makes a lot of
sense:

my subset Duck where {
has $.half_life;
can doom:();
can quake:(--> Wolfenstein);
};

then you can apply it as a ducktype with names:

my Duck $donald = some_function();
$donald.quake; # assured to return a Wolfenstein object

It's already part of S12, by the way.

Audrey

Accidental structural equivalence is a problem -- it's one of the things wrong
with C's so-called type system, for example.

I like to think of roles as nominally-tagged (and checked) structural
subtyping. When you're *defining* a type, its structure matters. When
you're *using* it, its behavior matters. It would be nice to keep those two
separate.

-- c

In a prototype-instance system,

instance(Dog) isa class(Dog)
instance(Chihuahua) isa class(Chihuahua) isa class(Dog)
instance(Chihuahua) isa instance(Dog)

Note that instances inherit doubly, from own class and from parent's
instance.

But this does not imply that:

class(Chihuahua) isa instance(Dog)

So I don't see a problem.

Miro