|Language design question firstname.lastname@example.org (2000-02-13)|
|Re: Language design question email@example.com (Chris F Clark) (2000-02-13)|
|Re: Language design question firstname.lastname@example.org (James Jones) (2000-02-15)|
|Re: Language design question email@example.com (2000-02-15)|
|Re: Language design question firstname.lastname@example.org (2000-02-16)|
|Re: Language design question email@example.com (Joachim Durchholz) (2000-02-16)|
|Re: Language design question firstname.lastname@example.org (Joachim Durchholz) (2000-02-17)|
|Re: Language design question email@example.com (Keith Thompson) (2000-02-19)|
|Re: Language design question firstname.lastname@example.org (Tom Payne) (2000-02-19)|
|Re: Language design question Andrew.Walker@nottingham.ac.uk (Dr A. N. Walker) (2000-02-27)|
|Re: Language design question email@example.com (2000-03-21)|
|Re: Language design question firstname.lastname@example.org (Frederic) (2000-03-25)|
|[1 later articles]|
|From:||"Joachim Durchholz" <email@example.com>|
|Date:||16 Feb 2000 23:43:10 -0500|
Shaun Flisakowski wrote:
> > Does anyone see any problem with [not having an explicit
> > dereference operator] that I'm overlooking?
> > Are there any existing langues that handle this similarly?
Ah, now I understand the question (lazy me not reading lots of code).
Yes, there is. Eiffel does not have an explicit dereferencing
operator; it just has path expressions of the form "base.selector",
where "selector" can be an attribute or a parameterless function,
returning either a direct attribute or a reference to an object. For
the theory behind the first aspect of this language design, take a
look at http://www.elj.com/elj/v1/n1/bm/urp/. (A word of caution: the
author, Bertrand Meyer, can put his arguments in a very convincing
manner even if he is dead wrong. This doesn't mean he is dead wrong
very often, this is more the exception... but it means that you have
to be careful to spot the assumptions that are the basis for his
reasoning, and evaluate whether your assumptions match his or not.)
Language-wise, unifying references and nonreferences is not a problem,
and it's also not a problem in programming. It does make for some
confusion when it comes to discussions that dwell on the fine points
of references, sharing, and such, so this is less a technical question
(no problems here) but a psychological one (do the programmers
understand what they're doing - and if they don't understand, is the
language constructed so that it does not matter?).
Return to the
Search the comp.compilers archives again.