Kind of because we got
or:
Boolean * block -> Object
and now we have
Object * Object -> Object
I already discussed by emails too mcuh this point with marcus.
Since we do not have even the start of a process to document the design
rationale behind
such decisions I will not discuss it. But I do not like that we have
such ad-hoc process and I
do not think that the ratio of impact and interest is valuable.
Sure now we can define or: in our class and try to find its senders by
browsing at least on of the 1590 senders (quite pratical). And if one
day we will have a type inferencer for Pharo code we just removed some
of the few cases
where we could do something. (and this is true that Booleans are not the
basis for building types analysis).
Stef
Le 1/5/15 11:58, Thierry Goubier a écrit :
Le 01/05/2015 11:50, Marcus Denker a écrit :
On 01 May 2015, at 11:48, stepharo <[email protected]> wrote:
To make the whole thing easier to understand we need to distinguish
the two bugs.
1) or: is somehow special. No, it is not. We fixed that, but the
fix was broken.
See my other mail.
I would add two different kind of rules to help people and slow the
use of redefinition of special selectors.
I do not understand why.
I side with Marcus there. Why?
You now have a compiler which does not make those selectors special,
and you want to keep them special?
Thierry
Marcus
