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

[Igor Stasenko]

On 4 February 2011 19:56, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
>
> 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 ?
>
no i'm not. I just found it quite abusive that MiscPrimitivePlugin
tries to dictate
what selectors should be present in those classes, instead of letting
them to decide by themselves.
In fact, as i said in previous discussion, if we can't contaminate a
translated primitives explosion,
then why just not query all classes in image , who of them wants to
add something to VM, instead of selectively
pick few of them?

> 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.
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.