[Vm-dev] MiscPrimitivePlugin, translated primitives and ByteString method(s)

[Nicolas Cellier]

In this particular case, why not just peek Squeak change ?

What is the added value of Pharo solution ?
IMO, none, it's just a workaround, and that pre-existed in Sophie.

Or do you try and invent a procedure for future divergence ?

Nicolas

2011/2/4 Igor Stasenko <siguctua at gmail.com>:
>
> On 4 February 2011 18:31, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>> On Fri, Feb 04, 2011 at 05:34:27PM +0100, Igor Stasenko wrote:
>>>
>>> The aim of this change is to help fixing the
>>> ByteString>>findSubstring:in:startingAt:matchTable: issue
>>> by moving the selector names , which should be translated from
>>> MiscPrimitivePlugin class to the corresponding classes,
>>>
>>> so they could choose which selectors to include.
>>>
>>> The problem, that Pharo having the fix for
>>> findSubstring:in:startingAt:matchTable: bug
>>> but this method can't be used for translation anymore because it is
>>> moved to another one:
>>> findSubstringViaPrimitive:in:startingAt:matchTable: , while original
>>> one dispatching to it, after testing that there is no widestrings.
>>>
>>> And so, VMMaker can't work on pharo without error, so either a patch
>>> should be applied to VMMaker to change selector from
>>> #findSubstring:in:startingAt:matchTable: to
>>> #findSubstringViaPrimitive:in:startingAt:matchTable: in
>>> MiscPrimitivePlugin , which sucks, because then
>>> VMMaker package become dirty and it is seen in builds and gets into
>>> every source file..
>>>
>>> , or if we apply this changeset to our images, then Pharo could answer
>>> different selector, without need
>>> patching anything.
>>>
>>> And for future, this pattern could be extended, to seek for all
>>> #translatedPrimitiveSelectors implementors in system, not just in 3
>>> classes.
>>> But that gets us back to discussion about separating
>>> responsibilities... so.. lets try to fix what we have instead.
>>>
>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html
>>>
>>
>> I am traveling and cannot look at the change set now (so ignore this if
>> it is not relevant to your cs), but FYI Andreas already fixed the underlying
>> problem in the VM that led to the Pharo refactoring, and Stef already agreed
>> (Pharo list email somewhere) that it would be good to revert the Pharo change
>> after the VM fix is in general circulation.
>>
>
> But even if that, i think it is generally better let each class
> personally decide, which selectors should be translated
> and which ones not.
>
>> Dave
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>