Re: Object spec
On Wed, 05 Mar 2003 13:31, Brent Dax wrote: > # *) A superclass (obviously, but I consider it to be the > # same level as > # Properties, Methods and Attributes.) > Superclass*es*. Perl 5 has MI, and I don't expect that to change in > Perl 6. Parrot absolutely *must* support Perl, or it has failed in its > primary goal. > # *) a set of Interfaces (similar to multiple inheritance; a way of > # grouping methods associated with a class for another to > # implement). > # eg, in Java and IDL. > Can this be implemented in terms of MI and/or delegation? (For Perl 6's > part, my understanding is that an interface is just a class that > inherits from Interface--although I could *easily* be wrong about that.) Whether to implement interfaces using Multiple Inheritance, or Multiple Inheritance using Interfaces is a half empty/half full decision. It makes little difference. What I'm saying is that it should be possible to `filter' which methods you inherit via @ISA. Ideally there would be some standard way for a module to describe groups of methods for other classes to import a la Exporter's %EXPORT_TAGS. The result would allow both Multiple Inheritance *and* Interfaces. In my experience classes only have *is a* relationships with one other class. The other classes they inherit are *can behave like a* relationships. MI should be frowned upon where Interfaces will not do IMHO. But that is a flamewar topic :-). > # *) Associations, eg in UML. > I've deleted your stuff about associations below, which described their > properties nicely, but didn't explain what they *are*. What are they > and when would you use them? Can they be implemented in terms of > properties and/or attributes? Associations are grouping two classes together. Or more, in the general case, but this is not required as three way associations can be broken down into an `association class' with three or more two way associations. It is a simple concept. You use them all the time, whether you call them associations or not. When I first started recognising them after I started to learn UML, programming felt like cooking with Garlic for the first time. For instance, a biological parent/child relationship is a two to many association. From the parent's angle, the association might be called `children'. From the child's angle, the association might be called `parents'. They are the same relationship, and altering one should affect the other - this `empathic' effect of the collections is (IMHO) important to include. It's a bit like declaring a linked list and not having to worry about maintaining both directions in your user code. In RDBMS terms, a many to one relationship is implemented with an `id' column in the referring class. A one to many relationship is implemented with a `foreign key' in the referant class. Is the relationship from the class with the foreign key to the class without or the other way? It is both. Associations can be implemented in terms of properties and/or attributes, however I think it would pay to have a common way to access and manipulate the collections that implement the associations, so a piece of code can decline to care whether it is a `many to one' relationship implemented with a simple reference, an `ordered' relationship implemented with a array, an `unordered' relationship implemenetd with a set or bag, or a `keyed' relationship implemented with a hash. In fact, I have implemented such behaviour using attributes, in Class::Tangram - an experimental pre-release (for Perl 5 :)) is available at: http://vilain.net/pm/Class-Tangram-1.12.2.tar.gz Probably the most relevant for this discussion are the README and t/04-containers.t. It is not yet complete, I need to flesh the test cases out more. Right now the implementation of this particular feature leaves a bit to be desired (it's still in the `code it slowly but correctly' stage), which is why I haven't released it to CPAN yet; the real drawback right now for me is speed. I'm working on some alternatives which would be faster (see README.Containers in the distribution). Associations could easily be left out of the object core if it is not deemed to fit; but I just thought I'd say that I consider these to be one of the primary elements of objects and so IMHO belong in the Perl 6 object implementation. UML considers them pretty core, too. Leave them out to carry on with the status quo of a myriad of subtly different, non-interchangable approaches to associating classes. -- Sam Vilain, [EMAIL PROTECTED] If you think the United States has stood still, who built the largest shopping center in the world? RICHARD M NIXON
Re: Object spec
--- Sam Vilain <[EMAIL PROTECTED]> wrote: > What I'm saying is that it should be possible to `filter' which > methods you inherit via @ISA. Ideally there would be some standard > way for a module to describe groups of methods for other classes to > import a la Exporter's %EXPORT_TAGS. > The result would allow both Multiple Inheritance *and* Interfaces. Are you speaking in terms of limitation, or requirement? It would be nice to have a syntax solution. I've seen p5 interfaces with stubs that die so that you have to override them in a subclass. It works, but seems a little kludgy. And I'm coming in late on this. Are you saying you want Exporter/%EXPORT_TAGS functionality built into the language and into all objects? Wouldn't that jack up the overhead? Is that what you mean by "associations", below? It seems like a pretty generic word. > In my experience classes only have *is a* relationships with one > other class. The other classes they inherit are *can behave like a* > relationships. MI should be frowned upon where Interfaces will not > do IMHO. But that is a flamewar topic :-). lol -- probably. :) But did you say that right? "MI should be frowned upon where Interfaces will not do"? Or are you using interfaces as a form of MI? I tend to think of them (inaccurately, I suppose) as "not really inheriting", but just defining requirements. Java pollution, probably. ;o] But I think it is generally frowned upon, while not being officially _bad_. We musn't dictate style. I prefer delegation, and making better ways available discourages the effectively deprecated methodology, but sometimes one needs to use what one knows and get the job done. As much as I dislike it, I have to admit that there are times to apply the adage "if a jobs worth doing, it's worth doing poorly." Then again, there are folk who will argue that MI isn't doing it poorly. For some problems, it might be the most elegant solution, even if interfaces won't handle the situation. An interface really *isn't* a true inheritance, after all -- so there must be a reason there's a difference. :o} > Associations are grouping two classes together. Or more, in the > general case, but this is not required as three way associations > can be broken down into an `association class' with three or more > two way associations. Sounds like MI. > It is a simple concept. You use them all the time, whether you call > them associations or not. When I first started recognising them after > I started to learn UML, programming felt like cooking with Garlic for > the first time. LOL!! (My ex and I once made 40-garlic Chicken Felice. Our classrooms *reeked* the next day, and the students were dying, but it took me all day to figure out why they were SO miserable, and I couldn't smell anything at all!! :) > Leave them out to carry on with the status quo of a myriad of subtly > different, non-interchangable approaches to associating classes. TMTOWTDI? Still, though your point is valid if I understand it, it will always be possible to create "non-interchangable approaches", and we don't want to dictate methods if we can help it. I think I need an exampleunfortunately I'm at work and haven't the time to properly peruse the one you offered. Thus I must apologize, and wait for more input. Paul __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Object spec
> Are you speaking in terms of limitation, or requirement?
> It would be nice to have a syntax solution. I've seen p5 interfaces
> with stubs that die so that you have to override them in a subclass. It
> works, but seems a little kludgy.
Back in 1988 programming Objective-C under NeXTSTEP you could have a
class that does these things (based on methods inherited from Object):
- iJustCantSeemToGetAnythingDone
{
[self notImplemented:_cmd]; // TODO: We'd better write this soon!
}
- imFeelingAbstract
{
[self subclassResponsibility:_cmd];
}
- bogus
{
[self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
}
Also, there was a doesNotRecognize: method that was called by the runtime
system when method lookup failed. I presume you could override it to do
nasty things, but I never did that myself.
Regards,
-- Gregor
Multiple Inheritance eq Interfaces [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
> Are you speaking in terms of limitation, or requirement?
> It would be nice to have a syntax solution. I've seen p5 interfaces
> with stubs that die so that you have to override them in a subclass. It
> works, but seems a little kludgy.
> And I'm coming in late on this. Are you saying you want
> Exporter/%EXPORT_TAGS functionality built into the language and into
> all objects? Wouldn't that jack up the overhead?
No. All I'm saying is that this sort of construct:
*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
Gives you everything that inheriting a class does, apart from the ->isa()
relationship. And potential unwanted namespace pollution.
I'm thinking along the lines of;
use base MyActualObjectSuperClass;
use base XML::Sablotron::DOM => [ "Core" ];
So your class ->isa("MyActualObjectSuperClass"), but ->can() all of the
Core DOM methods, which could perhaps be tested for as
->mimics("XML::Sablotron::DOM", "Core"), but also as
->isa("XML::Sablotron::DOM") for compatibility.
> We musn't dictate style.
No, but we should emanate good style. And I consider opening two class'
namespaces into the same stash to be very bad style.
Whenever I've seen Multiple Inheritance used, it has been because the two
classes inherited are not similar; and you're just doing it to save
yourself the hassle of splitting it into a ``servant class'' (ie,
referring to another object & forwarding methods to it). To re-iterate my
point, an interface is a `more correct' representation of this
relationship. So let's make the semantics of it easy so that people can
avoid it more easily...
Brent says that `attribute slots in a Parrot object are private to the
object', so if you really do inherit from two classes, it should be the
case that one class cannot access the other class' attributes. But - if
the child class accesses an attribute which is defined in both classes,
which does it get? I think that case (MI two classes with clashing
symbols) should be a hard run-time error. If attributes are declared
explicitly, then this enables this test. In Perl 5, the approach taken
with MI namespace clashes is to cross one's fingers ;).
--
Sam Vilain, [EMAIL PROTECTED]
"Understanding is a kind of ecstasy."
-- Carl Sagan
RE: Object spec
Several people have mentioned a desire to see Perl6 and Parrot facilitate object persistence. Should such issues be tackled in Parrot? Will there ever be a Parrot Object Database that we can serialize our Perl, Python and Ruby objects into, to be used at some later date in code written in Jako? If an appropriate parrot topic, I'd be especially interested to hear the thoughts of people like Sam Vilain, Dave Rolsky, Piers Cawley, and others who've already spent a great deal of tuits tackling these issues. What does parrot need to facilitate object persistence and cross-language OO? Obviously the OMG's UML and family of specifications deal with these issues. What other practical approaches exist? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds RoadMain: 913.384.1008 Mission, KS 66202 Fax:913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Object spec [OT?]
--- [EMAIL PROTECTED] wrote:
> > Are you speaking in terms of limitation, or requirement?
> > It would be nice to have a syntax solution. I've seen p5 interfaces
> > with stubs that die so that you have to override them in a
> > subclass. It works, but seems a little kludgy.
>
> Back in 1988 programming Objective-C under NeXTSTEP you could have a
> class that does these things (based on methods inherited from
> Object):
> - iJustCantSeemToGetAnythingDone {
> [self notImplemented:_cmd]; // TODO: We'd better write this soon!
> }
> - imFeelingAbstract {
> [self subclassResponsibility:_cmd];
> }
> - bogus {
> [self error:"Bogon flux exceeds limit %d\n", BOGON_LIMIT];
> }
As in the p5 equivs (???):
sub iJustCantSeemToGetAnythingDone {
shift->notImplemented(@_); # better write this soon!
}
sub imFeelingAbstract {
shift->{subclassResponsibility}->(@_);
}
sub bogus {
dir sprintf "Bogon flux exceeds limit %d\n", BOGON_LIMIT;
}
or am I completely off base?
(never done Objective-C under NeXTSTEP).
I think I may have missed the point.
Sorry, feeling dense. :)
> Also, there was a doesNotRecognize: method that was called by the
> runtime system when method lookup failed. I presume you could
override
> it to do nasty things, but I never did that myself.
AUTOLOAD()? Oh, I *have* done nasty things with that, that I don't even
like to talk about
Mostly, though, I just use it to fake up quick templated accessors.
If I know there are forty fields on an object that are all going to
look exactly alike, I'll stick a build-on-the-fly routine in AUTOLOAD
so that if one gets called it has a legitimate accessor the next time.
That way I only have to write one reasonably abstracted routine, rather
than the forty cut-paste-edit versions I've seen folk actually do in
this shop
"Hey, it was quick and easy"
Ugh.
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
> > Leave them out to carry on with the status quo of a myriad of subtly
> > different, non-interchangable approaches to associating classes.
> TMTOWTDI?
> Still, though your point is valid if I understand it, it will always be
> possible to create "non-interchangable approaches", and we don't want
> to dictate methods if we can help it.
> I think I need an exampleunfortunately I'm at work and haven't the
> time to properly peruse the one you offered. Thus I must apologize, and
> wait for more input.
Consider this excerpt from the test script:
my $joe = new Person(name => "Joe Average");
my $car = new Object(description => "Red Car");
$car->set_owner($joe);
ok($joe->posessions->includes($car), "Joe owns car");
The `Object' class has an association which it calls `owner', to class
`Person' (note: not all associations will be restricted to a particular
class). This is a collection that can only have one element so it is
implemented with a reference.
The `Person' class has an association which it calls `posessions' to class
`Object'. This is an unordered collection that can hold many elements so
it is implemented with a Set::Object.
They are the same relationship, and so setting the relationship from one
direction affects the other direction.
So, it makes sense to allow the same methods to access and update the
collections.
is($joe->get_posessions(0), $car, "Joe's first posession is his car");
ok($joe->posessions->includes($car), "Joe's posessions are a set");
ok($joe->posessions_includes($car), "Joe's set of posessions is
encapsulated");
These tests perhaps illustrate the level to which I've made them similar;
is($car->get_owner(0), $joe, "Refs can look like arrays");
ok($car->owner_includes($joe), "Refs can look like encapsulated sets");
eval { $car->owner->includes($joe) };
ok($@, "Refs cannot behave like real Sets");
To make the last test work would need associations in the object core, I
think.
--
Sam Vilain, [EMAIL PROTECTED]
Whatever you do will be insignificant, but it is very important that
you do it.
-- Mahatma Gandhi
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
> > And I'm coming in late on this. Are you saying you want
> > Exporter/%EXPORT_TAGS functionality built into the language and
> > into all objects? Wouldn't that jack up the overhead?
>
> No. All I'm saying is that this sort of construct:
>
>*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
>
> Gives you everything that inheriting a class does, apart from the
> ->isa() relationship. And potential unwanted namespace pollution.
Isn't that potential namespace pollution anyway?
You should obviously pay attention to what you're importing
Even now, you can explicitly
use Class ();
to import nothing, right?
> I'm thinking along the lines of;
>
> use base MyActualObjectSuperClass;
> use base XML::Sablotron::DOM => [ "Core" ];
>
> So your class ->isa("MyActualObjectSuperClass"), but ->can() all of
> the Core DOM methods, which could perhaps be tested for as
> ->mimics("XML::Sablotron::DOM", "Core"), but also as
> ->isa("XML::Sablotron::DOM") for compatibility.
Ok, forgive me. I see what you're saying, but I'm lost as to why.
As I said before, I'm feeling really dense today.
> > We musn't dictate style.
>
> No, but we should emanate good style. And I consider opening two
> class' namespaces into the same stash to be very bad style.
True enough.
("emanate"? maybe "promote".)
> Whenever I've seen Multiple Inheritance used, it has been because the
> two classes inherited are not similar; and you're just doing it to
> save yourself the hassle of splitting it into a ``servant class''
(ie,
> referring to another object & forwarding methods to it). To
> re-iterate my point, an interface is a `more correct' representation
> of this relationship. So let's make the semantics of it easy so that
> people can avoid it more easily...
I don't know if I can 100% agree with your assumptions, but I do agree
with your suggestion. :) As I said before, I prefer delegation anyway.
> Brent says that `attribute slots in a Parrot object are private to
> the object', so if you really do inherit from two classes, it should
> be the case that one class cannot access the other class' attributes.
Makes sense.
> But - if the child class accesses an attribute which is defined in
> both classes, which does it get? I think that case (MI two classes
> with clashing symbols) should be a hard run-time error.
Ah. P5 does a [EMAIL PROTECTED] search, right?
But that might not be what you want, particularly if you say
@ISA = qw / X Y /;
and you want X's foo() method but Y's bar(). If both have a foo() *and*
a bar(), you couldn't disambiguate with the order of @ISA anymore. It's
probably a rare case, but it will happen. You're right -- no clean
solution comes easily to mind. All that pops up atthe moment is
hardcoding hackery, in fact, but as I said, I'm dense today, lol
> If attributes are declared explicitly, then this enables this test.
> In Perl 5, the approach taken with MI namespace clashes is to cross
> one's fingers ;).
lol, yeah I guess so.
So how would you write code in your proposed solution to solve the
above example case?
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Associations between classes [was: Re: Object spec]
Seems like you are thinking along the lines of making Parrot support
Prevayler-style
http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html
stuff naturally and with less coding at the top layer. Is that where you
are headed with
this?
Regards,
-- Gregor Purdy
Sam Vilain <[EMAIL PROTECTED]>
Sent by: Sam Vilain <[EMAIL PROTECTED]>
03/05/2003 11:11 AM
To: [EMAIL PROTECTED], Paul <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc:
Subject:Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 04:19, Paul wrote:
> > Leave them out to carry on with the status quo of a myriad of subtly
> > different, non-interchangable approaches to associating classes.
> TMTOWTDI?
> Still, though your point is valid if I understand it, it will always be
> possible to create "non-interchangable approaches", and we don't want
> to dictate methods if we can help it.
> I think I need an exampleunfortunately I'm at work and haven't the
> time to properly peruse the one you offered. Thus I must apologize, and
> wait for more input.
Consider this excerpt from the test script:
my $joe = new Person(name => "Joe Average");
my $car = new Object(description => "Red Car");
$car->set_owner($joe);
ok($joe->posessions->includes($car), "Joe owns car");
The `Object' class has an association which it calls `owner', to class
`Person' (note: not all associations will be restricted to a particular
class). This is a collection that can only have one element so it is
implemented with a reference.
The `Person' class has an association which it calls `posessions' to class
`Object'. This is an unordered collection that can hold many elements so
it is implemented with a Set::Object.
They are the same relationship, and so setting the relationship from one
direction affects the other direction.
So, it makes sense to allow the same methods to access and update the
collections.
is($joe->get_posessions(0), $car, "Joe's first posession is his car");
ok($joe->posessions->includes($car), "Joe's posessions are a set");
ok($joe->posessions_includes($car), "Joe's set of posessions is
encapsulated");
These tests perhaps illustrate the level to which I've made them similar;
is($car->get_owner(0), $joe, "Refs can look like arrays");
ok($car->owner_includes($joe), "Refs can look like encapsulated sets");
eval { $car->owner->includes($joe) };
ok($@, "Refs cannot behave like real Sets");
To make the last test work would need associations in the object core, I
think.
--
Sam Vilain, [EMAIL PROTECTED]
Whatever you do will be insignificant, but it is very important that
you do it.
-- Mahatma Gandhi
Re: Associations between classes [was: Re: Object spec]
--- Sam Vilain <[EMAIL PROTECTED]> wrote:
>
> Consider this excerpt from the test script:
>
> my $joe = new Person(name => "Joe Average");
> my $car = new Object(description => "Red Car");
>
> $car->set_owner($joe);
>
> ok($joe->posessions->includes($car), "Joe owns car");
How much of Association is just "tricky, sticky property"?
You'd like to declare the relationship between them, but this can be
really difficult (consider e.g., nethack, in which the things you can
"own" are constrained by weight/volume/knapsack).
So certainly you need to be able to add code to the equation.
Person::possess(o is Object)
{
if (weight_of_my_stuff() + weight_of(o) > $self.weight_limit)
{
whine(...);
}
else
{
$self.stuff.push(o);
}
}
In other cases, you don't care so much. So then it would be nice if you
could declare the relationship and have the accessor functions get
generated for you.
I work with a tool that provides just a little built in support for
this kind of thing:
When you create a relationship (using the "relate" command) between to
objects, you can do:
ccm relate -from $object_spec_1
-name $relationship_name
-to $object_spec_2
ccm unrelate [spec, as above]
ccm relate -show [partial or complete spec, as above: -f -t -n]
ccm query "is__of('$object_spec')"
ccm query "has_('$object_spec')"
The relate database is pretty straightforward -- a three-column table.
The query part is supported by "magic" -- the query syntax parser knows
how to chop up is_XXX_of() and has_XXX() predicates to extract
relationship names.
I think that the Association concept can be implemented as a non-core
package. You'll declare Associations like classes, except that they'll
mostly be auto-generated. However, if you need to insert code (as
above) you can explicitly spell out your sub.
What would be nice would be a convention for
accessing/creating/querying/modifying them, so that whenever we see
"is_AssociationName_of(...)" (or whatever) we know that this is an
association.
=Austin
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
No. All I'm saying is that this sort of construct:
*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
Gives you everything that inheriting a class does, apart from the ->isa()
relationship. And potential unwanted namespace pollution.
It's probably time to note that, when I started the discussion, it
was on perl6-internals, and all I was interested in was nailing down
needed semantics. What you've started talking about is perl 6
*language* syntax and such. I'm not sure Larry's ready to start that
yet.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
> > *{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
> > Gives you everything that inheriting a class does, apart from the
> > ->isa() relationship. And potential unwanted namespace pollution.
>
> It's probably time to note that, when I started the discussion, it
> was on perl6-internals, and all I was interested in was nailing down
> needed semantics. What you've started talking about is perl 6
> *language* syntax and such. I'm not sure Larry's ready to start that
> yet.
That explains why it was starting to feel a little "drifty".
Next topic? :)
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Re: Object spec
Garrett Goebel <[EMAIL PROTECTED]> writes: > Several people have mentioned a desire to see Perl6 and Parrot facilitate > object persistence. Should such issues be tackled in Parrot? Will there ever > be a Parrot Object Database that we can serialize our Perl, Python and Ruby > objects into, to be used at some later date in code written in Jako? > > If an appropriate parrot topic, I'd be especially interested to hear the > thoughts of people like Sam Vilain, Dave Rolsky, Piers Cawley, and others > who've already spent a great deal of tuits tackling these issues. All I want is good object serialization. So I can say to an object 'write yourself to this stream' and have that do the right thing (ie, all the objects that are reachable from an object are serialized before that object, with any cycles broken. It's not much. The trick is defining the protocol of our stream classes so that we capture enough information. For bonus points it would be nice to be able to serialize a class so that one could send an object of an arbitrary class down a stream and know that, even if the object is later deserialized in a system which doesn't have the appropriate modules the object can still work. But that's probably something you'd do in a stream filter. Oh yeah, and 'Object' should have an C method, or what would be the point? Once I have a simple, stream based serialize/deserialize mechanism it's relatively easy to add pretty much any datastore management mechanism I want on top of it. Oh yeah, for extra bonus points, I'd like to be able to override the way Perl manipulates instance variables so I can track whether an object is modified during its 'in memory' time, that way I can write a storage system that's efficient about which objects it writes back to the database on a commit. (I can work scary mojo with having every object carry 'round a flattened copy of its old self, but that's rather expensive...) Note that I only need to do this when a database manager is in place, and I only need the override on unmodified, managed objects. Most of this stuff is available, at a cost (to both speed and programmer sanity) in Perl right now, but I really, really want nice interfaces. -- Piers
RE: Multiple Inheritance eq Interfaces [was: Re: Object spec]
Sam Vilain:
# > We musn't dictate style.
#
# No, but we should emanate good style. And I consider opening
# two class'
# namespaces into the same stash to be very bad style.
We *must* support MI, delegation and interfaces in Parrot. Interfaces
can probably be implemented in terms of MI and/or delegation, so why not
do so?
# Brent says that `attribute slots in a Parrot object are
# private to the
# object', so if you really do inherit from two classes, it
# should be the
# case that one class cannot access the other class'
# attributes. But - if
# the child class accesses an attribute which is defined in
# both classes,
# which does it get?
Neither. Attributes are private to the class that created them. A
subclass can't (well, shouldn't) access a superclass's attributes.
# I think that case (MI two classes with clashing
# symbols) should be a hard run-time error. If attributes are declared
# explicitly, then this enables this test. In Perl 5, the
# approach taken
# with MI namespace clashes is to cross one's fingers ;).
Alternatively, the approach taken with MI namespace clashes in Perl 5 is
to let the programmer arrange the inheritance tree as he sees fit, and
to let him explicitly delegate when there's no single arrangement that
works. That's a lot more *useful* than a hard error. I can see a
warning that can be deactivated, but not a fatal error.
class A {
method X { ... }
}
class B {
method X { ... }
}
class C is A is B {
...
}
Making that a fatal error looks great on paper, but what if B::X was
added in the latest version of B.pm? Do you really want a *fatal* error
to appear on machines that upgrade B, but not those that don't? Do you
have any idea what a nightmare that would be for module writers?
A warning to the effect of "Methods A::X and B::X conflict in mutual
subclass C", deactivatable with both 'no warnings <>' (or something)
and 'method X is from(A)', would please me much more. The manpage can
strongly encourage use of 'is from' when there's MI afoot.
But we're in language territory again. Parrot has to deal with this
issue in a flexible way, so always emitting a fatal error is simply not
an option.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
On Thu, 06 Mar 2003 15:31, Brent Dax wrote:
> Sam Vilain:
> # > We musn't dictate style.
> #
> # No, but we should emanate good style. And I consider opening
> # two class'
> # namespaces into the same stash to be very bad style.
>
> We *must* support MI, delegation and interfaces in Parrot. Interfaces
> can probably be implemented in terms of MI and/or delegation, so why not
> do so?
I'm not disagreeing with you. But I think it would be good to specify
exactly which methods you're inheriting via `is X', rather than
all-or-nothing. This would allow for the concept of modules exporting
Interfaces without the danger of collisions.
But then, I guess so would simply mandating that classes export their
interfaces cleanly, in chunks that are unlikely to collide.
> # attributes. But - if
> # the child class accesses an attribute which is defined in
> # both classes,
> # which does it get?
> Neither. Attributes are private to the class that created them. A
> subclass can't (well, shouldn't) access a superclass's attributes.
Good.
> Alternatively, the approach taken with MI namespace clashes in Perl 5 is
> to let the programmer arrange the inheritance tree as he sees fit, and
> to let him explicitly delegate when there's no single arrangement that
> works. That's a lot more *useful* than a hard error. I can see a
> warning that can be deactivated, but not a fatal error.
You are right - but this is a different condition. There is no error in
this case because there is no ambiguity as to which method to call.
> class A {
> method X { ... }
> }
> class B {
> method X { ... }
> }
> class C is A is B {
> ...
> }
> Making that a fatal error looks great on paper, but what if B::X was
> added in the latest version of B.pm? Do you really want a *fatal* error
> to appear on machines that upgrade B, but not those that don't? Do you
> have any idea what a nightmare that would be for module writers?
Isn't it more of a nightmare if this is silently accepted?
> A warning to the effect of "Methods A::X and B::X conflict in mutual
> subclass C", deactivatable with both 'no warnings <>' (or something)
> and 'method X is from(A)', would please me much more. The manpage can
> strongly encourage use of 'is from' when there's MI afoot.
> But we're in language territory again. Parrot has to deal with this
> issue in a flexible way, so always emitting a fatal error is simply not
> an option.
It sounds like you already have a plan - I didn't realise about `is from'.
I'll shut up on this subject now :-).
--
Sam Vilain, [EMAIL PROTECTED]
There is more to life than increasing its speed
-- Mahatma Gandhi
RE: Multiple Inheritance eq Interfaces [was: Re: Object spec]
Sam Vilain:
# > Alternatively, the approach taken with MI namespace clashes
# in Perl 5
# > is to let the programmer arrange the inheritance tree as he
# sees fit,
#
# You are right - but this is a different condition. There is
# no error in
# this case because there is no ambiguity as to which method to call.
In Perl 5, if there's an A::X and a B::X, the module writer arranges the
inheritance tree to get the one he wants. That's what I'm talking
about. The defined semantics of Perl 5 inheritance resolve the
ambiguity, but it's the module writer's duty to see that they resolve it
*correctly*. :^)
# > Making that a fatal error looks great on paper, but what if
# B::X was
# > added in the latest version of B.pm? Do you really want a *fatal*
# > error to appear on machines that upgrade B, but not those
# that don't?
# > Do you have any idea what a nightmare that would be for module
# > writers?
#
# Isn't it more of a nightmare if this is silently accepted?
Who said it would be silent? I mentioned emitting a warning below. The
module writer will fix the warning, and module users can disable the
warning easily until the new version is out.
# > A warning to the effect of "Methods A::X and B::X conflict
# in mutual
# > subclass C", deactivatable with both 'no warnings <>' (or
# > something) and 'method X is from(A)', would please me much
# more. The
# > manpage can strongly encourage use of 'is from' when
# there's MI afoot.
#
# It sounds like you already have a plan - I didn't realise
# about `is from'.
# I'll shut up on this subject now :-).
Ugh...sorry, that was rabid speculation on my part. I should have made
that more clear. (I do that way too often...)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Re: Object spec
On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote: > Several people have mentioned a desire to see Perl6 and Parrot > facilitate object persistence. Should such issues be tackled in Parrot? Not necessarily. Just be friendly to object persistence frameworks by exporting object relationships in a sensible and consistent manner. It is those relationships that drive the object persistence frameworks, and implementations of the object structure in various languages. The exact semantics and mechanisms of object persistence are still quite a research topic, so it is not appropriate yet to select one method as the best. However, I believe that the concepts of Object, Attribute, Association, Methods are stable. > What does parrot need to facilitate object persistence and > cross-language OO? Obviously the OMG's UML and family of specifications > deal with these issues. What other practical approaches exist? UML does not deal with persistence. It deals with specifying and modelling objects. I think that right now persistence fairly and squarely belongs outside of Parrot :-). -- Sam Vilain, [EMAIL PROTECTED] I dont have any solution, but I certainly admire the problem. ASHLEIGH BRILLIANT
Re: Associations between classes [was: Re: Object spec]
On Thu, 06 Mar 2003 05:40, [EMAIL PROTECTED] wrote: > Seems like you are thinking along the lines of making Parrot support > Prevayler-style > http://www-106.ibm.com/developerworks/web/library/wa-objprev/index.html > stuff naturally and with less coding at the top layer. Is that where you > are headed with > this? The paper appears to me to describe using serialisation of memory structures to achieve persistence, which is another approach entirely. Serialisation is good, but fails for more complicated memory structures. -- Sam Vilain, [EMAIL PROTECTED] The meek shall inherit the earth, but not its mineral rights. J PAUL GETTY
Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]
On Thu, 06 Mar 2003 16:22, Brent Dax wrote:
> Who said it would be silent? I mentioned emitting a warning below. The
> module writer will fix the warning, and module users can disable the
> warning easily until the new version is out.
> # It sounds like you already have a plan - I didn't realise
> # about `is from'.
> # I'll shut up on this subject now :-).
> Ugh...sorry, that was rabid speculation on my part. I should have made
> that more clear. (I do that way too often...)
Well, I for one like this iteration of your speculation.
`is from' would be a bit like `swiss inheritance' (think swiss cheese), or
the *{"foo"} = \&{"X::foo"} Perl 5 idiom.
It would be a clear way for a module author to inherit only the methods
that they desire.
The next question, then is - within the scope of the methods inherited via
`is from', are ALL of the methods of the original object visible, or just
the ones in private scope? If they are in public scope, what if the
derived Class redefines some methods that were effectively obscured, and
the inherited method calls it?
Hmm, I think that would just make it too ugly. If they don't inherit the
methods they need then they'll just have to get a `method not defined'
error.
It just goes to show that MI is an ugly hack compared to using a servant
class. But that is not the point here; the point here is making good MI
semantics.
Sorry, know I said I'd shut up :-) But this is still too interesting ;-)
--
Sam Vilain, [EMAIL PROTECTED]
Seeing a murder on television... can help work off one's antagonisms.
And if you haven't any antagonisms, the commercials will give you
some.
-- Alfred Hitchcock
Re: Object spec
[This came from perl6-internals, and should go back there. Redirect followups appropriately, please] At 11:58 PM +1300 3/4/03, Sam Vilain wrote: Dan, Sorry if I'm flogging a dead horse, but I just caught this call via the summarizer. Okay, here's another shot at the semantics for objects [for perl 6]. If folks, especially non-perl folks, would look this over and chime in, I'd much appreciate it. Objects have (all optional): *) Properties *) Methods *) Attributes Add to that: *) A superclass (obviously, but I consider it to be the same level as Properties, Methods and Attributes.) *) Associations, eg in UML. *) a set of Interfaces (similar to multiple inheritance; a way of grouping methods associated with a class for another to implement). eg, in Java and IDL. Well... no. Besides this really being something for discussion on perl6-internals (so if everyone'd move this over there, please, and my followups will go there from now on) what you've bulleted are all properties of the class, not the object. I was only dealing with what the object presents to user code, not in how the classes behave. Taking these in turn, though: *) Property on classes, not objects, but yes we'll have superclasses. *) We're not talking perl 5 style objects, rather objects as fundamental things with attributes. Associations, from what I can see from your description, don't really apply. *) We'll be having a "does" as well as "is" (inheritance) and "has" (delegation) lists for classes, so interfaces will be queryable if the language building the class supports them. Are you going to implement the concept of `scope' of methods/attributes? Many other languages have it, and I think in some circumstances it can help clarify the intent of code. Of course anally requiring it to be specified ends up with a language like Java :-). Yeah, with nested namespaces for searching. It'll kill method caches in some cases, I think, without some fancy internal footwork, so the performance will probably blow chunks to start. My humble opinion is that `public' attributes should just be implemented in terms of automatically generated accessor functions. That's not parrot's call--we don't care. If a language wants to expose, it should explicitly (to parrot) expose. Whether the user sees it, or how the user sees it, is syntax, and I don't do syntax. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Object spec
At 10:10 AM -0600 3/5/03, Garrett Goebel wrote: Several people have mentioned a desire to see Perl6 and Parrot facilitate object persistence. Should such issues be tackled in Parrot? To some extent, yes. (And as such this is CC'd to both p6l and p6i, but discussion really belongs in p6i) There's a freeze and thaw vtable entry for PMCs, and I've got sketches of necessary core functionality to make it fesable. At some point I'll get it down in electrons and fire it to p6i for hashing out. Basically we delegate to the PMC's code and let it do what it needs to. Standard serializers will be provided for mostly-passive variables, which should cover most common cases, while still allowing escapes for funkier (serializing file handles, sockets, or DB connections) cases. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec
On Thu, 06 Mar 2003 06:01, Dan Sugalski wrote: > *) We're not talking perl 5 style objects, rather objects as > fundamental things with attributes. Associations, from what I can see > from your description, don't really apply. I was talking about objects as fundamentals, too. I was just using Perl 5 syntax to illustrate. Perhaps I should use UML instead: +---+ | File | +---+ * | name: string |<--+ +---+ | +---,---+ | / \ | contents /___\ | | | +---+ 1 | | Directory |<*>+ +---+ Here we see a one to many relationship called `contents' between Classes Directory and File, as well as an `is a' relationship of Directory and file. It is composite, indicating that Directory objects are composed of files. Associations *are* fundamental object things. Presenting them in terms of attributes is the real hack. -- Sam Vilain, [EMAIL PROTECTED] It is necessary for me to establish a winner image. Therefore, I have to beat somebody. RICHARD M NIXON
