comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adam@irvine.com>
Subject: Re: worrying behaviour
Date: Fri, 2 May 2008 11:31:31 -0700 (PDT)
Date: 2008-05-02T11:31:31-07:00	[thread overview]
Message-ID: <e21f177f-fd90-4bc1-9b74-a367690fc68f@w4g2000prd.googlegroups.com> (raw)
In-Reply-To: b4ce25f9-32a7-46e0-b752-7b53482224d3@m44g2000hsc.googlegroups.com

On May 2, 10:41 am, echancr...@gmail.com wrote:

> Thanks Adam for your comprehensive answer.
> I know there is no error here, I just thought that if you explicitly
> bother to provide a renaming operator declaration it would be
> reasonable for the compiler to expect an explicit definition for it...

Not at all; I think it's quite common to rename implicitly declared
operators.


> Of course declaring the type private would highlight the problem
> but ... are you really sure that in the real world those mistakes are
> not made? (would be pretty hard to detect and would probably only be
> revealed on boundary cases)

They may well be made.  But a compiler can't reasonably catch all
mistakes.


> After all what is the point of renaming an operator and not provide an
> actual body for it but the default one?

To be able to use the operator without having to USE the package.  USE
TYPE makes this less necessary, but there's a lot of legacy code out
there written before Ada 95.  Also, there may be reasons why USE TYPE
is undesirable in particular situations, but I'm not sure what they
are... perhaps others could elaborate if there are.

Actually, now that I think of it, your question doesn't make that much
sense.  Other than the reason I've alluded to (i.e. making an operator
visible), I don't see any point to renaming an operator that *does*
have an actual body for it---I don't see why the explicitness or
implicitness of the operator's definition makes any difference.

(There are cases where you need a rename to avoid an ambiguity, but in
those cases you wouldn't be renaming an operator to the same operator
string, so I'm assuming that case isn't relevant to this discussion.)

                             -- Adam




  reply	other threads:[~2008-05-02 18:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 15:26 worrying behaviour echancrure
2008-05-02 15:54 ` Adam Beneschan
2008-05-02 17:41   ` echancrure
2008-05-02 18:31     ` Adam Beneschan [this message]
2008-05-03  1:15   ` Randy Brukardt
2008-05-03  2:04     ` Adam Beneschan
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox