On Tue, Feb 07, 2006 at 07:32:18PM -0500, Stevan Little wrote:
: 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.
That's a good description of what set off the initial alarm bells, but
I think what "pushed me over the edge", er, was the more general
problem of hypothetical calls to MMD, the "if I were to call this,
what would happen?" problem:
my &mmdref := &foo:($dog, $cat, $pickle);
my &mmdref := &foo:(Dog, Cat, Pickle);
I want to be able to ask what function (or set of functions) I'd get
regardless of whether I actually have objects of that type. I want
to do it with real objects and not just types because I see it as a
kind of currying, so the syntax has to support value-based dispatch
when values are specified, but type-based dispatch in general.
And that's when I started thinking that normal people don't actually
think about types the way type theorists think about types, and we
should give normal people a way to be vague when that helps them
linguistically. The type theorists can say ^Dog when they know
they mean the class and not a dog, and the normal people can say
Dog and let the system dwim depending on which method is called.
That's the part I'm pretty sure about. The part I'm not so sure about
is the think I've been mulling for a month or so since people started
carping "But how do I mark class methods as special?" The current
solution is that, if you want them to be class methods explicitly,
you use something like the
method ^howmany () {...}
Dog.^howmany
notation to explicitly put them into a different namespace attached to
the metaclass object so they don't get confused with ordinary methods.
People get into trouble when they inherit class methods, so it seems
like a namespace issue to me, with a solution that involves putting them
somewhere where you have to work a little harder to say which class
method you're really interested in. But I'm less sure of this part
of it.
Well, hey, at least I'm not in danger of confusing category:<x y>
notation with package::<x y> notation like I did yesterday. Durn
slices... It's been kind of a rough week, and it's hard to think
clearly (and even harder to express myself clearly) when so many
other things are happening, like work.
'Course, it could just be senility setting in...wouldn't be the first time...
Larry
