• Philippe Mori (10/10) Aug 19 2003 I think we could add the access prohibited for functions we do not
• Ilya Minkov (20/24) Aug 19 2003 These all can be called through a base class anyway, hence i see little
• Matthew Wilson (5/14) Aug 19 2003 I like the separation of errors and exceptions in Java, though I'd be ha...
• Philippe Mori (21/33) Aug 19 2003 I was not thinking about access by a base class... but more for

"Philippe Mori" <philippe_mori hotmail.com> writes:

I think we could add the access prohibited for functions we do not
want to be called (for. ex copy-constructor or an overload that
should not be called for a given type that would otherwise be
converted to another type).

There would be a few advantages over using private (and undefined):

a) the compiler would knows even inside the class or a friend
and would prevent any uses (and not only public or protected ones).
b) better diagnostic by the compiler since the purpose would be known.
c) better documentation by the code...
d) it would be illegal to give a definition for that function.

Ilya Minkov <midiclub 8ung.at> writes:

Philippe Mori wrote:
 I think we could add the access prohibited for functions we do not
 want to be called (for. ex copy-constructor or an overload that
 should not be called for a given type that would otherwise be
 converted to another type).

These all can be called through a base class anyway, hence i see little 
sense in it. Besides, i think this "feature" would invite to (mis)use it 
and thus would encourage bad design. Maybe there should be a library 
exception called something like NotImplemented, then the overload 
function would be a one-liner. This might be visible enough. Besides, 
the compiler may treat it as an error to call a function known to 
consist only of a throw NotImplemented.

I can't really imagine re-using the syntax for unimplemented pure 
virtual functions, which implies that such a class cannot be instantiated.

BTW, isn't it somewhat inconstent that in Phobos exceptions don't have 
anything common in their name, like some have "Error" (ConvError, 
ConvOverflowError) and some have "Exception" (FileException) - maybe all 
should be changed to "Error" to keep it short. It probably doesn't make 
sense to attach "Error" to each (maybe to any at all?) exception, since 
they are used within "throw" and "catch" only anyway. Or go hungarian: 
EOutOfMemory, EConv, EConvOverflow, EFile, ... This is where it seems to 
make sense. Like, "ConvOverflowError" - Overflow is by itself an error, 
do we need tautologies?

-eye

"Matthew Wilson" <matthew stlsoft.org> writes:

 BTW, isn't it somewhat inconstent that in Phobos exceptions don't have
 anything common in their name, like some have "Error" (ConvError,
 ConvOverflowError) and some have "Exception" (FileException) - maybe all
 should be changed to "Error" to keep it short. It probably doesn't make
 sense to attach "Error" to each (maybe to any at all?) exception, since
 they are used within "throw" and "catch" only anyway.

I like the separation of errors and exceptions in Java, though I'd be happy
to hear a counter argument from a real Java aficionado (which I'm not!)

Or go hungarian:
 EOutOfMemory, EConv, EConvOverflow, EFile, ... This is where it seems to
 make sense. Like, "ConvOverflowError" - Overflow is by itself an error,
 do we need tautologies?

I always used to use XOutOfMemory, XOverflow, etc. in my C++ exception
classes. I still kind of like it ...

"Philippe Mori" <philippe_mori hotmail.com> writes:

"Ilya Minkov" <midiclub 8ung.at> a écrit dans le message de
news:bhu80s$2u3q$1 digitaldaemon.com...
 Philippe Mori wrote:
 I think we could add the access prohibited for functions we do not
 want to be called (for. ex copy-constructor or an overload that
 should not be called for a given type that would otherwise be
 converted to another type).

 These all can be called through a base class anyway, hence i see little
 sense in it. Besides, i think this "feature" would invite to (mis)use it
 and thus would encourage bad design. Maybe there should be a library
 exception called something like NotImplemented, then the overload
 function would be a one-liner. This might be visible enough. Besides,
 the compiler may treat it as an error to call a function known to
 consist only of a throw NotImplemented.

I was not thinking about access by a base class... but more for
a root class (since for now it seems that we only have public derivation).

So in fact the feature would be usefull only to disallow predefined
function generated by the compiler.

A good example would be for the predefined function cmp().
Having a modifier would allows the compiler to detect such
comparisons at compile-time which is very desirable in that
case... In fact, if the comparison is seldom done, the program
may even run for a while before we notice the bug that should
have been catch by the compiler...

Well, thinking of it, it should be a function modifier as it
will be usable with free function as well.

Another good uses of it would be to ensure that an obsolete
function is not used anymore.

Or than we do not call a function with wrong parameter type
particulary if a conversion exists but should not be considered
(for ex. in C++, string class can be constructed from a double
or a bool but it will not give the result it should according to
what would be intuitive).