Re: Rational for not making cursor tagged in Containers

On Fri, 20 Apr 2007 11:26:08 +0200, Maciej Sobczak wrote:

Dmitry A. Kazakov wrote:

A confusion is in assumption that some arguments of an operation are more
arguments than others.

There is some rationale for this, however.
With the traditionally abstract OO, operations are executed as a result
of messages that are sent to objects. Now that indeed gives some objects
more focus than others.

This:

a.op(b);

means (supposedly) that "op" message is sent to object "a" and the
payload of the message is "b".

I agree that it introduces some asymetry that is not necessarily needed.
I mean - the above abstraction is not necessarily the best one, but
serves me well as an explanation of the a.op(b) issue.

Ah, yes, messaging is an interesting issue.

Another is that primitive operations belong to the
object (instance).

No, but it makes sense to think that they belong to the type of some object.

They do, if all arguments had the same type. But if they don't?

The third confusion raises from incompatibility of the
prefix notation with multi-methods and multiple dispatching operations.

True. But then, the above messaging abstractions needs to be extended to
cover "multicasts". :-)

That is one problem. Another is that you still have dedicated arguments,
i.e. ones marshaled (parameters) and ones referenced (recipients). But it
is not in Ada way to distinguish by-copy and by-reference. Why should
anybody care, why should it be syntactically highlighted? Another problem
is the sender. The sugar a.op(b) tells nothing about who issued the
message. While the paradigm tells about messages sent *between* objects.
This adds additional asymmetry, c, the sender is invisible and actually is
a context rather than object. I.e. there are three animals:

1. the recipient (a fully decorated object, blue blood)

2. the parameter[s] (value, hard-wired thing nobody knows what,
"non-tagged", as Ada calls it (:-))

3. the sender's context, which is even not a value.

Looks like a mess, even without multicasting, or messages with acknowledge,
or remote calls on local objects...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Attachment Issue
    ... SMTP connector: Only messages less than is un-ticked ... However, if the attachment was over 10MB, shouldn't the sender get a Delivery Failure notification message? ... 5MB in size are not being received by Exchange recipients. ...
    (microsoft.public.exchange.clients)
  • Re: Mail Server
    ... >> the spam folder in my MUA, the few passing are moved manually. ... > ways to bombard people with increasing numbers of e-mails, and recipients ... regardless of the sender's pure intentions. ... regardless of who the sender is. ...
    (comp.os.linux.misc)
  • Re: Mail Server
    ... > the spam folder in my MUA, the few passing are moved manually. ... ways to bombard people with increasing numbers of e-mails, and recipients ... regardless of the sender's pure intentions. ... regardless of who the sender is. ...
    (comp.os.linux.misc)
  • Re: Just what the h can we do with "sender" - new guy question
    ... In the context you describe the sender is not much use to you. ... The data that you want to deal with is in the treeview. ... If it's a reference to the object that fired the event, ...
    (microsoft.public.dotnet.languages.csharp)
  • Event ID: 32090 "send to fax" wizard
    ... Sender User Name: user ... This only occurs when there are multiple recipients. ... to go on are that it broke in RTM SBS 2003 after a month or so. ...
    (microsoft.public.windows.server.general)