Multiple classifications of an object
When you blass an object in Perl, you give it exactly one type. The @ISA variable allows that type to refer to many other classes as the inheritance tree. @ISA is a list, but ref($obj) isn't. This means that you sometimes have to create a lot of useless classes to work around this limitation. A simple example: Imagine you have a class "Person". A Person can be Male or Female. Thats one set of subclasses. But a Person can also be Employed or Unemployed. So I might want to say bless $self, qw(Employed Male); In Perl5 I am forced to create 4 new classes: Employed_Male, Employed_Female, Unemployed_Male, Unemployed_Female. The combinatorial explosion can, well, explode! The other standard solution is to add a "Person has-a Employment_Status" relationship, but that doesn't feel much better. Its just another way of programming round a weakness in the object models of most mainstream languages Can anyone see any problems with making C and C work with lists? C is not effected. We might want some magic to ensure 'ref($foo) eq "bar"' still works as expected. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Multiple classifications of an object
At 11:44 AM 6/25/01 -0700, David Whipp wrote: >When you blass an object in Perl, you give it exactly >one type. The @ISA variable allows that type to refer >to many other classes as the inheritance tree. @ISA >is a list, but ref($obj) isn't. This means that you >sometimes have to create a lot of useless classes to >work around this limitation. > >A simple example: Imagine you have a class "Person". >A Person can be Male or Female. Thats one set of >subclasses. But a Person can also be Employed or >Unemployed. So I might want to say > >bless $self, qw(Employed Male); > >In Perl5 I am forced to create 4 new classes: >Employed_Male, Employed_Female, Unemployed_Male, >Unemployed_Female. The combinatorial explosion can, >well, explode! The other standard solution is to >add a "Person has-a Employment_Status" relationship, >but that doesn't feel much better. Its just another >way of programming round a weakness in the object >models of most mainstream languages > >Can anyone see any problems with making C and >C work with lists? C is not effected. We >might want some magic to ensure 'ref($foo) eq "bar"' >still works as expected. What's wrong with multiple inheritance? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
RE: Multiple classifications of an object
Peter Scott wrote: > What's wrong with multiple inheritance? You have to create a whole load of extra classes whose only purpose is to define a list of superclasses. Compare: bless $self, qw(Employed Male); with package Employed_Male; @ISA=qw(Employed Male); # multiple inheritance ... bless $self, "Employed_Male"; Allowing C and C to use lists allows me to be slightly more Lazy. In bigger hierarchies, the benefits are greater because the number of possible leaf classes is greater. (Imagine Employed as subclasses of FullTime and PartTime; then add in race, ethnicity, ...) Some people would argue that these things are attributes, not base classes; but those same people would argue that multiple inheritance is bad. I'm not objecting to multiple inheritance: I just saying that its a waste of effort to create classes that don't add any new details. If the class that combines multiple superclasses adds unique behaviour/data to that combination, then multiple inheritance is the correct solution. When all you are doing is saying that an object has 2 classes then forcing the extra work is just a waste of time. Dave.
Re: Multiple classifications of an object
At 12:05 PM 6/25/2001 -0700, Peter Scott wrote: >At 11:44 AM 6/25/01 -0700, David Whipp wrote: >>Can anyone see any problems with making C and >>C work with lists? C is not effected. We >>might want some magic to ensure 'ref($foo) eq "bar"' >>still works as expected. > >What's wrong with multiple inheritance? Nothing, but he wants MI on a per-object basis, rather than a per-class basis, presumably to avoid having to create a zillion classes who's sole purpose in life is to have an @ISA array. Sounds sensible, and worth sending past Damian. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multiple classifications of an object
> >What's wrong with multiple inheritance?
>
> Nothing, but he wants MI on a per-object basis, rather than a per-class
> basis, presumably to avoid having to create a zillion classes who's sole
> purpose in life is to have an @ISA array.
>
> Sounds sensible, and worth sending past Damian.
It's certainly not unreasonable, though it doesn't mesh perfectly with
Perl's OO model. The easy solution (available in Perl 5 too) is to
autogenerate the interim MI-ing classes as needed:
my $next = "a";
sub multibless {
my ($ref, @classes) = @_;
my $MIclass = "_MI_class_$next";
$next++;
@{$MIclass."::ISA"} = @classes;
bless $ref, $MIclass;
}
# and later:
my $schimmer = multibless {}, qw(Dessert_Topping Floor_Wax);
But one could also imagine that Perl 6 might allow individual objects to
have an C property that pre-empted their class's C<@ISA> array.
Damian
Re: Multiple classifications of an object
On Mon, Jun 25, 2001 at 11:44:06AM -0700, David Whipp quoth: > We might want some magic to ensure 'ref($foo) eq "bar"' > still works as expected. ref($foo) could be any(@ISA) .g -- Writing code on one line is like playing the trumpet without breathing! -Adam Pisoni
Re: Multiple classifications of an object
On Mon, Jun 25, 2001 at 12:47:41PM -0700, David Whipp wrote:
>> What's wrong with multiple inheritance?
> You have to create a whole load of extra classes whose only
> purpose is to define a list of superclasses. Compare:
This sounds a lot like the case I had with a
content-syndication system I'm
working on.
Basically, I wanted to create a Feed-object that inherits from any
Fetch-class and any Parse-class. Something like this:
bless $obj1, qw/Fetch::LWP Parse::HTML/;
bless $obj2, qw/Fetch::POP3 Parse::CSV/;
but then I realized that since the Fetch and Parse-classes never diddled
with $self, I didn't need inheritance at all. Delegation was more than
good enough in my case.
I ended up with something like this (simplified a bit):
package Feed;
sub new {
my $class = shift;
my %args = @_;
my $f = $args{FETCH}->new;
my $p = $args{PARSE}->new;
bless {FETCH => $f, PARSE => $p} => $class;
}
sub fetch {
my $self = shift;
return $self->{FETCH}->fetch(@_);
}
sub parse {
my $self = shift;
return $self->{PARSE}->parse(@_);
}
sub cleanup {
my $self = shift;
$self->{FETCH}->cleanup(@_);
$self->{PARSE}->cleanup(@_);
}
etc..
which works very well.
The downside is of course that I need to make a small stub for every
single function I want to delegate. Since it's only a few function I
need from the classes, it's not a big problem. If you have 50 functions
in each class, it could be a hassle.
I haven't given it much thought, but I imagine the cleanup-method could
be difficoult to implement with inheritance.
I don't know if delegation is the solution in your case though. And I
certainly can't claim that it is the solution in every "multibless"
case. But it worked for me :)
--
Trond Michelsen
