Hi
I try to build a small 'algebraic number tower' like Monoid, Group, Ring and so on. There are some quirks. For example I have Monoid, OrderedMonoid, Group, OrderedGroup ,.... (the situation is more complicated but this is a first problem). The algebraic number tower is not a single tree and I want to avoid double code. General: There are Methods that belongs to a special Datatype and Methods that are generic. To create a BaseClass with all functionality seems a little bit... What are the possiblities in Cuis-Smalltalk to tackle this problem? Cheers Helmut. |
If you end up really wanting Traits without reinventing any wheels, the implementation Andreas did in Squeak to make them unloadable simplified the business a great deal. That would be the one I'd port, if I was going to the trouble of porting; the version in Pharo will be a lot harder to disentangle from Pharo.
On Mar 11, 2013, at 5:22 AM, Helmut <[hidden email]> wrote: > Hi > > I try to build a small 'algebraic number tower' like Monoid, Group, Ring and > so on. There are some quirks. For example I have Monoid, OrderedMonoid, > Group, OrderedGroup ,.... (the situation is more complicated but this is a > first problem). The algebraic number tower is not a single tree and I want > to avoid double code. General: There are Methods that belongs to a special > Datatype and Methods that are generic. > > To create a BaseClass with all functionality seems a little bit... > > What are the possiblities in Cuis-Smalltalk to tackle this problem? > > Cheers > Helmut. > > > > -- > View this message in context: http://forum.world.st/simulate-or-alternative-to-traits-tp4676088.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Hi folks,
Cuis is a Smalltalk-80 system. My suggestion is to go the Smalltalk way. (There are tons on books and references on OOD with Smalltalk). So far I haven't seen a problem where Traits offered a clear advantage over Composition / Inheritance. Traits implementations for Smalltalk are poorly integrated into the system, and the few people who try to use them keep reporting problems with the tools and the environments, for example, in Pharo, after many years. If people really want Traits, please commit seriously to supporting them, adapting the system as needed, to keep the current level of quality of the programmer's experience with the system. If a person or group does this, then Traits could be a useful optional package for Cuis. Cheers, Juan Vuletich On 3/11/2013 9:40 PM, Casey Ransberger wrote: > If you end up really wanting Traits without reinventing any wheels, the implementation Andreas did in Squeak to make them unloadable simplified the business a great deal. That would be the one I'd port, if I was going to the trouble of porting; the version in Pharo will be a lot harder to disentangle from Pharo. > > On Mar 11, 2013, at 5:22 AM, Helmut<[hidden email]> wrote: > >> Hi >> >> I try to build a small 'algebraic number tower' like Monoid, Group, Ring and >> so on. There are some quirks. For example I have Monoid, OrderedMonoid, >> Group, OrderedGroup ,.... (the situation is more complicated but this is a >> first problem). The algebraic number tower is not a single tree and I want >> to avoid double code. General: There are Methods that belongs to a special >> Datatype and Methods that are generic. >> >> To create a BaseClass with all functionality seems a little bit... >> >> What are the possiblities in Cuis-Smalltalk to tackle this problem? >> >> Cheers >> Helmut. >> _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Free forum by Nabble | Edit this page |