[Cuis] simulate or alternative to traits?
Juan Vuletich
juan at jvuletich.org
Tue Mar 12 06:44:26 CDT 2013
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<helmut.preininger at chello.at> 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.
>>
More information about the Cuis
mailing list