[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