[Pharo-project] support for flattening-out traits for export?
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? TIA Eliot
On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda@gmail.com>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
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 <eliot.miranda@gmail.com>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
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 <adi@netstyle.ch> 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 <eliot.miranda@gmail.com 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
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.
Alltogether? +1000 :-) -- Lukas Renggli www.lukas-renggli.ch
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. 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. 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 <adi@netstyle.ch> 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 <eliot.miranda@gmail.com>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
On Tue, Jun 7, 2011 at 7:18 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>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 <adi@netstyle.ch> 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 < eliot.miranda@gmail.com>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
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
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. 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@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
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@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
On Mon, Jun 6, 2011 at 11:11 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda@gmail.com>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.
Hmm, at least in Fuel stable 1.4 there exists FLTWithClass trait which is used by FLObjectCluster and FLRawArrayedCollectionCluster. This seems reasonable to me; Pharo and Squeak currently support traits. But I'm trying to use Fuel in Newsqueak (the Squeak Newspeak implementation) and we eliminated traits from that system. So... Turns out there is a facility to remove traits, and had I browsed before asking (lazy man, me) I would have found it (I'm in an updated 1.2): Behavior>>flattenDownAllTraits and so one can theoretically eliminate traits from Fuel by e.g. #('Fuel' 'FuelTests') do: [:pn| (SystemNavigation new allClassesInPackageNamed: pn) do: [:c| c isTrait ifTrue: [c category: #Unpackaged] ifFalse: [{c. c class} do: [:b| b flattenDownAllTraits]]]] but there's a couple of bugs, one weird. The first bug is that basicLocalSelectors can answer nil and so Behavior>>flattenDown: (find attached) needs to read: flattenDown: aTrait | selectors | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. selectors := (self traitComposition transformationOfTrait: aTrait) selectors. self basicLocalSelectors: (self basicLocalSelectors ifNil: [selectors] ifNotNil: [:bls| bls , selectors]) asSet. self removeFromComposition: aTrait But the weird bug, which I suppose could be a Cog VM bug, and that I don't have time to track down right now, is that if I try the doit above FLRawArrayedCollectionCluster class ends up losing its #for: method from FLTWithClass classTrait but FLObjectCluster does not. But if I evaluate FLRawArrayedCollectionCluster class flattenDownAllTraits. manually before the doit then FLRawArrayedCollectionCluster class does /not/ lose its #for: method and everything is ok. BTW, I find adding a literal selector mode to the finder is really useful. Being able to look for just #for: instead of all the selectors containing for: makes finding for: much easier (try it and see) ;) So find attached a modification to the finder that matches exactly that selector if one surrounds it with double quotes. i.e. searching for "for:" finds only the implementors of #for:.
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.
Well, if we can track down and fix the bug then a package-level flattenDownAllTraits could be constructed and provided from a menu. That would be useful and as you can see, at least theoretically its easily done :)
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....
At least in Fuel core you'd loose almost nothing. The FLTWithClass trait adds 6 methods but is used only by two subclasses of FLCluster, (FLObjectCluster and FLRawArrayedCollectionCluster). So you could add a subclass of FLCluster, e.g. FLClusterWithClass, and then move FLObjectCluster and FLRawArrayedCollectionCluster under it. At least that's what I'd do. best, Eliot P.S. Fuel looks well-factored. I like the idea of abstracting the code for marshalling specific kinds of classes into the FLCluster hierarchy. I look forward to providing more feedback once we're using Fuel.
Cheers
-- Mariano http://marianopeck.wordpress.com
On Tue, Jun 7, 2011 at 7:48 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Mon, Jun 6, 2011 at 11:11 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda@gmail.com>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.
Hmm, at least in Fuel stable 1.4 there exists FLTWithClass trait which is used by FLObjectCluster and FLRawArrayedCollectionCluster.
yes, sorry Eliot for my false assumption. Martin remembered that to me today afternoon :(
This seems reasonable to me; Pharo and Squeak currently support traits. But I'm trying to use Fuel in Newsqueak (the Squeak Newspeak implementation) and we eliminated traits from that system. So...
Turns out there is a facility to remove traits, and had I browsed before asking (lazy man, me) I would have found it (I'm in an updated 1.2):
Behavior>>flattenDownAllTraits
Interesting. I wasn't aware of that :)
and so one can theoretically eliminate traits from Fuel by e.g.
#('Fuel' 'FuelTests') do: [:pn| (SystemNavigation new allClassesInPackageNamed: pn) do: [:c| c isTrait ifTrue: [c category: #Unpackaged] ifFalse: [{c. c class} do: [:b| b flattenDownAllTraits]]]]
but there's a couple of bugs, one weird. The first bug is that basicLocalSelectors can answer nil and so Behavior>>flattenDown: (find attached) needs to read:
flattenDown: aTrait | selectors | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. selectors := (self traitComposition transformationOfTrait: aTrait) selectors. self basicLocalSelectors: (self basicLocalSelectors ifNil: [selectors] ifNotNil: [:bls| bls , selectors]) asSet. self removeFromComposition: aTrait
But the weird bug, which I suppose could be a Cog VM bug, and that I don't have time to track down right now, is that if I try the doit above FLRawArrayedCollectionCluster class ends up losing its #for: method from FLTWithClass classTrait but FLObjectCluster does not. But if I evaluate
FLRawArrayedCollectionCluster class flattenDownAllTraits.
manually before the doit then FLRawArrayedCollectionCluster class does /not/ lose its #for: method and everything is ok.
weird....Maybe Adrian can help us?
BTW, I find adding a literal selector mode to the finder is really useful. Being able to look for just #for: instead of all the selectors containing for: makes finding for: much easier (try it and see) ;)
+1
So find attached a modification to the finder that matches exactly that selector if one surrounds it with double quotes. i.e. searching for "for:" finds only the implementors of #for:.
Great, thanks! I will ask benjamin to integrate it :)
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.
Well, if we can track down and fix the bug then a package-level flattenDownAllTraits could be constructed and provided from a menu. That would be useful and as you can see, at least theoretically its easily done :)
Yes, it sounds good.
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....
At least in Fuel core you'd loose almost nothing.
This this can be done in a couple of minutes. But what do you win? if you cannot really testes (because most traits are there) you won't be sure if it works.
The FLTWithClass trait adds 6 methods but is used only by two subclasses of FLCluster, (FLObjectCluster and FLRawArrayedCollectionCluster). So you could add a subclass of FLCluster, e.g. FLClusterWithClass, and then move FLObjectCluster and FLRawArrayedCollectionCluster under it. At least that's what I'd do.
+1. Sounds a good solution. I will do this with Martin. Would that help?
best, Eliot
P.S. Fuel looks well-factored. I like the idea of abstracting the code for marshalling specific kinds of classes into the FLCluster hierarchy.
Thanks :) Several times we discussed what to do. One possibility is what is done now. The other one, like Colin's S&M does, is that each class, say Float, SmallInteger, ByteArray, etc, instead of answering kind of specific claster, they all use the same but different methods. Examples: Float >> serialize FLSerializer serializeFloat: self. ByteArray >> serialize FLSerializer serializeByteArray: self. etc... this makes easy porting it to other dialect because you jus change one class. But such class is big with a lot of methods. We prefer our design which splits the behavior in different classes, but makes porting more complicated since you should change most of the FLCluster hierarchy.
I look forward to providing more feedback once we're using Fuel.
And we are looking forward to receive feedback as well.
Cheers
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
participants (5)
-
Adrian Lienhard -
Eliot Miranda -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse