www.digitalmars.com         C & C++   DMDScript  

D - Add another access specifier

reply "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.
Aug 19 2003
parent reply 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
Aug 19 2003
next sibling parent "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 ...
Aug 19 2003
prev sibling parent "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).
Aug 19 2003