On Tue, Jun 7, 2011 at 7:48 PM, Eliot Miranda <[email protected]>wrote:
> > > On Mon, Jun 6, 2011 at 11:11 PM, Mariano Martinez Peck < > [email protected]> 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. >> > > 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
