Sean
When the compiler inlines some methods, I would find it most surprising if it
was turned of in half the code (or just in yours :-) ). When I am reading some
code, I would rather have some consistency.
So I would just implement a whenNil: method which is a true message, and put a
comment i
Richard,
My _concern_ with inlining is that since it is designed to short-circuit
dynamic method lookup, it is impossible to call a _different_ implementation.
That is, you lose the opportunity to have the _receiver_ decide how to respond
to the message. You may think of it as a message, but th
We're still not on the same page.
You seem to have some ideological objection to inlining that
I am completely failing to comprehend.
Just because a procedure call (message send) is inlined doesn't
in the least mean it *isn't* a procedure call (message send),
just as compiling a procedure call (mes
Congratulations! And thanks!!
On Wed, Mar 16, 2022 at 6:24 AM teso...@gmail.com wrote:
> Hello,
> I have released a new version of the Pharo VM for Pharo 9 and Pharo 10.
> This VM is accessible right now from Zero-Conf, updating it in the Pharo
> Launcher or using the usual downloads (as descr
it's impossible to talk about a project that i don't understand.
this sentence
*In the second code especially, the problem is that `position` could be
many types that are not in the same hierarchy,*
draw my attention, because i did many hierarchies when you don't need to
do it. just use polymorph
On 3/16/2022 8:33 PM, s...@clipperadams.com wrote:
I care because it makes “everything is a message” a lie! And I suspect
(no proof and could be wrong) it’s an optimization that only made
sense with the hardware constraints of 40+ years ago. Arguing against
premature optimization is hardly some
> if you are using the null object pattern then you should not write those
> checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to
> an instance of the null object and that object should decide what to do.
> just an opinion.
I agree as a general rule, but it can get complicated
> To start with, why do you CARE whether a particular
> method is inlined or not?
I care because it makes “everything is a message” a lie! And I suspect (no
proof and could be wrong) it’s an optimization that only made sense with the
hardware constraints of 40+ years ago. Arguing against prematu
Congratulations on the release :-)
On Wed, Mar 16, 2022 at 11:24 AM teso...@gmail.com
wrote:
> Hello,
> I have released a new version of the Pharo VM for Pharo 9 and Pharo 10.
> This VM is accessible right now from Zero-Conf, updating it in the Pharo
> Launcher or using the usual downloads (as
Hello,
I have released a new version of the Pharo VM for Pharo 9 and Pharo 10.
This VM is accessible right now from Zero-Conf, updating it in the Pharo
Launcher or using the usual downloads (as described in pharo.org/download).
This version includes a series of bug fixes.
Changelog:
- Correct
Pattern? I'd call it an antipattern myself.
Note that we can already construct
{ block1
. block2
. block3
}
and write
{ block1
. block2
. block3
} allSatisfy: [:each | each value].
so we don't have to abuse the #, selector
or write a single new method to get the "flattened"
structu
The motivating example can be written
aHasDot := a includes: $..
bHasDot := b includes: $..
^aHasDot = bHasDot
ifFalse: [bHasDot]
ifTrue: [aHasDot
ifTrue: [a < b]
ifFalse: [a > b]]
(Dijkstra was right. People *do* forget that '='
12 matches
Mail list logo
