View mode: basic / threaded / horizontal-split · Log in · Help
August 19, 2003
Add another access specifier
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.
August 19, 2003
Re: Add another access specifier
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
August 19, 2003
Re: Add another access specifier
>
> 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 ...
August 19, 2003
Re: Add another access specifier
"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).
Top | Discussion index | About this forum | D home