On Mon, 4 Jan 2010, Igor Stasenko wrote:

> 2010/1/4 Levente Uzonyi <leves at elte.hu>:
>>
>>
>> On Mon, 4 Jan 2010, Igor Stasenko wrote:
>>
>>> They make a difference.
>>> Actually, when coding the stuff, i was more concerned about #endPC
>>> than anything else,
>>> since now it will be calculated much slower, because trailer decoding
>>> the data , even if its not used by sender which might be interested in
>>> getting #endPC only.
>>> To optimize this, i though that maybe it worth to decode data lazily,
>>> while in #method: , calculate only size field.
>>> But i'm not sure, if it worth spending time optimizing it, since i'm
>>> not measured the impact.
>>>
>>> My nitpick was about workarounds in using #perform: with pregenerated
>>> selectors. Other changes, which
>>> focused on avoiding generating temporary trailer instance is
>>> definitely worth doing.
>>
>> I didn't look at the code in detail until now and I think it would be better
>> to use subclasses for dispatching. This means removing the kind variable and
>> every existing trailerKind would have it's own subclass. The subclasses
>> would have 3 responsibilites #kindAsByte (returns a constant) #encode and
>> #decode (implement the kind specific encoding/decoding). The class side
>> #trailerKinds method could be generated based on the #kindAsByte
>> implementations. A single method could be used for dispatching like:
>> CompiledMethodTrailer class >> for: method
>>
>>        | flagByte |
>>        flagByte := method at: method size.
>>        ^(self trailerKinds at: flagByte >> 2 + 1) new
>>                method: method;
>>                yourself
>>
>> Where trailerKinds returns an Array with the subclasses.
>> What do you think?
>>
>
> This is much better, its however spawns a number of subclasses. So if
> you think it worth more attention, then do it.
> One of positive moments, that if you make a trailer kinds to be
> classvar, and change #kindAsByte appropriately,
> then we could allow an easy plug-in and plug-out interface for new
> trailer kinds by external package, without need of reserving a
> specific number.
> If you gonna to implement that, do not forget to create an interface
> for uninstalling the trailer kind
> and in #uninstallTrailer:, replace it with undefined trailer for all
> methods which currently using this trailer kind.
> P.S. And if you gonna do that, please make sure to provide changes for
> adopting them in both trunk and Pharo ;)
> P.P.S. And try to not introduce any of #isKindOf: or #isXXX patterns :)

Okay, keep the ideas coming if you have more.


Levente

>
>>
>> Levente
>>
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>