could we agree to remove caseOf: and caseOf:otherwise:

Igor Stasenko wrote:
> On 14 February 2011 01:32, Schwab,Wilhelm K <[hidden email]> wrote:
>> That's where I typically use a dictionary.

> Indeed.

Yes - sensible answer from Wilhelm Schwab.

>> You didn't answer the question though.

> Because it sounds rhetoric to me.
> How to deal with randomly put integers coming from outer source?
> If you're a software engineer, you should know it. :)

Indeed. Case construct is sometimes an appropriate way.

>  - first try to avoid dealing with them. So if you can control the
> protocol, use other ways of encoding actions/data.

Yes, but the point is that one does not always have full control of ones
environment. Of course it would be nice it to have sensible input data.
It would be nice to have a pony with wings too.

>  - organize these numbers (using dictionary or whatever), so they
> won't look like a random noise
> for people who first looking at your code. Put them into single place
> with documentation etc.

I do like the dictionary approach and sometimes do that. Other times I
wonder if I've made the world that much of a better place by loading the
logic into a dictionary rather than leaving it out in the code where
anyone can see it. It depends on the number of symbols.

I'm going to leave it here, as I don't want to find myself in the
position of the last and loudest advocate of case statements. I don't
think they're that good an idea in most circumstances, but I do think
they're reasonable enough sometimes.



                     Steve

Hi,

I'm sorry to interrupt that discussion, but I read all the messages about that subject since you started to discuss it and I really would like to understand a thing:
Why does the case structure seem to be so bad in Smalltalk?

I hope some of you could explain me :)

Adrien.

On 14 February 2011 23:33, Adrien BARREAU <[hidden email]> wrote:
> Hi,
>
> I'm sorry to interrupt that discussion, but I read all the messages about
> that subject since you started to discuss it and I really would like to
> understand a thing:
> Why does the case structure seem to be so bad in Smalltalk?
>
> I hope some of you could explain me :)
>
Because you  can  do such kind of dispatching using messages.

> Adrien.
>



--
Best regards,
Igor Stasenko AKA sig.

Really?
How can we help to remove this dependency? Can igor help?
This means that the decompiler is more complex (more jump to analyze for a messages that is sent may be
10 times in total in the complete system). I will not compare with ifTrue:ifFalse: and the other inlined selectors
that are really used.

Stef

you should follow my lecture if one day they let me do it at Lille.
Why Boolean operations are not using ifTrue:ifFalse: everywhere....?
I spent two hours explaining that point.

Stef

On Feb 14, 2011, at 11:33 PM, Adrien BARREAU wrote:

> Hi,
>
> I'm sorry to interrupt that discussion, but I read all the messages about that subject since you started to discuss it and I really would like to understand a thing:
> Why does the case structure seem to be so bad in Smalltalk?
>
> I hope some of you could explain me :)
>
> Adrien.

Eliot

you use caseOf: for the generation of C in Slang and VM maker.
Now this means that
        - it does not need to be inlined
        - it could be packaged with VMMaker

Are these two points correct?

Stef

On Tue, Feb 15, 2011 at 08:00:18AM +0100, St?phane Ducasse wrote:
> Eliot
>
> you use caseOf: for the generation of C in Slang and VM maker.
> Now this means that
> - it does not need to be inlined
> - it could be packaged with VMMaker
>
> Are these two points correct?

No.

VMMaker is used in many images, not just Pharo. And #caseOf:
is used in packages other than VMMaker. So moving it into the
VMMaker package would be a Bad Thing To Do.

Dave

On 15 February 2011 12:50, David T. Lewis <[hidden email]> wrote:
I agree.
Then probably, Pharo should move it to separate 'Crap-compat' package.

;-P

You don't need to remove #caseOf: implementation. I can stay. Just
remove a compiler hacks for it :)

P.S. i patched MessageNode class>>initialize
to test if VMMaker can work without compiler support of caseof:
and as it was expected it works quite well.

I recompiled VMMaker package and then generated full source code of
everything, and then built VM. No any errors.

> Dave
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

>>> you use caseOf: for the generation of C in Slang and VM maker.
>>> Now this means that
>>>       - it does not need to be inlined
>>>       - it could be packaged with VMMaker
>>>
>>> Are these two points correct?
>>
>> No.

? Apparently igor is just saying the contrary. You probably say no for the second point.
I can understand that when we want to generate switch in C this is better to have that at the AST level.
Now I do not see why this would be needed to inline it.

>> VMMaker is used in many images, not just Pharo. And #caseOf:
>> is used in packages other than VMMaker.

Do you have a list?

>> So moving it into the
>> VMMaker package would be a Bad Thing To Do.
>>
>
> I agree.

> Then probably, Pharo should move it to separate 'Crap-compat' package.

Yes this is what I will do. I will keep that name and put a big warning.

> ;-P
>
> You don't need to remove #caseOf: implementation. I can stay.

Well yes we can always turn around. Now in my house I regularly empty my garbage can.

> Just
> remove a compiler hacks for it :)
>
> P.S. i patched MessageNode class>>initialize
> to test if VMMaker can work without compiler support of caseof:
> and as it was expected it works quite well.
>
> I recompiled VMMaker package and then generated full source code of
> everything, and then built VM. No any errors.

Good to know that.
We should rewrite all the users of caseOf: in Pharo and add a lint rule checking them
and one day we will remove it. Because we cannot drag all these stuffs forever.

Stef

2011/2/15 Igor Stasenko <[hidden email]>:
Agree, that's the way to go, and you handle it with a Pharo specific
ConfigurationOf...

Nicolas

Em 13/02/2011 21:21, Stephen Taylor < [hidden email] > escreveu:
Igor Stasenko wrote:

>
> >> You  have some  integers: 0  83 67  77  68 72  80 112  113 87  70
> >> 82. When a variable's value is equal to any of these...
>
> > Don't try to convince me that there are sort of problems which can
> > be solved only by using case statement :)

Igor's attitude, which I'll take as sample of a school of thought is dangerously
similar to the  one which in name of keeping certain aspects of Smalltalk "pure"
or near to the origins has made its acceptance  fall as the other aspects of the
technology (OO, WIMP, etc.), made their way into other languages/platforms/technologies.

>  You didn't answer the question though.

And then this: to the first concrete example, no complete answer comes out which we
could check if the code construct is indeed only a syntactic sugar, or deserves
incorporation in the toolset of the language...
 
>  > First, get rid of these integers in your code.
>  That's the killer  - yes, we can usually  design around cases where
> we'd use case constructs (though I'm not convinced they're the spawn
> of  the devil)  but what  about cases  where we're  interfacing with
> external data sources and we  don't get to redesign the whole system
> to suit our needs?

FWIW, this kind of need, namely having to take alternate actions due different
integer codes is pretty common when interfacing with industrial boards, a lot of protocols use this as well and most of them are already in use, some even have international standards.

So the answer "redesign your world to fit our world-view" does not cut in...

Also, another argument I've seen in this thread which is pretty commonplace w.r.t. performance must be extirpated in our discourse: "the performance x to y slower than <baseline implementation> is very good considering {dynamic} languages (or similar statement)".

Performance counts!  One of the reasons we're working in Pharo is to bring its performance on par with competitive technologies.  We're doing things to take out 'cruft', some to make the abstractions more elegant, but some are pragmatic which require depart of breaking 'pure' Smalltalk OO way of thinking.

--
Cesar Rabak


>
>
>  Steve
>

This solution has the disadvantages of caseOf: solution, namely a non OO approach requiring maintenance in several places in the code, and the disadvantages of having less performance on the speed metric.

I think it is capricious to stick to it, except if the Smalltalk flavour you're using does not offer the caseOf: construct.
 
my 0.0199999...

--
Cesar Rabak



Em 13/02/2011 22:32, Schwab,Wilhelm K < [hidden email] > escreveu:
That's where I typically use a dictionary.  Map the numbers to what is often a factory (a factory that reads from a stream being a common scenario) or sometimes closures.  Create the map once on class initialization or once per "session" (or at least try not to build the map "every time"), and the result is reasonably efficient.  It is really no different from what Smalltalk user interface frameworks do to dispatch messages to objects.  Obviously, if the numbers are contiguous, one could use an array, but I find a dictionary convenient because there is no need to mess with offsets.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stephen Taylor [[hidden email]]
Sent: Sunday, February 13, 2011 6:21 PM
To: [hidden email]
Subject: Re: [Pharo-project] could we agree to remove caseOf:   and     caseOf:otherwise:

Igor Stasenko wrote:

>> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a
>> variable's value is equal to any of these...

> Don't try to convince me that there are sort of problems which can be
> solved only by using case statement :)

You didn't answer the question though.

> First, get rid of these integers in your code.

That's the killer - yes, we can usually design around cases where we'd
use case constructs (though I'm not convinced they're the spawn of the
devil) but what about cases where we're interfacing with external data
sources and we don't get to redesign the whole system to suit our needs?



 Steve

Adrien,

Case (a.k.a "switch") constructs are not "so bad in Smalltalk" only, they are considered bad OO practice and it is tabled in the "The Object-Orientation Abuse" code smell when refactoring.

there is an abundant literature about it that you can find online, so I'll refrain to make this post to long.  If you folks think it is worth, we can open a different thread...

--
Cesar Rabak



Em 14/02/2011 20:33, Adrien BARREAU < [hidden email] > escreveu:


Hi,

I'm sorry to interrupt that discussion, but I read all the messages about that subject since you started to discuss it and I really would like to understand a thing:
Why does the case structure seem to be so bad in Smalltalk?

I hope some of you could explain me :)

Adrien.
 

I am not completely certain who is on which side here anymore, other than #caseOf: is at the center of it.  I think I saw Eliot say that Cog uses it; if I got that right, it's a pretty compelling reason to keep it in the image.  Doing that, either for Cog's benefit, or even just for the convenience of a subset of users does not necessarily imply that Pharo itself needs to use the message.  That is about the limit of what I can offer in the form of guidance, and it is really more of a question: could Pharo be changed to ignore the message, and then keep it in the image for Cog and other users?  Maybe that is too idealistic, or just plain naive :)

Mapping integers from the outside world to objects and/or behavior is something that I do a lot.  I have to more or less agree with Sig; case statements as such generally point to room for a design to better exploit messaging.  There are indeed scenarios (especially if not exclusively in external interfacing) that call for mapping numbers to actions.  I have had great results with dictionaries for that purpose, but I am not trying to squeeze every last byte code per second out of a portable VM.  

There have been situations in which Smalltalkers have climbed the ivory tower and looked with contempt on things that make the world work.  I am not convinced that is happening here.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of [hidden email] [[hidden email]]
Sent: Tuesday, February 15, 2011 1:23 PM
To: [hidden email]
Subject: Re: [Pharo-project]    could we agree to remove caseOf: and    caseOf:otherwise:

Em 13/02/2011 21:21, Stephen Taylor < [hidden email] > escreveu:
Igor Stasenko wrote:

>
> >> You  have some  integers: 0  83 67  77  68 72  80 112  113 87  70
> >> 82. When a variable's value is equal to any of these...
>
> > Don't try to convince me that there are sort of problems which can
> > be solved only by using case statement :)

Igor's attitude, which I'll take as sample of a school of thought is dangerously
similar to the  one which in name of keeping certain aspects of Smalltalk "pure"
or near to the origins has made its acceptance  fall as the other aspects of the
technology (OO, WIMP, etc.), made their way into other languages/platforms/technologies.

>  You didn't answer the question though.

And then this: to the first concrete example, no complete answer comes out which we
could check if the code construct is indeed only a syntactic sugar, or deserves
incorporation in the toolset of the language...

>  > First, get rid of these integers in your code.
>  That's the killer  - yes, we can usually  design around cases where
> we'd use case constructs (though I'm not convinced they're the spawn
> of  the devil)  but what  about cases  where we're  interfacing with
> external data sources and we  don't get to redesign the whole system
> to suit our needs?

FWIW, this kind of need, namely having to take alternate actions due different
integer codes is pretty common when interfacing with industrial boards, a lot of protocols use this as well and most of them are already in use, some even have international standards.

So the answer "redesign your world to fit our world-view" does not cut in...

Also, another argument I've seen in this thread which is pretty commonplace w.r.t. performance must be extirpated in our discourse: "the performance x to y slower than <baseline implementation> is very good considering {dynamic} languages (or similar statement)".

Performance counts!  One of the reasons we're working in Pharo is to bring its performance on par with competitive technologies.  We're doing things to take out 'cruft', some to make the abstractions more elegant, but some are pragmatic which require depart of breaking 'pure' Smalltalk OO way of thinking.

--
Cesar Rabak


>
>
>  Steve
>

On 15 February 2011 19:23,  <[hidden email]> wrote:
I am not opposed to innovations or cross-breeding techs.
My purism lies on simple principle: KISS.
If something could be made simpler without losing key features then it
should done.


>>  You didn't answer the question though.
>
> And then this: to the first concrete example, no complete answer comes out which we
> could check if the code construct is indeed only a syntactic sugar, or deserves
> incorporation in the toolset of the language...
>
I don't see a need of explaining how to interpret a simple translation
without using caseOf: statement.

>>  > First, get rid of these integers in your code.
>>  That's the killer  - yes, we can usually  design around cases where
>> we'd use case constructs (though I'm not convinced they're the spawn
>> of  the devil)  but what  about cases  where we're  interfacing with
>> external data sources and we  don't get to redesign the whole system
>> to suit our needs?
>
> FWIW, this kind of need, namely having to take alternate actions due different
> integer codes is pretty common when interfacing with industrial boards, a lot of protocols use this as well and most of them are already in use, some even have international standards.

And i suspect that all these standards are properly documented, and
each signal/number having its description,
so you can represent them by names, not by numbers.

>
> So the answer "redesign your world to fit our world-view" does not cut in...
>

I'm not asking you to redesign C world to fit smalltalk view. Use each
tool what it made for.
What i asking is to not use a microscope for hammering nails. Hammer
is much better tool for that.

> Also, another argument I've seen in this thread which is pretty commonplace w.r.t. performance must be extirpated in our discourse: "the performance x to y slower than <baseline implementation> is very good considering {dynamic} languages (or similar statement)".
>
> Performance counts!

Sure. At some point if you train long enough you can hammer nail using
microscope much faster than using hammer. But that still doesn't means
that you doing it right :)



--
Best regards,
Igor Stasenko AKA sig.

Em 15/02/2011 10:37, Igor Stasenko < [hidden email] > escreveu:

Whereas I understand we are community of spirited and humorous programmers, I think that statements like:

> I  agree.    Then  probably,  Pharo  should  move   it  to  separate
> 'Crap-compat' package.

Are not amenable to the "good energy" Stef is willing to have in the Pharo team.

>  ;-P

And the emoticon puts a tongue!

The 'nickname' brings a judgment of value which I think may stir more
feelings and doesn't bring anything useful to Pharo...

>  You don't need to remove  #caseOf: implementation. I can stay. Just
> remove a compiler hacks for it :)
>  P.S. i patched MessageNode class>>initialize to test if VMMaker can
> work without compiler  support of caseof: and as  it was expected it
> works quite well.
>  I recompiled VMMaker package and then generated full source code of
> everything, and then built VM. No any errors.

And what would be the results of Levente's benchmark?


--
Best regards,
Igor Stasenko AKA sig.

On 15 February 2011 19:59, Eliot Miranda <[hidden email]> wrote:
so why not put it:

^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF

?
Or this will be slower than caseOf: ?


>>
>>        - it could be packaged with VMMaker
>
> No.  It needs to be in the compiler to be inlined.  Why have you got on this
> hobby-horse?  It is a non-issue.  caseOf: ios not widelty used but extremely
> useful in certain circumstances.  This has the feeling of a religious
> pogrom, not a rational approach to the system.  IIABDFI = If It Ain't Broke,
> Don't Fix It.

This concept kinda appeal to me.
From other side, i am also strongly feel that house should be kept clean :)



--
Best regards,
Igor Stasenko AKA sig.

On Feb 15, 2011, at 7:59 PM, Eliot Miranda wrote:

Does simulator needs to be fast?

Then I have no problem that this code is in VMMaker. If this is essential.

>  - it could be packaged with VMMaker
>
> No.  It needs to be in the compiler to be inlined.  Why have you got on this hobby-horse?

Absolutely not. There are a lot of stuff that can follow the same argument.
And at the end we will have a system with a lot of stuff nearly used and more or less useful.

I want Object to be cleaned. I want a clean compiler. I want to minimize our pain. and not having to decompile
caseOf: = less pain less works less maintenance....

I want to have a real clean kernel

>  It is a non-issue.  caseOf: ios not widelty used but extremely useful in certain circumstances.  This has the feeling of a religious pogrom, not a rational approach to the system.

This is what you believe but this is rationale. Why do we have 400 methods in Object, 800 in Morph (and we already removed a lot of them).
       

>  IIABDFI = If It Ain't Broke, Don't Fix It.

No sorry are telling to marcus that instead of doing something cool he should burn his time on decompiler for a message that is used by
3 tools? Am'i hearing you saying that? Please let me know instead of telling me that I focus on the wrong stuff to fix.
And breaking senders and implementors and probably pretty printing.

Do we care about having a decent compiler? This is more than 2 years that I want a compiler with an open infrastructure
so that we can have first class instance variables (like in CLOS since 1990). I want to have Maggrite like meta description integrated and
I want daemons in less than 10 lines of code. Not copying a complete compiler like in Tweak. We prototyped first class instance variable with **no** runtime cost in one afternoon 2 years ago and this is still not our image. Why because there are fucking stuff everywhere.

When do we really invent something new in this wonderful community or are we just doomed to stay doing fucking maintenance of
CRAPPPPPPY code. Because let us face it this is about that. I'm doing pharo to move on and reinvent the system.

If we do not reconsider past choices why do we need filesystems? It works no so do not fix it.
Streams too, Morphic yes it works, browser (come on we are the only system on earth where Car inherits from Wheel - yes us
the inventors of OOP - laughable - you should see some of our students they laugh a lot. Because Browser inherits from StringHolder....

So do we want that because if we want that. I'm off.

> Are these two points correct?
>
> No, IMO, definitely not.
>  
>
> Stef
>
>