[Pharo-project] support for flattening-out traits for export?

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Jun 8 01:44:27 EDT 2011


On Jun 7, 2011, at 10:48 PM, Mariano Martinez Peck wrote:

> Ok....since Martin is a shy guy I will speak in his name ;)
> Not sure if it is worth it for the thread, but just want to make clear why we used Traits. A couple of reasons:
> 
> 1) Martin didn't have time to play with Traits before, and since he is a hacky guy he wanted to learn and try. Fuel has a particular problem, and he tried with Traits
> 2) In a couple of places we found Traits were easier than subclassifaction. So, we went ahead.
> 3) We were not aware of some problems of traits, and we discover them after. I cannot really reproduce or numerate them but some tools like OB, RB and Monticello are not fully working with them.

OB we know but Monticello is working.

> 4) Martin was taught (mostly by Hernan Wilkinson I guess jajajaja) not to duplicate code at all. Maybe even too much ;)
> 5) I also liked when Martin put traits. 90% are used in tests. The little part of the core can be easily removed as Eliot suggested.
> 
> Now, I am not saying whether Traits are useful or not. I just want to say why we used them. Now, if we re-think about them, as said, we may be able to refactor them and not used them and avoid code duplication.
> 
> Cheers
> 
> 
> On Tue, Jun 7, 2011 at 10:27 PM, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> Hi eliot
> 
> we are nearly in sync :).
> 
> > and e.g. if it looses traits then at least provides tools for importing packages with traits, eliminating the trait usage on the way in, and in general provides tools for cleaning-up packages (i.e. refactoring with clean-ups) so that old packages continue to function, and so that users can continue to use Pharo in their daily work.
> 
> We always pay attention to that. We are working on tools to support change and evolution. Now we do not have enough man power. Torch is the example of the best tools for understanding changes
> I have seen but this is
> 
> >  But you also need Pharo the Phuture, which is a system moving towards your vision.  By maintaining the two side-by-side you get to work on migration tools and you keep the existing user base happy while helping people to dip their toes in the Phuture water.  I know its expensive,
> yes we know that and this is what we are doing
> 
> > but if you just provide Phuture you'll alienate the existing user base and you won't provide a well-tooled migration path to bring that user base into the future.  This is an agile, incremental approach to getting the entire community into the future,
> 
> oh yes that we know and this is for the reason that classboxes were not adequate for real usage that we never push them.
> 
> > instead of an isolated incremental approach, where only the developers at the core of Pharo can keep up with the incremental progress towards the vision.  Anyway, that's how I would go about it.
> 
> Yes this is our vision and process too.
> 
> eliot what I want to say is that we did pharo to open space and reinvent Smalltalk.
> I have no problem to perform a real analysis and decide that we made a mistake and learn from it with traits (see the beginning of the other mails).
> 
> I have a problem with cries and backward compatibility for the sake of it. If one of the smalltalk adds a good feature then we should copy it and we should add what we think
> is important. Smalltalk is not carved in stone. This is what we did for pragma (they are cool). We have the initialize invoked automatically (like CLOS since 90).
> Now if we do not give intellectual space for inventing on the pretext of backward compatibility then frankly better do something else. I think that pharo is doing a good job and we will continue and we will add/change the language for the better. We want slots for example because this is really good. And some people will do not like it and be against and use the "non compatible" flag.
> 
> The feedback we got from some venture oriented people is that: it is old. Sure they are probably idiot but with money and power in our case. So if I would sell the java, javascript it would be much simpler (even if the java hype i over and people are open to dynamic language): clojure, scala... xxxx.
> So my point is at least we should be imaginative and show that we are smart and that we can learn from others and be open to change.
> 
> This is my main point. I do not care about traits: I care about innovation and the place we give it.
> 
> For example we got a really nice presentation from tom van cutsem about the new scheme for proxy in Javascript and this is good and they will have a nice way to secure some part of Javascript.
> So mariano is working on Ghost and we want a really good proxy implementation and we will have it.
> This is the same for Fuel: we liked the idea of the pickle format and we will have a nice object-serializers. These two examples are not about the languages but for me this is the same.
> Ghost is based on a VM hook that does not exist in other Smalltalk. so too bad ;)
> 
> Stef
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> 





More information about the Pharo-dev mailing list