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

Eliot Miranda eliot.miranda at gmail.com
Mon Feb 14 23:04:04 CET 2011


On Mon, Feb 14, 2011 at 1:58 PM, Igor Stasenko <siguctua at gmail.com> wrote:

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



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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110214/00277a28/attachment.htm>


More information about the Pharo-project mailing list