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.
On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> > Larry~
> >
> > On 2/7/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > Indeed, and the modeling point of view is that $pipe is *also* just
> > > a representation of the Pipe. Neither Pipe nor $pipe is the thing
> > > itself. Most computer programs are about Something Else, so computer
> > > languages should be optimized for talking about other things rather
> > > than talking about themselves. The answer to
> > >
> > > Pipe.can("Smoke")
> > > $pipe.can("Smoke")
> > >
> > > should be the same, not different. On the other hand,
> > >
> > > ^Pipe.can("Smoke")
> > >
> > > is a different matter, insofar as you're asking a question about a Class
> > > object rather than a Pipe object. And now you get your Platonism back.
> > > You just have to be explicit about it.
> >
> > I see the value of ^Pipe and $pipe as seperate objects which can be
> > manipulated programmatically. What I don't really understand is what
> > exactly Pipe is and where it would be useful.
> >
> > They way you have described Pipe feels a little muddy to me and I am
> > unsure about its purpose and semantics. Is it just an object I ask
> > `.can()` or does it have some deeper usefulness?
>
> Well since ^Pipe will really just be the same value as Pipe.meta, then
> you can do many things with it (if I get my metamodel wishes that is).
> Now, in keeping with the "examples of useful things for people other
> than programmers and computers" spirit of this discussion, here is one
> possible approach to using metaclasses in a constructive way.
>
> Okay, so lets assume you own a tobacco shop, and you have modeled a
> Pipe hierarchy to represent all the pipes you sell. Your base classes
> might look something like this:
>
> class Pipe {
> has $stem;
> has $bowl;
> }
>
> class Pipe::Bowl {
> has $composed_of;
> has $color;
> has $size;
> }
>
> class Pipe::Stem {
> has $composed_of;
> has $color;
> has $length;
> has $filter = bool::false;
> }
>
> 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.
>
> class MagrittePipe::SpecialEngravedAnniversayEdition {
> is MagrittePipe;
> does Engraved[$engraving_text = "Ceci n'est pas une pipe"];
> does SpecialEdition[$type<Anniversay>];
> }
>
> Now, what does all this have to do with 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)).
>
> Of course, I am just dreaming here, but .... maybe I am not! Most of
> this is already possible using CLOS (see the Franz's AllegroCL 8.0
> it's bad*ss IMO), so why can't we have it?
>
> Anyway, I hope that doesn't make your head hurt too much Matt ;)
Now that everyone is on the same page, I will go about responding
> class Pipe {
> has $stem;
> has $bowl;
> }
>
> class Pipe::Bowl {
> has $composed_of;
> has $color;
> has $size;
> }
>
> 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?
>
> 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.
> 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.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
