www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - attribute bug?

reply "goofwin" <artem.3a gmail.com> writes:
Hello.

I have code like this:

class MyClass
{
	package abstract {
		void foo();
		void bar();
                 ...
	}
}

I have error after compilation:

Error: function ...foo non-virtual functions cannot be abstract

Code is compiling successed if change it like this:

class MyClass
{
	public abstract {
		void foo();
		void bar();
                 ...
	}
}

Is it bug or don't i know something about it?

PS: Sorry for my bad English.
PSPS: dmd v 2.060
Nov 09 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/9/12, goofwin <artem.3a gmail.com> wrote:
 class MyClass
 {
 	package abstract {
 		void foo();
 		void bar();
                  ...
 	}
 }

package methods are automatically final, you can't have a virtual package method.
Nov 09 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/09/2012 10:05 AM, Andrej Mitrovic wrote:
 On 11/9/12, goofwin<artem.3a gmail.com>  wrote:
 class MyClass
 {
 	package abstract {
 		void foo();
 		void bar();
                   ...
 	}
 }

package methods are automatically final, you can't have a virtual package method.

I knew that about 'private' but apparently 'package' is the same. Ali
Nov 09 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 09, 2012 10:32:55 Ali Çehreli wrote:
 I knew that about 'private' but apparently 'package' is the same.

Yes. public and protected are always virtual unless they're final and don't override anything (in which case, the compiler can choose to make them non- virtual). private and package are always non-virtual. IIRC though, the docs do need to be updated, since they imply that package is virtual, even though that's definitely not the case and isn't supposed to be the case. - Jonathan M Davis
Nov 09 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 06:28, Jonathan M Davis wrote:

 package restricts access to the same package. D has no concept like C#'s
 internal, because it doesn't have assemblies.

I'm not entirely sure how assemblies work in C# but couldn't one say that everything in D is internal unless explicitly marked as export? -- /Jacob Carlborg
Nov 10 2012
prev sibling next sibling parent "goofwin" <artem.3a gmail.com> writes:
On Friday, 9 November 2012 at 18:05:45 UTC, Andrej Mitrovic wrote:
 package methods are automatically final, you can't have a 
 virtual
 package method.

Thanks for help. But i don't understand why can't package method be virtual? What reason of this? PS: Sorry for my bad English.
Nov 09 2012
prev sibling next sibling parent "goofwin" <artem.3a gmail.com> writes:
On Friday, 9 November 2012 at 21:09:06 UTC, Jonathan M Davis 
wrote:
 Yes. public and protected are always virtual unless they're 
 final and don't
 override anything (in which case, the compiler can choose to 
 make them non-
 virtual). private and package are always non-virtual. IIRC 
 though, the docs
 do need to be updated, since they imply that package is 
 virtual, even though
 that's definitely not the case and isn't supposed to be the 
 case.

 - Jonathan M Davis

It is very interested. I thought that 'package' is same as 'internal' from C#. I don't like that public, protected methods is virtual and private, package is non-virtual implicitly. I think that implicit behaviour is bad in most cases. And why can't i change this behaviour explicitly for example by means abstract attribute? PS: Sorry for my bad English.
Nov 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 10, 2012 05:18:17 goofwin wrote:
 On Friday, 9 November 2012 at 21:09:06 UTC, Jonathan M Davis
 
 wrote:
 Yes. public and protected are always virtual unless they're
 final and don't
 override anything (in which case, the compiler can choose to
 make them non-
 virtual). private and package are always non-virtual. IIRC
 though, the docs
 do need to be updated, since they imply that package is
 virtual, even though
 that's definitely not the case and isn't supposed to be the
 case.
 
 - Jonathan M Davis

It is very interested. I thought that 'package' is same as 'internal' from C#.

package restricts access to the same package. D has no concept like C#'s internal, because it doesn't have assemblies.
 I don't like that public, protected methods
 is virtual and private, package is non-virtual implicitly. I
 think that implicit behaviour is bad in most cases. And why can't
 i change this behaviour explicitly for example by means abstract
 attribute?
 
 PS: Sorry for my bad English.

The language is more complicated if you can explicitly choose whether a particular function is virtual or not. It also causes a number of bugs. C++ has issues with it all the time. It certainly _can_ be done, but the language designers chose to go the Java route of making virtuality implicit. On the whole, it's exactly what you want. Generally, public functions need to be virtual. If they don't, you can mark them as final. And it makes no sense for a protected function to be non- virtual. So, both of them are virtual. It doesn't really make sense for private functions to be virtual. If you want them to be virtual, just use protected. And if private were virtual, then that would really hurt performance, and everyone would be forced to mark all of their private functions as final to avoid it. So, it just makes more sense to make them non-virtual. package is more debatable, and some people have argued that it should be virtual, but Walter Bright and Andrei Alexandrescu don't think that it really makes sense to. I'd have to go digging through the archives for the main newsgroup though to find a post where they discuss it to tell you exactly what they said. - Jonathan M Davis
Nov 09 2012
prev sibling next sibling parent "goofwin" <artem.3a gmail.com> writes:
On Saturday, 10 November 2012 at 05:34:32 UTC, Jonathan M Davis 
wrote:
 ...

The language is more complicated if you can explicitly choose whether a particular function is virtual or not. It also causes a number of bugs. C++ has issues with it all the time. It certainly _can_ be done, but the language designers chose to go the Java route of making virtuality implicit. On the whole, it's exactly what you want. Generally, public functions need to be virtual. If they don't, you can mark them as final. And it makes no sense for a protected function to be non- virtual. So, both of them are virtual.

I think that it is unsuccessful decision by the language designers, because object oriented code use virtual functions not much in most cases, thence it is useless and bad for performance or it causes developer to set public and protected functions as final explicitly very much.
 It doesn't really make sense for private functions to be 
 virtual. If you want
 them to be virtual, just use protected. And if private were 
 virtual, then that
 would really hurt performance, and everyone would be forced to 
 mark all of
 their private functions as final to avoid it. So, it just makes 
 more sense to
 make them non-virtual.

 package is more debatable, and some people have argued that it 
 should be
 virtual, but Walter Bright and Andrei Alexandrescu don't think 
 that it really
 makes sense to. I'd have to go digging through the archives for 
 the main
 newsgroup though to find a post where they discuss it to tell 
 you exactly what
 they said.

 - Jonathan M Davis

I agree with everything that you say about private functions and i agree with people who have argued that package functions should can be virtual.=) Thanks for help and interesting discussion. PS: Sorry for my bad English.
Nov 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 10, 2012 08:28:00 goofwin wrote:
 I think that it is unsuccessful decision by the language
 designers, because object oriented code use virtual functions not
 much in most cases, thence it is useless and bad for performance
 or it causes developer to set public and protected functions as
 final explicitly very much.

Object-oriented code not use virtual functions much? If you don't need virtual functions, then use a struct, not a class. Classes are polymorphic. Structs are not. In general, it doesn't make a lot of sense to use a class in D if you don't need polymorphism. And if you do need to but don't want the functions to be virtual (e.g. you want to use a class, because you want a reference type without going to the trouble of making a struct a reference type), then you can just make all of the class' public functions final. But that's not the normal case at all. - Jonathan M Davis
Nov 10 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 10, 2012 11:03:31 Jacob Carlborg wrote:
 On 2012-11-10 06:28, Jonathan M Davis wrote:
 package restricts access to the same package. D has no concept like C#'s
 internal, because it doesn't have assemblies.

I'm not entirely sure how assemblies work in C# but couldn't one say that everything in D is internal unless explicitly marked as export?

I guess, but that's purely a Windows dll thing. Linux isn't stupid enough to be affected by export at all (export is one of my biggest pet peeves with Windows - I absolutely hate it; it's just caused me way too much trouble). - Jonathan M Davis
Nov 10 2012
prev sibling parent "goofwin" <artem.3a gmail.com> writes:
On Saturday, 10 November 2012 at 18:35:57 UTC, Jonathan M Davis 
wrote:
 Object-oriented code not use virtual functions much? If you 
 don't need virtual
 functions, then use a struct, not a class. Classes are 
 polymorphic. Structs
 are not. In general, it doesn't make a lot of sense to use a 
 class in D if you
 don't need polymorphism. And if you do need to but don't want 
 the functions to
 be virtual (e.g. you want to use a class, because you want a 
 reference type
 without going to the trouble of making a struct a reference 
 type), then you
 can just make all of the class' public functions final. But 
 that's not the
 normal case at all.

 - Jonathan M Davis

You didn't understand me. I mean that only less 30% of public functions in typical class must be virtual in most cases. And fact, that i need use 'final' for 70% public functions, is not comfortable. It is my humble opinion. Sorry for my bad English.
Nov 10 2012