Re: package access specifier not usable within a class
On Thu, 08 Sep 2011 21:23:00 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: Neither private nor protected functions are ever virtual at this point, Jonathan meant to say neither private nor *package* functions. protected functions are virtual. -Steve
Re: package access specifier not usable within a class
On Friday, September 09, 2011 07:15:09 Steven Schveighoffer wrote: On Thu, 08 Sep 2011 21:23:00 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: Neither private nor protected functions are ever virtual at this point, Jonathan meant to say neither private nor *package* functions. protected functions are virtual. LOL. Ouch. Thanks for the correction. Yes private and package are not virual. Protected definitely is. It would be pretty useless otherwise. - Jonathan M Davis
Re: package access specifier not usable within a class
Andrej Mitrovic , dans le message (digitalmars.D.learn:29388), a écrit :
abstract class Foo
{
package void test();
}
class Bar : Foo
{
override package void test() { }
}
function test.Bar.test cannot override a non-virtual function
TDPL says package can only be used at class-level (i.e. package class
Bar : Foo), outside classes or inside a struct.
I want to hide a virtual method from client code, but another free
function in a different module but in the same package as these
classes needs access to that method. Are there any technical reasons
why package is not allowed for virtual methods?
private function are not virtual.
All non-static non-private non-template member functions are virtual
The spirit of this is that if a function is private, it should not be
seen by its subclasses, which makes sens. However, this is a bit
inconsistent with the fact that it can actually be seen by the whole
file. It seems that package function inherited from the same behavior,
enlarging this inconsistency.
Your request seem to be reasonable, so I would say the langage should be
improved in two ways:
- private (and package) function can be specifically made virtual, but
the problem is that virtual is not a keyword in d, and that would be
weird to have to write final sometimes, and virtual some other times.
- package function are virtual by default, which is the best solution
IMO. It's not a huge problem if private methods cannot be virtual, if
you can make them package virtual.
In the meantime, I would make the method public, but prefix the name
with an underscore to indicate it is morally private. I agree that it is
relying on the client's good will.
--
Christophe
Re: package access specifier not usable within a class
Christophe, dans le message (digitalmars.D.learn:29394), a écrit :
Andrej Mitrovic , dans le message (digitalmars.D.learn:29388), a écrit :
abstract class Foo
{
package void test();
}
class Bar : Foo
{
override package void test() { }
}
function test.Bar.test cannot override a non-virtual function
TDPL says package can only be used at class-level (i.e. package class
Bar : Foo), outside classes or inside a struct.
I want to hide a virtual method from client code, but another free
function in a different module but in the same package as these
classes needs access to that method. Are there any technical reasons
why package is not allowed for virtual methods?
private function are not virtual.
All non-static non-private non-template member functions are virtual
The spirit of this is that if a function is private, it should not be
seen by its subclasses, which makes sens. However, this is a bit
inconsistent with the fact that it can actually be seen by the whole
file. It seems that package function inherited from the same behavior,
enlarging this inconsistency.
Your request seem to be reasonable, so I would say the langage should be
improved in two ways:
- private (and package) function can be specifically made virtual, but
the problem is that virtual is not a keyword in d, and that would be
weird to have to write final sometimes, and virtual some other times.
- package function are virtual by default, which is the best solution
IMO. It's not a huge problem if private methods cannot be virtual, if
you can make them package virtual.
In the meantime, I would make the method public, but prefix the name
with an underscore to indicate it is morally private. I agree that it is
relying on the client's good will.
--
Christophe
I forgot about protected. Making the function protected may be fine.
Re: package access specifier not usable within a class
On Friday, September 09, 2011 03:05:05 Andrej Mitrovic wrote:
abstract class Foo
{
package void test();
}
class Bar : Foo
{
override package void test() { }
}
function test.Bar.test cannot override a non-virtual function
TDPL says package can only be used at class-level (i.e. package class
Bar : Foo), outside classes or inside a struct.
I want to hide a virtual method from client code, but another free
function in a different module but in the same package as these
classes needs access to that method. Are there any technical reasons
why package is not allowed for virtual methods?
Neither private nor protected functions are ever virtual at this point, though
it is likely that that will be changed to match TDPL. There are a number of
bugs on the matter. Among them are
http://d.puremagic.com/issues/show_bug.cgi?id=4542
http://d.puremagic.com/issues/show_bug.cgi?id=3581
http://d.puremagic.com/issues/show_bug.cgi?id=3258
- Jonathan M Davis
Re: package access specifier not usable within a class
Thanks. I'll refactor my code to eliminate the need for package in this case. I was going to use it as a quick workaround anyway. :)
