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
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
next sibling parent reply =?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
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 reply "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 

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
parent reply 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, 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
next sibling parent reply "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
parent reply 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
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
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 06:28, Jonathan M Davis wrote:



 internal, because it doesn't have assemblies.



that everything in D is internal unless explicitly marked as export?

-- 
/Jacob Carlborg
Nov 10 2012
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:


 internal, because it doesn't have assemblies.


 

 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 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