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

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 16 21:13:22 CET 2011

On Wed, Feb 16, 2011 at 12:04 PM, Stéphane Ducasse <
stephane.ducasse at inria.fr> wrote:

> On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote:
> >
> >
> > On Tue, Feb 15, 2011 at 11:50 PM, Stéphane Ducasse <
> stephane.ducasse at inria.fr> wrote:
> > Eliot a final question.
> > So how will you handle OPAL compiler change in Cog?
> > Do you require that marcus and jorge have to deal with decompiler of
> caseOf: in addition to all the rest?
> > Is it a strong requirement? Because then this is clear that Opal will be
> delayed. But may be it is not that important after all.
> > Just curious.
> >
> > OPAL is a Smalltalk compiler.  I can therefore assume that it will
> compile Smalltalk.  caseOf: is valid Smalltalk and so will be compiled by
> OPAL.  Whether Marcus chooses to optimise caseOf: or not is up to him.
> This is exactly my point.

No it's not.  Your point was to raise two straw-=man arguments:
1. that Marcus and Jorge would have to deal with the decompiler (not an
issue; the decompiler already deals with optimized caseOf: and the new
decompiler will deal with optimized caseOf: just as it'll deal with
optimized ifTrue: ifNotNil: et al).
2. that supporting caseOf: in optimized form will delay Opal (not an issue;
Opal will optimize certain constructs, this is just one more and won't add a
lot of time).

So your point appears to be to try and justify removing caseOf: on spurious
grounds by spreading FUD.

This is so unlike you I'm having a hard time really understanding what's
going on.

best regards,

> >
> >
> > Stef
> > (if you think that I focus on details then I'm certainly an idiot).
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110216/33b303fb/attachment.htm>

More information about the Pharo-project mailing list