--On 02 March 2004 12:48 -0700 James Giles <[log in to unmask]>
wrote:
> Craig Dedo wrote:
> ...
>> [...] All of
>> the vendors that have implemented this extension use the same rule in
>> cases of ambiguity. In such cases, structure component delimiter takes
>> precendence over other uses of period, i.e., the period is a structure
>> component delimiter and **NOT** an operator delimiter.
>
> That can't be the rule. The whole purpose of defined operators is
> to allow the programmer to create operators that work on his
> derived types. What you mean is that the implementations apply
> the rule you cite *only* if there's an ambiguity, not that they
> *always* treat period as a component selector. That is, the
> string X.Y.Z will be interpreted as a single qualified name if Y
> is a component name of the X's type, even if .Y. is an operator
> that's visible in the same context. But, .Y. will be treated as an
> operator if X's type has no component called Y. Of course, it's
> just an error if Y is neither an operator nor a component name.
>
> Given that clarification, I'm still not sure I like the rule, but I
> suppose it's tolerable.
No it is not tolerable. It is a totally unecessary cosmetic change to add
the use of period as the component selector.
However in a private reply a suggestion that should be considered was to
use @ as an alternative selector when the order is component@structure and
also to permit arraycomp@arraystructure selections that map simply to
multidimensional array.
>
> --
> J. Giles
--
Lawrie Schonfelder
Honorary Senior Fellow
University of Liverpool
1 Marine Park, West Kirby,
Wirral, UK, CH48 5HN
Phone: +44 (151) 625 6986
|