[squeak-dev] Unload Traits script (response to edgar)

[Jerome Peace]

[squeak-dev] Unload Traits script

>Edgar J. De Cleene edgardec2001 at yahoo.com.ar
>Sat May 10 22:23:24 UTC 2008
>
>El 5/10/08 5:58 PM, "Jerome Peace" <peace_the_dreamer at yahoo.com> escribió:
>
>>> Matthew Fulmer tapplek at gmail.com
>>> Sat May 10 19:18:47 UTC 2008
>>>
>>>
>>> I wrote a script that removes traits from a 3.9 or 3.8 image:
>>><...>
>>> Installer install: 'UnloadTraits'
>>> <...>
>>
>> Ok. Then what does this give you?
>>
>> If you had such an image could you use it as a basis for development?
>><...>
>> This is different from the question of should it be. That also is important
>to
>> answer. But the "should"
>> question is a political one. I'm just looking for the technical answer to
>the
>> "could" questions.
>><...>
>
>Well , 3.11 could not have Installer or any 3.8 don't have.

Huh? This does not sound right.
Are you saying that without traits you could not have the Installer SM or Universes?

>No SM, no Universes, no etc
>As clean we manage to clean and not putting any.

Not putting any what?

>Less code means less work.

If you change one thing here the you cause changes to other things there.
And you have to get the things there fixed.
So you need to think about what's "there" before you poke at what's "here"
Else you have in the long run more work and less working code.

>more easy to test

How would it be more easy to test?
Indeed how would you test?
And where are the tests that would prove you have not done harm by removing things?
How much time do you estimate it would take to do the cutting? <important question!>

>more easy to improve.

Not unless done carefully. And not unless done with concensus.
Unless others agree this is a good direction we will lose resources (i.e. good coders and helpers)
to other branches like Saphire.
Less work is getting others to help.

>I plan to cut several things , so my first could be Traits.
>It's your picture on Hall of Fame and going back to good track.

A good track for what?

Stef is going to try to entice seaside development into his branch.

IF he succeeds...

what will happen then?

If seaside uses traits and squeak-org squeak does not then:
1) We have a squeak without the seaside users(They will use Sapphire/Pharo)
2) We have a squeak without etoys users (they use a vpri varient of squeak)
3) We have s squeak maybe without a good way to update or maintain.
All we will be left to do is experiment with delta-streams and MC2.

Basicly we are going off you race track and into the woods.

In short and in the form of an Alan Kay question:

"What makes it worthwhile?"

Yours in curiosity and service, --Jerome Peace


      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Edgar J. De Cleene]

El 5/12/08 5:01 PM, "Jerome Peace" <peace_the_dreamer@...> escribió:

> Huh? This does not sound right.
> Are you saying that without traits you could not have the Installer SM or
> Universes?
No.
I saying my wished 3.11 could not have Installer, SM, Universes and many
more.
As I wish 3.11 become more modular.
And people could connect to squeaksource and follow any package they wish
ore need to have in his own image.
Traits is a open issue as each time a flame war arise.
I don't need and don't want Traits.
But if people choose we should have Traits as in 3.10, they have all as is
now.
Or if people found ways of unload without nasty collateral effects and then
other people take the Traits.mcz or some comes with BestTraits.mcz and other
with SuperTraitsBestAsOthersCrap33.1.3.mcz is bad ?

I long know wishes are wishes and reality bits me :=)

Edgar

Calderon de la Barca write "Pues toda la vida es sueño y los sueños, sueños
son" http://www.imagi-nation.com/moonstruck/clsc49.html

[Philippe Marschall]

2008/5/12, Edgar J. De Cleene <edgardec2001@...>:

>
>
>
>  El 5/12/08 5:01 PM, "Jerome Peace" <peace_the_dreamer@...> escribió:
>
>
>  > Huh? This does not sound right.
>  > Are you saying that without traits you could not have the Installer SM or
>  > Universes?
>
> No.
>  I saying my wished 3.11 could not have Installer, SM, Universes and many
>  more.
>  As I wish 3.11 become more modular.
>  And people could connect to squeaksource and follow any package they wish
>  ore need to have in his own image.
>  Traits is a open issue as each time a flame war arise.
>  I don't need and don't want Traits.

That's a personal opinion. There are people who need and want Tratis.

>  But if people choose we should have Traits as in 3.10, they have all as is
>  now.
>  Or if people found ways of unload without nasty collateral effects and then
>  other people take the Traits.mcz or some comes with BestTraits.mcz and other
>  with SuperTraitsBestAsOthersCrap33.1.3.mcz is bad ?

No just really hard and there are the usual questions how you can make
two different versions work together.

Cheers
Philippe

>  I long know wishes are wishes and reality bits me :=)
>
>  Edgar
>
>  Calderon de la Barca write "Pues toda la vida es sueño y los sueños, sueños
>  son" http://www.imagi-nation.com/moonstruck/clsc49.html
>
>
>
>

[Edgar J. De Cleene]

El 5/13/08 2:13 AM, "Philippe Marschall" <philippe.marschall@...>
escribió:

> That's a personal opinion. There are people who need and want Tratis.


Off course, read what I said
>>  But  if people choose we should have Traits as in 3.10, they have all as
is
>  now.

I don't cut any...yet.
And I don't do if Board said this is a bad idea.
And I don't cut if I see any reasonable thing (not a exercise) need Traits
and could not be made without Traits.
And I don't cut if see many people ask for keep Traits .

> No just really hard and there are the usual questions how you can make
two
> different versions work together.

Well , we have several versions of Monticello now, crucial for all.
And people just is discovering this.
And Keith Hodges is doing work in this area.

So I confident my idea of unloading Traits and having Traits.mcz ,
BestTraits.mcz , SuperTraitsBestAsOthersCrap33.1.3.mcz is a better way.

No progress is made without compromises.
The way to heaven is hard and full of obstacles, the way to hell is always
the easier one.

Cheers

Edgar

[Philippe Marschall]

2008/5/13 Edgar J. De Cleene <edgardec2001@...>:

>
>
>
> El 5/13/08 2:13 AM, "Philippe Marschall" <philippe.marschall@...>
> escribió:
>
>> That's a personal opinion. There are people who need and want Tratis.
>
>
> Off course, read what I said
>>>  But  if people choose we should have Traits as in 3.10, they have all as
> is
>>  now.
>
> I don't cut any...yet.
> And I don't do if Board said this is a bad idea.
> And I don't cut if I see any reasonable thing (not a exercise) need Traits
> and could not be made without Traits.
> And I don't cut if see many people ask for keep Traits .
>
>> No just really hard and there are the usual questions how you can make
> two
>> different versions work together.
>
> Well , we have several versions of Monticello now, crucial for all.
> And people just is discovering this.
> And Keith Hodges is doing work in this area.
>
> So I confident my idea of unloading Traits and having Traits.mcz ,
> BestTraits.mcz , SuperTraitsBestAsOthersCrap33.1.3.mcz is a better way.

I think you underestimate the effort that went into 3.9.

Cheers
Philippe

> No progress is made without compromises.
> The way to heaven is hard and full of obstacles, the way to hell is always
> the easier one.
>
> Cheers
>
> Edgar
>
>
>
>

[Edgar J. De Cleene]

El 5/13/08 6:27 AM, "Philippe Marschall" <philippe.marschall@...>
escribió:

> I think you underestimate the effort that went into 3.9.

Cheers
Philippe

Not at all. I have the deep respect for Markus and Stephanne.
Without his work , I couldn't do any 3.10

So I say I don't touch Traits.
All continue as they and others working hard for having we have was.

Peace please, the war is over.

Edgar

[Philippe Marschall]

2008/5/13 Edgar J. De Cleene <edgardec2001@...>:

>
>
>
> El 5/13/08 6:27 AM, "Philippe Marschall" <philippe.marschall@...>
> escribió:
>
>> I think you underestimate the effort that went into 3.9.
>
> Cheers
> Philippe
>
> Not at all. I have the deep respect for Markus and Stephanne.
> Without his work , I couldn't do any 3.10

It's not about respect. It's about months of pain to load Traits into
an image with Monticello.

Cheers
Philippe

> So I say I don't touch Traits.
> All continue as they and others working hard for having we have was.
>
> Peace please, the war is over.
>
> Edgar
>
>
>
>
>

[Klaus D. Witzel]

On Tue, 13 May 2008 11:37:32 +0200, Philippe Marschall wrote:

> 2008/5/13 Edgar J. De Cleene wrote :
>>
>> El 5/13/08 6:27 AM, "Philippe Marschall" escribió:
>>
>>> I think you underestimate the effort that went into 3.9.
>>
>> Cheers
>> Philippe
>>
>> Not at all. I have the deep respect for Markus and Stephanne.
>> Without his work , I couldn't do any 3.10
>
> It's not about respect. It's about months of pain to load Traits into
> an image with Monticello.

Aha. Everything has a good side, said my Grammy. What would the traits  
team make different, with such experience in mind? Anything that could be  
learned to fullfil my Grammy's statement?

/Klaus

> Cheers
> Philippe
>
>> So I say I don't touch Traits.
>> All continue as they and others working hard for having we have was.
>>
>> Peace please, the war is over.
>>
>> Edgar
>>
>>
>>
>>
>>

[Trygve Reenskaug]

Some parts of this message have been removed. Learn more about Nabble's security policy.

IMO, traits are fundamental and essential.

In the new BabyUML programming paradigm, a CLASS defines what an object IS as seen from its inside and a ROLE defines what an object DOES as seen from its outside.

It was a major breakthrough when I realized that a role should be coded as a trait, the trait defining what the object does in the context of a structure of collaborating, role playing objects.

A role is played by an object at run time. This object can be an instance of any class that implements its trait. So the trait is tied to a fundamental abstraction that is on the same level as the class.

I both look forward to and dread my publication of the first Baby IDE. Will it start a constructive discussion, will it be slaughtered, or will it be ignored?

With trepidation
--Trygve


On 13.05.2008 11:09, Edgar J. De Cleene wrote:

I don't cut any...yet.
And I don't do if Board said this is a bad idea.
And I don't cut if I see any reasonable thing (not a exercise) need Traits
and could not be made without Traits.
And I don't cut if see many people ask for keep Traits .

...

[Edgar J. De Cleene]

El 5/13/08 7:45 AM, "Trygve Reenskaug" <trygver@...> escribió:

> IMO, traits are fundamental and essential.
>
> In the new BabyUML programming paradigm, a CLASS defines what an object IS as
> seen from its inside and a ROLE defines what an object DOES as seen from its
> outside.
>
> It was a major breakthrough when I realized that a role should be coded as a
> trait, the trait defining what the object does in the context of a structure
> of collaborating, role playing objects.
>
> A role is played by an object at run time. This object can be an instance of
> any class that implements its trait. So the trait is tied to a fundamental
> abstraction that is on the same level as the class.
>
> I both look forward to and dread my publication of the first Baby IDE. Will it
> start a constructive discussion, will it be slaughtered, or will it be
> ignored?
>
> With trepidation
> --Trygve

So , this close all I said before.
I always have you as example, and your works as some essential.
It's why I have Baby SRE always on any "Full" or "Fun" image.

So sorry to all, I never speak again of Traits and DON'T support cutting
Traits.

Period.

Edgar

PS. And I read about the tree planted to 95 age, that is a example of Life

[Craig Latta]

Hi Edgar--

 > I [haven't cut anything]... yet. And I [won't cut Traits] if [the]
 > Board [says] this is a bad idea.

      With all due respect, the board has not yet chosen the next
release team. A person from a past release team will not necessarily be
on a future team.


      thanks,

-C

[Andreas Raab]

Trygve Reenskaug wrote:
> A role is played by an object at run time. This object can be an
> instance of any class that implements its trait. So the trait is tied to
> a fundamental abstraction that is on the same level as the class.

Interesting. But aren't you describing interfaces? I agree that
interfaces which describe the protocol required by a role can be a
useful; I am not convinced that traits (which are effectively used as
the implementation itself) are nearly as helpful in this context.

> I both look forward to and dread my publication of the first Baby IDE.
> Will it start a constructive discussion, will it be slaughtered, or will
> it be ignored?

I've been curious for a while now to see applications of traits and I'm
still waiting for one that convinces me they're worth the hazzles that
come along with it. I'm looking forward to seeing what you've done.

Cheers,
   - Andreas

[Sophie2]

"Andreas Raab" <andreas.raab@...> wrote in
> Trygve Reenskaug wrote:
>> A role is played by an object at run time. This object can be an instance
>> of any class that implements its trait. So the trait is tied to a
>> fundamental abstraction that is on the same level as the class.
>
> Interesting. But aren't you describing interfaces?

The role itself is better compared to a variable than to an interface. The
corresponding trait can provide an interface definition, as well as an
implementation that refers to other related roles. I think Trygve figured
out a way to extend the compiler so that the method bodies (typically in
traits, I expect) can use distinguished "Role variables", which the compiler
translated into a dynamic lookup query.

My 2c guesses :-)

Sophie

[Andreas Raab]

itsme213 wrote:
> "Andreas Raab" <andreas.raab@...> wrote in
>> Trygve Reenskaug wrote:
>>> A role is played by an object at run time. This object can be an instance
>>> of any class that implements its trait. So the trait is tied to a
>>> fundamental abstraction that is on the same level as the class.
>> Interesting. But aren't you describing interfaces?
>
> The role itself is better compared to a variable than to an interface.

Do you mean something like (for example) the "bounds role" or the "fill
role" for Morphs? If not, then I don't understand what roles mean in
this context.

> The  corresponding trait can provide an interface definition, as well as an
> implementation that refers to other related roles.

It can but if it's to provide the implementation you end up with
complexity explosion again since the dependencies will be implemented by
other traits, which will require even more traits etc. By the end of the
day there will only be a handful of suitable compositions of traits that
result in something usable (which is exactly what we've seen in other
applications of traits) and these few compositions usually can be better
expressed without traits.

The idea that having traits require other traits for their
implementation leads to flexibility is flawed. Flexibility results from
having abstract interfaces which allow (and sometimes require) the
implementor of the interface to go only by the observable structure and
not rely on anything that just happens to be part of the implementation.
Traits have been constantly used the other way around by requiring the
users of one trait also to pull in all the garbage that comes along with
the implementation of that trait.

> I think Trygve figured
> out a way to extend the compiler so that the method bodies (typically in
> traits, I expect) can use distinguished "Role variables", which the compiler
> translated into a dynamic lookup query.

That will be interesting to see. Although, I can't help but wonder: Why
not simply bundle up these "role variables" and their corresponding
behaviors and call 'em "object"? In which case you'd represent them by a
class, having access to all the state in one place, being able to
encapsulate its behavior etc.

Cheers,
   - Andreas

[Ryan Mitchley]

I need to be convinced otherwise, but it seems that traits are a form of multiple inheritance that looks good on the surface, but turns out to be ill-conceived and inferior to other design methods.

Among collaborating agents, one is only concerned that a given agent provides set of necessary/desirable methods or behaviours. This may be fully provided, especially in a highly reflective language, as meta-information about an instance's methods. This could be a method in itself. i.e. an instance's traits are dynamically calculated as meta-information about its methods. There is no need to make this a first-class, inheritance type abstraction.

However, the set of an instance's methods in a single-inheritance language is basically a function of its class, which leaves me wondering why this is at all necessary.

[Trygve Reenskaug]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 14.05.2008 13:01, Andreas Raab wrote:

Trygve Reenskaug wrote:

A role is played by an object at run time. This object can be an instance of any class that implements its trait. So the trait is tied to a fundamental abstraction that is on the same level as the class.

Interesting. But aren't you describing interfaces? I agree that interfaces which describe the protocol required by a role can be a useful; I am not convinced that traits (which are effectively used as the implementation itself) are nearly as helpful in this context.

No, I am describing the methods that drive the object interaction.
--Trygve

[Trygve Reenskaug]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 14.05.2008 16:21, itsme213 wrote:

"Andreas Raab" andreas.raab@... wrote in
  

Trygve Reenskaug wrote:
    

A role is played by an object at run time. This object can be an instance 
of any class that implements its trait. So the trait is tied to a 
fundamental abstraction that is on the same level as the class.
      

Interesting. But aren't you describing interfaces?
    

The role itself is better compared to a variable than to an interface. The 
corresponding trait can provide an interface definition, as well as an 
implementation that refers to other related roles. I think Trygve figured 
out a way to extend the compiler so that the method bodies (typically in 
traits, I expect) can use distinguished "Role variables", which the compiler 
translated into a dynamic lookup query.

My 2c guesses :-)

Sophie
  

Exactly, that's what I am doing.
--Trygve