On Mon, Feb 14, 2011 at 1:58 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 February 2011 22:38, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
> On Fri, Feb 11, 2011 at 1:43 PM, stephane ducasse <stephane.ducasse@free.fr>
> wrote:
>>
>> Hi guys
>>
>> let us do another pass at cleaning and realigning the system.
>> Could we agree to deprecate caseOf: and caseOf:otherwise:?
>> it will simply the compiler, decompiler and also we do not need that at
>> all.
>>
>> | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z
>>
>> =>
>> "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}.
>> z detect: [:each | each key value = #b] "
>>
>> there is one user which I fixing right now.
>
> please don't. �It is used in many places in Cog and would be extremely
> uncomfortable to live without.
>

Yes, i mentioned that too..

It is strange however that the only 'senders' of these messages in VMMaker is:

TMethod>>prepareMethodIn: aCodeGen
...
� � � � � � � � � � � � � � � � � � � � (#(caseOf: #caseOf:otherwise:) includes: node selector) ifTrue:
� � � � � � � � � � � � � � � � � � � � � � � �[replacements at: node put: (self buildSwitchStmt: node)]]].

ahh... probably it means that system navigation can't detect them ,
because they are 'inlined' and there is no references to
these selectors from methods where it used.


That's right. �The compiler inlines caseOf: into a series of comparisons and jumps. �One way to find some uses (those without an explicit otherwise clause) is to look for senders of #caseError.
�
But if you look at code
there, VMMaker won't stop working if we remove compiler support of
these guys, because it just reacts on a message-send level by checking
if it a special selector, so it will be translated to switch statement
in C.

But we /will/ lose the ability to load code including it. �This clearly isn't any kind of solution.
�

Oh.. or perhaps because code using #dispatchOn:in: :)


cheers
Eliot


>>
>> Stef
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.