View mode: basic / threaded / horizontal-split · Log in · Help
November 09, 2012
attribute bug?
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
November 09, 2012
Re: attribute bug?
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.
November 09, 2012
Re: attribute bug?
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
November 09, 2012
Re: attribute bug?
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
November 10, 2012
Re: attribute bug?
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.
November 10, 2012
Re: attribute bug?
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.
November 10, 2012
Re: attribute bug?
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
November 10, 2012
Re: attribute bug?
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.
November 10, 2012
Re: attribute bug?
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
November 10, 2012
Re: attribute bug?
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home