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 <[email protected]> > 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 >
