Classes as Packages (was: Harvesting infrastructure)
Nathanael Schärli
n.schaerli at gmx.net
Tue Nov 19 16:33:39 UTC 2002
Andreas
Thanks very much for your input!
> BTW, I'm really looking forward to trying the traits out
> myself. Not that I want to put any pressure on you, of course ;-)))
I got the message. Let's hope for a couple of rainy days... ;)
Nathanael
PS: I wrote a long email explaining the major difference between MI and
Traits in the reply to Anthony. It could be intersting to get a better
feeling for Traits and why I think they will be accepted by most
programmers even though MI was not.
> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> Behalf Of Andreas.Raab at gmx.de
> Sent: Monday, November 18, 2002 9:32 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Classes as Packages (was: Harvesting infrastructure)
>
>
> Hi Nathanael,
>
> I just did a quick glance over the paper and perhaps I'm
> wrong but I'm missing a point about refactoring. Why is this
> important?! Well, in a large number of cases code reuse does
> not come from the initial design but rather somewhere down
> the road when we see similarities in concepts that really
> should be represented by a common one. Traits seem to be a
> very nice solution to that problem as well since (I think)
> they have very elegant ways of reifying those concepts and
> make them readily accessible.
>
> BTW, I'm really looking forward to trying the traits out
> myself. Not that I want to put any pressure on you, of course ;-)))
>
> Cheers,
> - Andreas
>
> > Tim,
> >
> > I agree with you. Your critics on MI is just about what
> inspired us to
> > do the Traits work. Have a look at the latest draft of the Traits
> > paper
> >
> (http://www.iam.unibe.ch/~schaerli/traits_draft/traitsDraft.pd
> f) and you
> > will find a detailed description of good reasons why MI
> ddidn't make it
> > into recent languages. I hope that Traits are going to be more
> > successful ;)
> >
> > Nathanael
> >
> > > -----Original Message-----
> > > From: squeak-dev-admin at lists.squeakfoundation.org
> > > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> > > Behalf Of Tim Rowledge
> > > Sent: Monday, November 18, 2002 7:38 PM
> > > To: squeak-dev at lists.squeakfoundation.org
> > > Subject: Re: Classes as Packages (was: Harvesting infrastructure)
> > >
> > >
> > >
> > > > > And anyone that starts going on about multiple inheritance is
> > > > > looking for a visit from one of the four horsement of the
> > > > > apologists. :-)
> > > >
> > > > I think this is a myth of multiple inheritance. I
> think it can be
> > > > tamed and used effectively. See above.
> > > Lots of people have tried to convince of that in the last
> > > twenty years and so far not a one has made a good enough case
> > > to change my mind. It is certainly possible you may be the
> > > first but don't hold your breath too long!
> > >
> > > One of the classic old claims for MI was along the lines of -
> > > well, I have implemented Toy and Truck and now I want a toy
> > > truck so I should be able to inherit from both. Yippee, it's
> > > obvious! BZZZZZZ.
> > >
> > > Firstly, like many occasions where people make claims
> > > congurent to this, it's a bad example. Truck, if implemented
> > > in any serious manner, will have a great deal of state and
> > > behaviour that is nothing whatosever to do with toy trucks.
> > > Do toy trucks need to know about, say, service schedules,
> > > fuel consumption, tyre pressure et al.? I doubt it. It's
> a bad mix.
> > >
> > > Secondly, I've never yet been convinced that any proposed
> > > implementation of MI can handle the tangle of possible
> > > inheritance upstream. Where and how should one decide which
> > > of the possible upward paths to follow? If following one path
> > > leads to a DNU should you try another? And another? I think
> > > it is easy to see a pretty nasty O(something horrible)
> > > problem here. How would one specify which path to use it if
> > > it supposed to be decided by the programmer? The old ST-80 MI
> > > experiment used munged selectors, something like 'self
> > > truck.size' which looked 'orrible. And probably allowed
> > > something like 'self number.wibble' whcih wuldbe nonsensical.
> > >
> > > Thirdly, it always seems more plausible to me to use
> > > composition/delgation. ToyTruck would be a little better if
> > > implemented as having a toy-ness ivar and a truck-ness ivar
> > > and then _using_ them rather than inheriting them. I imagine
> > > that this maps onto Traits reasonably well from my current
> > > understanding. I would concur however that making it possible
> > > to subclass traits would be (probably) useful; but let's not
> > > go into whether traits should have trairts, at least just yet.
> > >
> > > tim
> > > --
> > > Tim Rowledge, tim at sumeru.stanford.edu,
> > > http://sumeru.stanford.edu/tim Useful > random insult:- He
> > > donated his brain to science but they made an early withdrawal.
> > >
> > >
> >
> >
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
>
>
More information about the Squeak-dev
mailing list
|