The Inbox: Traits-pre.307.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The Inbox: Traits-pre.307.mcz

commits-2
A new version of Traits was added to project The Inbox:
http://source.squeak.org/inbox/Traits-pre.307.mcz

==================== Summary ====================

Name: Traits-pre.307
Author: pre
Time: 20 November 2015, 2:58:26.562 pm
UUID: f0955b2d-775c-4862-85b9-5d6e616cd2e4
Ancestors: Traits-eem.306

This fixes http://bugs.squeak.org/view.php?id=7767 which is about the - and @ operator of Trait compositions ignoring brackets. This implementation uses the normal left to right evaluation order of Smalltalk to avoid confusions about the way trait composition expressions are evaluated.

=============== Diff against Traits-eem.306 ===============

Item was changed:
  ----- Method: TraitAlias>>printOn: (in category 'operations') -----
  printOn: s
  "Answer the trait composition string (used for class definitions)"
+ s nextPutAll: '('.
  s nextPutAll: subject asString.
  s nextPutAll: ' @ {'.
  aliases do:[:assoc| s print: assoc] separatedBy:[s nextPutAll:'. '].
  s nextPutAll: '}'.
+ s nextPutAll: ')'.!
- !

Item was changed:
  ----- Method: TraitComposition>>- (in category 'converting') -----
  - anArray
- "the modifier operators #@ and #- bind stronger than +.
- Thus, #@ or #- sent to a sum will only affect the most right summand"
 
+ self updateTraits: (self traitsCollect: [:aTrait | aTrait - anArray ])!
- self addLast: (self removeLast - anArray)!

Item was changed:
  ----- Method: TraitComposition>>@ (in category 'converting') -----
  @ anArrayOfAssociations
+
+ self updateTraits: (self traitsCollect: [:aTrait | aTrait @ anArrayOfAssociations ])!
- "the modifier operators #@ and #- bind stronger than +.
- Thus, #@ or #- sent to a sum will only affect the most right summand"
-
- self addLast: (self removeLast @ anArrayOfAssociations)!

Item was added:
+ ----- Method: TraitComposition>>traitsCollect: (in category 'accessing') -----
+ traitsCollect: aBlock
+ ^self collect: [:each| each traitsDo: aBlock]!

Item was changed:
  ----- Method: TraitComposition>>traitsDo: (in category 'accessing') -----
  traitsDo: aBlock
+ ^self do: [:each| each traitsDo: aBlock]!
- ^self do:[:each| each traitsDo: aBlock]!

Item was added:
+ ----- Method: TraitComposition>>updateTraits: (in category 'converting') -----
+ updateTraits: aCollection
+
+ self
+ removeAll;
+ addAll: aCollection!

Item was changed:
  ----- Method: TraitExclusion>>printOn: (in category 'composition') -----
  printOn: aStream
  "Answer the trait composition string (used for class definitions)"
+ aStream nextPutAll: '('.
  aStream nextPutAll: subject asString.
  aStream nextPutAll: ' - {'.
  exclusions asArray sort do:[:exc| aStream store: exc] separatedBy:[aStream nextPutAll: '. '].
+ aStream nextPutAll: '}'.
+ aStream nextPutAll: ')'.!
- aStream nextPutAll: '}'.!


Reply | Threaded
Open this post in threaded view
|

AW: [squeak-dev] The Inbox: Traits-pre.307.mcz

Patrick R.
I want to add some more reasoning to this commit. The commit is intended to fix this issue: http://bugs.squeak.org/view.php?id=7767

My implementation is based on the corresponding Pharo Traits implementation, except for the TraitsComposition>>#printOn: implementation. Do you think it is worth also recreating that behavior?

In general, the most important thing regarding this change is, that this might break older .st or .cs files containing Traits definitions based on the old evaluation order.

Bests
Patrick
________________________________________
Von: [hidden email] <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Freitag, 20. November 2015 09:52
An: [hidden email]
Betreff: [squeak-dev] The Inbox: Traits-pre.307.mcz

A new version of Traits was added to project The Inbox:
http://source.squeak.org/inbox/Traits-pre.307.mcz

==================== Summary ====================

Name: Traits-pre.307
Author: pre
Time: 20 November 2015, 2:58:26.562 pm
UUID: f0955b2d-775c-4862-85b9-5d6e616cd2e4
Ancestors: Traits-eem.306

This fixes http://bugs.squeak.org/view.php?id=7767 which is about the - and @ operator of Trait compositions ignoring brackets. This implementation uses the normal left to right evaluation order of Smalltalk to avoid confusions about the way trait composition expressions are evaluated.

=============== Diff against Traits-eem.306 ===============

Item was changed:
  ----- Method: TraitAlias>>printOn: (in category 'operations') -----
  printOn: s
        "Answer the trait composition string (used for class definitions)"
+       s nextPutAll: '('.
        s nextPutAll: subject asString.
        s nextPutAll: ' @ {'.
        aliases do:[:assoc| s print: assoc] separatedBy:[s nextPutAll:'. '].
        s nextPutAll: '}'.
+       s nextPutAll: ')'.!
- !

Item was changed:
  ----- Method: TraitComposition>>- (in category 'converting') -----
  - anArray
-       "the modifier operators #@ and #- bind stronger than +.
-       Thus, #@ or #- sent to a sum will only affect the most right summand"

+       self updateTraits: (self traitsCollect: [:aTrait | aTrait - anArray ])!
-       self addLast: (self removeLast - anArray)!

Item was changed:
  ----- Method: TraitComposition>>@ (in category 'converting') -----
  @ anArrayOfAssociations
+
+       self updateTraits: (self traitsCollect: [:aTrait | aTrait @ anArrayOfAssociations ])!
-       "the modifier operators #@ and #- bind stronger than +.
-       Thus, #@ or #- sent to a sum will only affect the most right summand"
-
-       self addLast: (self removeLast @ anArrayOfAssociations)!

Item was added:
+ ----- Method: TraitComposition>>traitsCollect: (in category 'accessing') -----
+ traitsCollect: aBlock
+       ^self collect: [:each| each traitsDo: aBlock]!

Item was changed:
  ----- Method: TraitComposition>>traitsDo: (in category 'accessing') -----
  traitsDo: aBlock
+       ^self do: [:each| each traitsDo: aBlock]!
-       ^self do:[:each| each traitsDo: aBlock]!

Item was added:
+ ----- Method: TraitComposition>>updateTraits: (in category 'converting') -----
+ updateTraits: aCollection
+
+       self
+               removeAll;
+               addAll: aCollection!

Item was changed:
  ----- Method: TraitExclusion>>printOn: (in category 'composition') -----
  printOn: aStream
        "Answer the trait composition string (used for class definitions)"
+       aStream nextPutAll: '('.
        aStream nextPutAll: subject asString.
        aStream nextPutAll: ' - {'.
        exclusions asArray sort do:[:exc| aStream store: exc] separatedBy:[aStream nextPutAll: '. '].
+       aStream nextPutAll: '}'.
+       aStream nextPutAll: ')'.!
-       aStream nextPutAll: '}'.!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

timrowledge
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?

Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IG: Insert Garbage



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Levente Uzonyi-2
On Fri, 20 Nov 2015, tim Rowledge wrote:

> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?

I always considered Traits to be a weak concept. IMHO with less effort,
one could have created a stateful deterministic mixin system which would
have been superior to Traits.

Andreas has replaced the original Traits implementation with his own
"NanoKernel" variant. It's probably the simplest thing that can be
considered as Traits.

If you need tools, then you'll have to look somewhere else. The Pharo guys
might have come up with something over the years.

I think only Pharo and some related projects use Traits, but even there
the use-cases are extremely limited.

>
> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

Backwards compatibility is the only reason for it to be in the image. In
the 4.1 release, it was unloadable. We should check whether it still is.
Sadly I have to agree with you on the rest, too.


Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IG: Insert Garbage
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Karl Ramberg
In reply to this post by timrowledge


On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge <[hidden email]> wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?

Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction.  
And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.

If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.

Best,
Karl

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IG: Insert Garbage






Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Nicolas Cellier
Concerning Traits I would keep them in trunk for these reasons:
- if the package is not in trunk it will rapidly rot
- this package can extend cross compatibility with Pharo a bit further
I don't know which package really use them though, but that's my feeling

2015-11-20 20:18 GMT+01:00 karl ramberg <[hidden email]>:


On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge <[hidden email]> wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?

Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction.  
And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.

If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.

Best,
Karl

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IG: Insert Garbage










Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

marcel.taeumel
In reply to this post by timrowledge
cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

cbc
I used them while building up some COBOL software analysis code


I've considered using them elsewhere, but the tools deficit is an issue, yes.   You CAN work around the issue with the current tools - it's just not as nice as using the rest of the language.

--cbc

On Fri, Nov 20, 2015 at 12:51 PM, marcel.taeumel <[hidden email]> wrote:
I like traits. I use them for documenting extension points/interfaces:

https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViObjectView.trait
https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViMemento.trait

Please keep them in the image.

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862318.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Chris Muller-3
In reply to this post by timrowledge
On Fri, Nov 20, 2015 at 12:40 PM, tim Rowledge <[hidden email]> wrote:
> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
>
> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

+1.  +1.  +1 and, +1.  Doing the most with the least is the most
beautiful and admirable aspect of Squeak.  Six reserved words,
assignment, and sending messages to objects.  That's pretty much it.
Those concepts alone form the building blocks of the entire IDE, and
still able to push the language with clever hacks like Mixins,
Generators, Promises, Futures, WriteBarriers, and Continuations.

Traits, Slots, Islands, Environments and Pragmas never convinced me
that they deserve to be part of a language this wonderfully sparse.

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

marcel.taeumel
The then trade-off would be to make them unloadable, right? ;) Just like anyone can unload *-Deprecated packages. This simplifies maintenance.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Robert Hirschfeld
In reply to this post by Nicolas Cellier
I would like island to stay also. To me, they are one of the most interesting additions to our base over the recent years. (We use them in Archipelago [*]...)

Best,
Robert

[*] http://www.hpi.uni-potsdam.de/swa/publications/media/SecklerHirschfeld_2014_ArchipelagoAResearchPlatformForComponentInteractionInDistributedApplications_AuthorsVersion.pdf


> On 20 Nov 2015, at 21:54, Nicolas Cellier <[hidden email]> wrote:
>
> Concerning Traits I would keep them in trunk for these reasons:
> - if the package is not in trunk it will rapidly rot
> - this package can extend cross compatibility with Pharo a bit further
> I don't know which package really use them though, but that's my feeling
>
> 2015-11-20 20:18 GMT+01:00 karl ramberg <[hidden email]>:
>
>
> On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge <[hidden email]> wrote:
> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
>
> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
>
> Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction.  
> And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.
>
> If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.
>
> Best,
> Karl
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IG: Insert Garbage
>
>
>
>
>
>
>
>
>



--
Robert Hirschfeld
[hidden email]
www.hirschfeld.org


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

David T. Lewis
In reply to this post by marcel.taeumel
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
> The then trade-off would be to make them unloadable, right? ;) Just like
> anyone can unload *-Deprecated packages. This simplifies maintenance.
>

Right. Making these packages reloadable is a very good idea. The idea of
just deleting them seems rather unhelpful to me.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Karl Ramberg


On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis <[hidden email]> wrote:
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
> The then trade-off would be to make them unloadable, right? ;) Just like
> anyone can unload *-Deprecated packages. This simplifies maintenance.
>

Right. Making these packages reloadable is a very good idea. The idea of
just deleting them seems rather unhelpful to me.

Environments are currently not working and as a consequence blocking use of project/ image segment loading/ unloading. 

Karl
 

Dave





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

David T. Lewis
On Sat, Nov 21, 2015 at 06:43:00PM +0100, karl ramberg wrote:

> On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
> > > The then trade-off would be to make them unloadable, right? ;) Just like
> > > anyone can unload *-Deprecated packages. This simplifies maintenance.
> > >
> >
> > Right. Making these packages reloadable is a very good idea. The idea of
> > just deleting them seems rather unhelpful to me.
> >
>
> Environments are currently not working and as a consequence blocking use of
> project/ image segment loading/ unloading.
>

I am not sure what is involved, but is it because of this?

  http://bugs.squeak.org/view.php?id=7814

If so we should try Colin's suggested workaround:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/180018.html

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Karl Ramberg
The Binding issue is fixed by this.

I'll commit that.

The saved project can not be loaded though,,,

Best,
Karl

On Sat, Nov 21, 2015 at 7:28 PM, David T. Lewis <[hidden email]> wrote:
On Sat, Nov 21, 2015 at 06:43:00PM +0100, karl ramberg wrote:
> On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
> > > The then trade-off would be to make them unloadable, right? ;) Just like
> > > anyone can unload *-Deprecated packages. This simplifies maintenance.
> > >
> >
> > Right. Making these packages reloadable is a very good idea. The idea of
> > just deleting them seems rather unhelpful to me.
> >
>
> Environments are currently not working and as a consequence blocking use of
> project/ image segment loading/ unloading.
>

I am not sure what is involved, but is it because of this?

  http://bugs.squeak.org/view.php?id=7814

If so we should try Colin's suggested workaround:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/180018.html

Dave





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Frank Shearar-3
In reply to this post by timrowledge
On 20 November 2015 at 18:40, tim Rowledge <[hidden email]> wrote:
> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
>
> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

There's definitely a pattern there: someone has a great idea for a
fairly advanced capability, heroically tries to do all the work solo,
or with minimal help from the community, burns out and the work never
gets finished.

Traits, or things close enough to traits that you end up splitting
hairs to tell them apart, are a core feature of so many languages
nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
head), while we let the idea die on the vine, for want of tooling
support. And I'm sure Environments will, too.

Sure, if it's not providing value, and no one's willing to do the
work, just kill the thing and be done. I'd rather see people pitch in
and help _make_ the dang thing a proper part of the system. ("Thing"
here applies mostly to Environments, but Islands and Traits too.) But
I'm also not going to run around pointing fingers: I'm too burned out
to do anything to help, so I'll just shut up now.

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IG: Insert Garbage
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Karl Ramberg
Software is hard to make. Even harder to make right.
Picking up other peoples projects can be daunting.

Most of these projects are quite difficult and involve almost as much political as technical skills to do. (Political in the sense as to get the community to agree to changes and adapt)

I'm not sure how to proceed.

Best,
Karl



On Mon, Nov 23, 2015 at 3:30 PM, Frank Shearar <[hidden email]> wrote:
On 20 November 2015 at 18:40, tim Rowledge <[hidden email]> wrote:
> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
>
> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.

There's definitely a pattern there: someone has a great idea for a
fairly advanced capability, heroically tries to do all the work solo,
or with minimal help from the community, burns out and the work never
gets finished.

Traits, or things close enough to traits that you end up splitting
hairs to tell them apart, are a core feature of so many languages
nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
head), while we let the idea die on the vine, for want of tooling
support. And I'm sure Environments will, too.

Sure, if it's not providing value, and no one's willing to do the
work, just kill the thing and be done. I'd rather see people pitch in
and help _make_ the dang thing a proper part of the system. ("Thing"
here applies mostly to Environments, but Islands and Traits too.) But
I'm also not going to run around pointing fingers: I'm too burned out
to do anything to help, so I'll just shut up now.

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: IG: Insert Garbage
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Tobias Pape
Hi Karl,

On 23.11.2015, at 16:45, karl ramberg <[hidden email]> wrote:

> Software is hard to make. Even harder to make right.
> Picking up other peoples projects can be daunting.
>
> Most of these projects are quite difficult and involve almost as much political as technical skills to do. (Political in the sense as to get the community to agree to changes and adapt)
>
> I'm not sure how to proceed.
>

I have to concur, for every very line.

We should have at least a list of things that people/community think are orphaned… so that we can bail if they are actually not.

Best regards
        -Tobias

> Best,
> Karl
>
>
>
> On Mon, Nov 23, 2015 at 3:30 PM, Frank Shearar <[hidden email]> wrote:
> On 20 November 2015 at 18:40, tim Rowledge <[hidden email]> wrote:
> > Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
> >
> > Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
>
> There's definitely a pattern there: someone has a great idea for a
> fairly advanced capability, heroically tries to do all the work solo,
> or with minimal help from the community, burns out and the work never
> gets finished.
>
> Traits, or things close enough to traits that you end up splitting
> hairs to tell them apart, are a core feature of so many languages
> nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
> head), while we let the idea die on the vine, for want of tooling
> support. And I'm sure Environments will, too.
>
> Sure, if it's not providing value, and no one's willing to do the
> work, just kill the thing and be done. I'd rather see people pitch in
> and help _make_ the dang thing a proper part of the system. ("Thing"
> here applies mostly to Environments, but Islands and Traits too.) But
> I'm also not going to run around pointing fingers: I'm too burned out
> to do anything to help, so I'll just shut up now.
>
> frank
>
> > tim
> > --
> > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> > Strange OpCodes: IG: Insert Garbage
> >
> >
> >
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Levente Uzonyi-2
In reply to this post by Frank Shearar-3
On Mon, 23 Nov 2015, Frank Shearar wrote:

> On 20 November 2015 at 18:40, tim Rowledge <[hidden email]> wrote:
>> Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
>>
>> Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
>
> There's definitely a pattern there: someone has a great idea for a
> fairly advanced capability, heroically tries to do all the work solo,
> or with minimal help from the community, burns out and the work never
> gets finished.
>
> Traits, or things close enough to traits that you end up splitting
> hairs to tell them apart, are a core feature of so many languages
> nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
> head), while we let the idea die on the vine, for want of tooling

Traits are complex: they introduce a new kind of Behavior, one which
doesn't do anything on its own. If Traits were all Classes and all Classes
were Traits, the whole implementation would probably be a lot simpler.
Traits are weak: they only provide a way to share stateless methods
between classes (methods which can't reference variables). If you Traits
were Classes, you could share stateful methods by providing a mapping for
variables, the same way you can do it for methods.

> support. And I'm sure Environments will, too.

Environments is at a point where it needs complex things to be found out
to move forward. The current implementation is incomplete and broken. The
reason why we don't face the problems (so often) is that we only use one
environment.

Levente

>
> Sure, if it's not providing value, and no one's willing to do the
> work, just kill the thing and be done. I'd rather see people pitch in
> and help _make_ the dang thing a proper part of the system. ("Thing"
> here applies mostly to Environments, but Islands and Traits too.) But
> I'm also not going to run around pointing fingers: I'm too burned out
> to do anything to help, so I'll just shut up now.
>
> frank
>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Strange OpCodes: IG: Insert Garbage
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Traits-pre.307.mcz

Colin Putney-3
In reply to this post by Frank Shearar-3


On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar <[hidden email]> wrote:

There's definitely a pattern there: someone has a great idea for a
fairly advanced capability, heroically tries to do all the work solo,
or with minimal help from the community, burns out and the work never
gets finished.
 
Traits, or things close enough to traits that you end up splitting
hairs to tell them apart, are a core feature of so many languages
nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
head), while we let the idea die on the vine, for want of tooling
support. And I'm sure Environments will, too.

Sure, if it's not providing value, and no one's willing to do the
work, just kill the thing and be done. I'd rather see people pitch in
and help _make_ the dang thing a proper part of the system. ("Thing"
here applies mostly to Environments, but Islands and Traits too.) But
I'm also not going to run around pointing fingers: I'm too burned out
to do anything to help, so I'll just shut up now.
 
Yup, that about sums it up. 

Over the last year or so, I've attempted to resume work on Environments several times only to get discouraged and give up. The "easy" part is done, and what remains is tracing through gnarly legacy code and figuring out where the SystemDictionary assumptions are. It's hard. 

The reason I started working on OmniBrowser 10 years ago was because Nathanael Schärli commented that the hardest part of getting the Traits prototype working was adding tool support. The idea was to make a modular tool set that could easily be modified and *make language improvements easier*. That failed. OB ended up being a great IDE once Lukas did the refactoring support, but nobody uses it. I spent years trying to hunt down the underlying reasons for that and remove the obstacles, but in the end, "not exactly like the tools I already know" and "requires installation" proved insurmountable.

This is why I wanted to develop Environments in the trunk and not have it be an optional thing. That worked fairly well, but then I ran into the exact same problem that Nathanael did with Traits. 

I really want Environments to succeed. I do. I wrote the cleanest code I could, with tests and comments. I engaged with the community from the beginning and throughout the process trying to build support for the idea and knowledge about the implementation. Eventually, I had to take a break and deal with meatspace things like moving and a new job, but I was determined to get back into it as soon as I could.

After time away from it, though, thinking about Environments fills me with despair. Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses. Ok, that's over the top. But to a first approximation it's true. It's why we lost the Pharo folks.

So here's my proposal: let's decide as a community whether we want Environments or not. I pledge to help implement the decision either way. If people want to go back to the classical ST-80 global namespace, I'll help with that. Or we can figure out what would be required for Environments to actually be worth keeping and I'll help work on that too. 

Thoughts?

Colin


123