Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!solaris.cc.vt.edu!news.vt.edu!newspump.monmouth.com!newspeer.monmouth.com!news.xnet.com!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!not-for-mail
From: buzzard@TheWorld.com (Sean T Barrett)
Subject: Re: [TADS] A subtle incompatibility between 2.2 and 2.5.5
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <Gu4sMD.IBE@world.std.com>
Date: Sat, 6 Apr 2002 05:30:12 GMT
References: <a7sdvj$2oa$1@news.lth.se> <y77r8.980$AB3.234097686@newssvr21.news.prodigy.com> <Gu328o.97r@world.std.com> <r%mr8.4$oe6.758@news.oracle.com>
NNTP-Posting-Host: shell01.theworld.com
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: trn 4.0-test72 (19 April 1999)
Lines: 48
Xref: news.duke.edu rec.arts.int-fiction:102657

mjr wrote:
>Well, it's more a matter of scoping than of precedence; the "." operator
>implies something about the scope of its right operand.  You make a valid
>point that this is different from, say, "+" or "-", and I can understand why
>one would want to design a language where operators were completely regular.
>TADS has its roots in C and Java, though, where this kind of operator
>irregularity is not unheard of - C and Java both treat "." the same way tads
>3 does, for example, and the assignment operator in all three languages
>gives its left operand a special interpretation.

Sure, but C doesn't *have* the option to make the right side
of a "." be a variable, so I'm not sure that analogy helps--
I don't know what Java does. (A different C analogy below.)

Now, I have to admit, I was over-stating my case a bit;
in my scenario, the default interpretation of 'foo.bar' where
bar is a variable is that you dereference the variable expecting
a property pointer, and 'foo.&bar' always gets the property
named bar, but if there is no variable 'baz' you can simply
type 'foo.baz' (not 'foo.&baz') to reference a property on
foo, then clearly "." does have a little magic going on about
its RHS--it does imply a special context for evaluating an
identifier there (if it's a bare identifier that has no other
meaning, interpret it as a property pointer--something we don't
do in most other expression contexts, although we could allow
something along those lines if we allow 'baz' all by itself
to mean 'self.baz' if we know that self is declared to have a
baz; however, this starts to get messy as 'foo.baz' wouldn't
be checking at compile time whether baz is a property name on
self, or or foo).

In C, though, function pointers "auto-dereference"; in

   void my_iter(Object **obj, void (*func)(Object *o))
   {
      ...
         func(obj[x]);
      ...
   }

I don't have to write "(*func)(obj[x])" even though
that's "really what I mean". To me, the ability to pass
a property pointer into a function and use the
notation "foo.func(y)" is a similar convenience. And
it makes it much easier to read the code and see what's
happening if you're familiar with the technique.

SeanB
