On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Stevan~
>
> I am going to assume that you intended to reply to perl 6 language,
> and thus will include your post in its entirety in my response.
Yes, sorry... I missed the "reply to all" button on the gmail UI by a
few pixels I guess. Thank you for forwarding.
> Now that everyone is on the same page, I will go about responding
>
# snip some code ....
> >
> > class Pipe::Stem {
> > has $composed_of;
> > has $color;
> > has $length;
> > has $filter = bool::false;
> > }
>
> so far I am mostly with you, except one question. Does <has $filter =
> bool::false;> just provide a default?
Yes, that is a default value. I assume that most Pipe smokers don't
like filters in their pipes, I might be wrong on that one because I am
not a pipe smoker :)
> > You would then model the different pipes you sell;
> >
> > class MagrittePipe {
> > has $stem = Pipe::Stem.new(
> > :composed_of<ebony>,
> > :color<black>,
> > :length<short>
> > );
> > has $bowl = Pipe::Bowl.new(
> > :composed_of<mahogany>,
> > :color<brown>,
> > :size<medium>
> > );
> > }
> >
> > Now, you might say, why not make the MagrittePipe an instance of Pipe,
> > and give the Pipe class a few more attributes, like a name. Well, if
> > you did that then you couldn't subclass it of course.
>
> Actually, I was going to ask why not make MagrittePipe inherit from Pipe.
Ooops, forgot that part it should infact inherit from Pipe. And of
course you can do that dynamically with the metamodel ;)
> > Well, using introspection, it becomes very simple to discover various
> > qualities about your inventory, enough to probably even autogenerate
> > the HTML pages for your online-web store (powered by Perl 6 of
> > course). And lets not forget the uber-cool Perl 6 Object Database
> > which you are using to store your real-time inventory in (all
> > metamodel powered of course). And of course if you want, you can use
> > the DistributedObjectProxy metaclass which will automatically make
> > your objects distributed so that your door-to-door Pipe saleforce can
> > update your inventory in real time from their cellphones. And your R&D
> > department can use the built-in (but as yet unspeced) logic
> > programming features of Perl 6 to mine your customer information from
> > your (previously mentioend) object database and genetically "grow"
> > new, more desireable Pipe products (which is easy to do since your
> > metaclasses are programatically composable (and no I don't mean eval
> > $code)).
>
> I think you mis-understand me. I do not question the value of a
> powerful meta-model. Quite the contrary I want to see Perl 6 have a
> meta-model more powerful and accessible then CLOS. I see it as a
> necessity for a language that plans to truely scale in the future.
>
> What I do question is the usefullness of having bare class names
> represent these "prototype objects". I just don't really understand
> what they are for or do.
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;
(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.
Stevan
