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

[squeak-dev] Unload Traits script


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

El 5/12/08 5:01 PM, "Jerome Peace" <[hidden email]> 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

2008/5/12, Edgar J. De Cleene <[hidden email]>: 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

El 5/13/08 2:13 AM, "Philippe Marschall" <[hidden email]>
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

2008/5/13 Edgar J. De Cleene <[hidden email]>: I think you underestimate the effort that went into 3.9.

Cheers
Philippe

El 5/13/08 6:27 AM, "Philippe Marschall" <[hidden email]>
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

2008/5/13 Edgar J. De Cleene <[hidden email]>: It's not about respect. It's about months of pain to load Traits into
an image with Monticello.

Cheers
Philippe

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

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

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 .

...

El 5/13/08 7:45 AM, "Trygve Reenskaug" <[hidden email]> escribió:


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

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

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

"Andreas Raab" <[hidden email]> 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

itsme213 wrote:
> "Andreas Raab" <[hidden email]> 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

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.

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

On 14.05.2008 16:21, itsme213 wrote:

"Andreas Raab" [hidden email] 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

On 14.05.2008 16:41, Andreas Raab wrote:

itsme213 wrote:

"Andreas Raab" [hidden email] 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

Why not indeed?  I've better get my act together so that we can get a solid foundation for a constructive discussion, haven't I?
Cheers
--Trygve

Trygve Reenskaug wrote:
I don't want to rush you so do take your time but I am very much looking
forward to see what you're working on. It sounds like it may be a very
novel application of traits so I'm curious to learn more about it.

Cheers,
   - Andreas

"Trygve Reenskaug" <[hidden email]> wrote in message

> 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.

This mapping of role to trait is quite intuitively appealing.

However, since
- traits are applied statically, not dynamically
and
- trait callbacks to the object (required methods) are hardcoded in the
trait definition itself with no way to rename (only alias)

Wouldn't it be quite difficult to handle the more general cases of dynamic
roles, and of multiple roles of the same role type (e.g. I am a programmer
on projects p1 and p2)?

In these casees would you revert to using separate role-objects? e.g. a
Person class with a iVar that is a collection of role-like objects, one for
"programmer-on-p1" and one for "programmer-on-p2"?

Curious - Sophie