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

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.

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

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

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.

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.

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

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.

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

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