[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko siguctua at gmail.com
Mon Feb 14 22:58:20 CET 2011


On 14 February 2011 22:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Fri, Feb 11, 2011 at 1:43 PM, stephane ducasse <stephane.ducasse at 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. 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.

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

>>
>> Stef
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list