2009/12/28 Stéphane Ducasse <[email protected]>: >>> >>> >>> Package Classes Methods >>> Traits 59 873 >>> Traits-Kernel 22 343 >>> Traits-Kernel-Traits 17 215 >>> Traits-Composition 7 127 >>> NanoTraits-Kernel 9 190 >>> NanoTraits-Tests 9 122 >>> >> >> oh, that's quite a big difference. >> I am curious, is it because of simpler implementation or because of >> smaller feature set? > > First two remarks > -we should remove the old infrasturcture for requirements computation > that has not > much with traits. > - second counting number of classes is not a good measure. > Do you think that this is better to have one Refactoring class or 18 > Refactoring classes? > I counting, because i want smaller kernel (including image size) and memory footprint. And sure thing, i don't think that 1 class with tons of custom methods better than 18 ones. It depends.
>>> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing >>> NanoTraits there will be many other methods removed in Behavior and friends >>> which are only the result of unnecessary complexity in Berned traits. It >>> will be *significantly* simpler by any measures and unloadable. > > This is probably true. > This is why I want to see the result of nano traits. > >>>> >>> (Installer repository: 'http://www.squeaksource.com/NanoTraits') >>> install: 'NanoTraits-Kernel'; >>> install: 'NanoTraits-Tests'. >>> >>> then install it using: >>> >>> NanoTrait install. >>> >>> (WARNING: Be prepared to throw the image away if something goes wrong) >>> >>>> I just have some concerns about common protocols, so developers could >>>> use traits in both pharo & squeak without need of refactoring. >>> >>> Fair enough. I don't think there's much difficulty as far as extending the >>> existing protocols go. We could even add compatibility traits >>> (TCompilingBehavior etc) that model the old structure if people want to add >>> extension methods to those. >>> >> >> And hey, my code is always MIT, so if the Pharo folks are interested, tell >>> them they're more than welcome to use and enhance it. The squeaksource >>> repository is world-writable. > > > I'm really interested in a cleaner/smaller/less intrusive trait > implementations. > Contrary to what some not so clever guys thought it was always the case. ;D i hope i'm not in that list :) > Just no time right now. shit..... back project wirting > >> Aye, i CC this conversation to pharo list. >> Personally, amount of code is the major criteria for me to choose >> from. Especially for things in Kernel. >> And especially, if it doesn't having heavy tradeoffs. > > Igor please rephrase your thoughts! :) > amount of complexity !!! > not amount of code!!! > Come on number of classes is not a decent measure in presence of late > binding! > hehe.. i hope that Andreas writing short methods, not a fat ones which trying to do everything at once :) I just pointing out, that it is much easier to study & comprehend a smaller code base. Less methods, less classes => less code to read & understand. I can't say anything about complexity of nano-traits comparing to Berne ones. Its just my guess, that less code is a sign of less complex model, or better code reuse, and so i welcome it :) > Stef > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
