help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] gst-shape


From: Gwenaël Casaccio
Subject: Re: [Help-smalltalk] gst-shape
Date: Wed, 20 Oct 2010 09:16:51 +0200

I've migrated the patch on my gst git:
git://github.com/MrGwen/smalltalk.git the shape branch

Gwen

On Mon, Oct 18, 2010 at 12:37 PM, Gwenaël Casaccio <address@hidden> wrote:
> Thanks,
>
> I'll do a pass and fix it
>
> Cheers,
> Gwen
>
> On Mon, Oct 18, 2010 at 12:05 PM, Paolo Bonzini <address@hidden> wrote:
>> On 10/18/2010 11:42 AM, Gwenaël Casaccio wrote:
>>>
>>> Hi,
>>>
>>> I would like to announce gst-shape git://github.com/MrGwen/gst-shape.git
>>> a refactoring of the class shape, a small example of the power of this new
>>> refactoring:
>>
>> This is very nice, thanks.  You can also use a branch of smalltalk.git
>> rather than a fully separate repository.  This will make it easier for me to
>> pull.
>>
>> However, I wouldn't use class methods.  I think it's bad design. It's better
>> to use a simpler hierarchy and put these on the instance side using instance
>> variables:
>>
>> Shape "class methods for mapping integers to ShapeSymbol instance"
>>    VMShape
>>        FixedShape "current NilShape"
>>        IntegerShape "adds #byteSize, #byteSize:"
>>            SignedIntegerShape
>>            UnsignedIntegerShape
>>        FloatingPointShape
>>        CharacterShape
>>             EncodedCharacterShape
>>             UnicodeCharacterShape
>>    ShapeAliasSymbol "abstract class maybe not necessary"
>>        ShapeInherit
>>        ShapeWord
>>
>> This is because you can use #nextBytes:signed: and #nextPutBytes:of: to
>> implement dumping.  Those methods are private, but we can un-privatize them.
>>
>> "wrongClassIfFloatOrDoubleShape:" and "wrongClassIfCharacterOrUtf32Shape:"
>> can be unified to "checkArgumentClass:".
>>
>> The "subclassResponsibilityIfCharacterOrUtf32Shape" and
>> "subclassResponsibilityIfNotCharacterOrUtf32Shape" methods are also bad.
>>  First of all, the former should not be used (it's always using #ifFalse: in
>> kernel/CharArray.st). Second, I'd anyway use a method #hasValueAtPrimitives
>> that returns true/false.
>>
>> Thanks,
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]