On Tue, Jun 7, 2011 at 7:18 AM, Stéphane Ducasse <[email protected]>wrote:
> Just a meta question..... > So what will people do when we will add slots? Leave/cry and complain as > usual? When Common lisp got slots since 1990 and the world imagination got > killed by Java, it makes me think. > May be we are not a community to invent something after all. Especially if > we are not ready because the last time something serious was new in > Smalltalk it was back in 1984. > I think to invent something new you have to fork. IMO, the community needs Pharo the platform, which stays backwards-compatible, 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. 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, 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, 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. > > Mariano this is not against you but in general. Pharo is not about > maintaining the past. > This notion of compatibility is doomed, because first VW does not ask pharo > to add a feature in the language (like these wonderful namespaces or XML > code format) > Second, this means that nobody can evolve. While we have the tools to > manage difference. > So of course traits could be better but this is not by being negative on > attempt to move our wonderful old community that we will make progress. > Or may be the best way is just to tell us that we should better invest in > Javascript and we will all look far cooler in fact. > Are you really afflicted with FUD? Talk to e.g. Gilad about using Javascript for Newspeak and you'll find there are a host of deep serious problems using it. Its community is large which implies great inertia. There are basic problems with the language (it lacks structure, it is difficult to implement efficiently). There are problems with its tools. But unlike Pharo and Squeak you don't have control unless you maintain your own fork. As they say, better the devil you know than the devil you don't. Stay strong and cast those doubts aside. You're on the right track; you just need to think a bit about how to walk down it. best wishes, and hugs, Eliot > > Stef > > > > On Jun 7, 2011, at 3:10 PM, Mariano Martinez Peck wrote: > > > Thanks Adrian. > > > > BTW, there is no way to fileout a whole Monticello package? it seems I > have to manually do a fileout of each category, not package :( > > > > Eliot: we were discussing today with Martin and maybe we will get rid of > Traits. The truth is that in our case we use them mostly for tests and we > think that with a good refactor we can avoid using them without duplicating > too much code. In fact, we suffer several problems with traits and the > integration with tools like Monticello. And even more it makes porting more > complicated. We cannot code that much now because we are preparing a paper > for ESUG but we will give it a try. > > > > Taking into account all your knowledge and experience in general and with > Parcels, we will LOVE to listen your feedback for Fuel. > > > > Cheers > > > > Mariano > > > > > > On Tue, Jun 7, 2011 at 12:29 PM, Adrian Lienhard <[email protected]> > wrote: > > IIRC this can be achieved with two small changes: > > > > - Comment out the line "method isLocalSelector" from > PackageInfo>>methods. This will flatten the traits into the classes, i.e., > make all methods of a class being stored even if they come from a trait. > > > > - In addition you probably need to change PackageInfo>>classes to filter > out all traits (like ... reject: #isTrait). > > > > HTH, > > Adrian > > > > On Jun 7, 2011, at 08:11 , Mariano Martinez Peck wrote: > > > > > On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda < > [email protected]>wrote: > > > > > >> Hi All, > > >> > > >> if I want to export a package (Fuel!!) to a dialect without traits > is > > >> there anything to help me remove the trait info and just file-out the > > >> composed code? > > >> > > >> > > > Hi Eliot. Traits are only used in Fuel for testing. And really used for > > > testing methods for classes and traits (not the basic methods). So, of > > > course, you can directly fileout the Fuel package only without traits. > > > > > > One of the things I always wanted is what you are really asking, a way > to > > > fileout forgetting traits, just letting those methods directly in the > > > classes. But I have no idea if that's possible. > > > > > > Finally, I was never really convinced about the Traits usage in Fuel. > Mostly > > > because some tools seem not to be happy with them...We should check how > much > > > difficult and what we loose removing them now.... > > > > > > Cheers > > > > > > -- > > > Mariano > > > http://marianopeck.wordpress.com > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >
