On 15/10/2020 13:03, Anton Shepelev wrote:
we definitely should have sticked with Alan Kay's
"message-sending", and there would be much less
misunderstandings and problems today.
I fear this message-passing approach even further from
normal proceudural prgramming that conventinal OO languages
and would therefore be even more confusing and unintuitive.
It is not an approach per se, but just terminology.
And when coming from Assembler/C/C++, like I do, it is a very confusing
one: At the end of the day, it is always just about pushing the
arguments on the stack and picking the subroutine address to which the
CPU shall branch, whether that address selection is static (and can
therefore be done at compile time), virtual (i.e. based on the object
the function is called for, which requires a (quick and simple) virtual
function table lookup for the object's class at runtime), dynamic (i.e.
based on the object and the argument types on the stack, like Groovy
does), or completely custom implemented in the language itself (as can
be done in Groovy).
It is never about passing messages from one object to the other, which
to me implies creating messaging objects, which are being put into a
queue for asynchronous processing by the receiving object (possibly with
prioritization, ...), and maybe being sent over a network connection,
etc. So a much more heavy & slower mechanism than what actually takes place.
Of course one often times finds logical/natural what one first
encountered, but keeping that in mind, from what lies underneath it,
calling it a method call with passed arguments still makes the most
sense to me.
Cheers,
mg
