On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Stevan~
>
> On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> >
> > Well, to be totally honest, I think only Larry truely understands
> > their usage, but to the best of my understanding they are intented to
> > serve a number of roles;
>
> I agree with you about that, which is part of what bothers me.
>
> >
> > (Larry, please correct me if I am wrong here)
> >
> > - to allow for introspection of the class.
> >
> > After all ^Foo.can() is really just a series of method calls to the
> > Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
> > type!!
> >
> > - provide an invocant for "class" methods.
> >
> > Larry does not like the class-method/instance-method distinction (in
> > fact it seems he doesn't even like the class/instance distinction
> > either), and has declared that a "class method" is really just a
> > method of the class which does not access any instance attributes.
> > Well, this complicates the type signature of the invocant, and we need
> > an invocant that the type-checker can check.
> >
> > In Perl 5, classes were just package names which were just strings.
> > This will not work in Perl 6 in the presence of a reasonably decent
> > type checker, the class needs to be *something*. Now Larry has also
> > declared that he does not like the idea of a "class object", I think
> > this is because that means that a properly typed method signature for
> > a class method would look like this:
> >
> > class Foo {
> > method foo (Class $class:) {
> > say "I am a class method, and proud of it";
> > }
> > }
> >
> > According to the signature, this method takes any Class instance as an
> > invocant. Well
> > thats just not right because it should only accept the Class instance
> > which represents the Foo class. But we can't (at least I dont think we
> > can) be that specific, at least not easily enough to also allow this
> > method to be called by an instance of Foo as well.
> >
> > So, the solution, use "prototype instances" for "class objects". So
> > now we can properly type our class method for both Foo and $foo like
> > this:
> >
> > class Foo {
> > method foo (Foo $class:) {
> > say "I am a class method, and proud of it";
> > }
> > }
> >
> > And whalla, we have a class/instance method ala Perl 5 and it is
> > properly type checkable too.
> >
> > Of course I might be totally wrong here, but this is my best grasp on
> > the subject.
>
> Perl 6 allows dispatch on value (if I am not mistaken). Thus, just as we
> have a
>
> sub fact( Int 0 ) { return 0; }
> sub fact( Int $n ) { return $n * fact($n-1); }
>
> Why not have class methods take the form
>
> class Foo {
> method foo (Class Foo) {
> say "I am a class method, and proud of it";
> }
> }
>
> They are still well types (I think), and properly restricts the types
> allowed for foo.
Larry is going to have to answer the why part of that descision.
However, I would venture to guess that dispatch on value is much
harder to grok in this case than dispatch on type. Especially since it
requires that you understand (at least partially) the metamodel.
> After all Foo is just a specific instance of the class Class.
Shhh... class objects don't exist ... I was never here,... I will I
count to three and when I snap my fingers you will awaken and will
have forgotten all about class Class.
1 ... 2 ... 3 ... *snap*
