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.
�