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

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Feb 15 20:19:03 CET 2011


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

> 
> 
> On Mon, Feb 14, 2011 at 11:00 PM, Stéphane Ducasse <stephane.ducasse at inria.fr> 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
> 
> No.  If it is not inlined the simulator will go *much* slower.  e.g.
> 
> CogVMSimulatorLSB>>byteAt: byteAddress
> 	| lowBits long |
> 	lowBits := byteAddress bitAnd: 3.
> 	long := self longAt: byteAddress - lowBits.
> 	^(lowBits caseOf: {
> 		[0] -> [ long ].
> 		[1] -> [ long bitShift: -8  ].
> 		[2] -> [ long bitShift: -16 ].
> 		[3] -> [ long bitShift: -24 ]
> 	}) bitAnd: 16rFF
> 

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





More information about the Pharo-project mailing list