Re: The old "Object.Method" syntax debate

[john@nospam.demon.co.uk (John McCabe)]

On 27 May 2003 20:02:21 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>I agree that there may be those troubles with this notation, but there are
>significant gains also. Potential confusion with component is one side of
>this change, but another side is abstraction step for the concept of component.
>In other words, there are cases where it is significant to know that a member
>of composite type is really represented by corresponding data element; but
>there are plenty of cases where flexibility is more desirable, that is, our
>layer should not depend on whether that member actually has consolidated
>reprepsentation in memory or it is computed on demand.

That is an interesting point and, I believe, directly analogous to the
Ada concept of using the same type of parentheses for array acceses
and function parameters.

>  Real problem with this "object notation" for operations in Ada is that there
>is no clear understanding where this notation is for good and where it is for
>evil. AI-252 mentions "controlling" object, and yes, there are plenty of cases
>where we really have some controlling object, and in those cases that "object
>notation" often are justified (after all, in such cases this notation actually
>carries useful information, explicitly pointing out at the controlling object).
>But unfortunately there is very big "grey zone" where controlling objects are
>doubtful, and there are many cases without natural controlling objects at all.

To be honest I've always had a little difficulty with controlling
objects and the Ada 95 syntax. I think this may be because I was
trying to get a feel for C++/Java/VB at around the same time as I was
learning to use Ada 95 and the object.operation syntax seemed so
obvious and simple to me.

>I think that it would be wrong to take away that exclusive privilege --
>to introduce attributes -- from the language designers and compiler vendors.
>The name space for attributes is too important language resource, it should
>not be given out freely for general use.
>  How about another character instead of apostrophe (or dot) for user-defined
>attributes? For example, there is quite popular # (read "join" for this purpose):
> Object#Operation 
>("controlling object" somehow associates with "base" -:)

Nah - that's ugly :-)


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'