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