[Oberon] Message Objects in Oberon

[Jörg Straube]

I see it exactly as you mentioned it yourself
- a „parameter" is an argument to a subroutine with type checking at compile time
- a „message" is an argument to a subroutine with type checking at run time.

Jörg

> Am 31.03.2016 um 03:37 schrieb Lars <noreply at z505.com>:
> 
> On Mon, March 28, 2016 12:42 am, Douglas G. Danforth wrote:
>> Srinivas,
>> 
>> 
>> I think you have put your finger on one of the
>> (in my opinion) weaknesses of Oberon
>> (and BlackBox).  I do not like those kind of
>> messages.  They seem to be necessary when one "broadcasts" to many
>> different, say, Views where the broadcaster doesn't know who will handle
>> the message.  That feels wrong to me, but I don't have an alternative.
>> 
>> -Doug Danforth
>> 
> 
> Yikes, this sounds like Smalltalk philosophy where objects don't know much
> about anything, and this is considered a "feature", not a bug.
> 
> Has anyone even come up with a scientific or mathematical definition of
> why a message is not the same as sending in a parameter into a procedure
> or function?
> 
> It has always bothered me, the numerous terms people use.. message,
> parameter, argument.. instead of one rigorous scientific definition..
> 
> If I have a function add(x,y) who is to say X and Y are not messages being
> sent in to the Add object or the Add procedure, or function? What's a
> message?
> 
> Is a C language variadic function, where you can send any parameters you
> want into the function, similar to not knowing much about anything? You
> can send any message into the function, of any type, and then it is
> checked later at run time, not at compile time, as to what you are sending
> in to the function or procedure.
> 
> I wonder if when people use variadic functions, they are emulating
> something that OOP languages like smalltalk have where an object doesn't
> have to know much info about particular messages except at run time when
> it's negotiated.
> 
> Likely there are some overlaps between languages that previously people
> didn't see the connection.
> 
> Then there is reflection, interfaces that aren't specifically predesigned
> up front and left empty to extend... inheritance that leaves the object
> open to anyones extension later...  These all seem like concepts that are
> highly unprovable programs at compile time or at initial design.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon