On Wednesday, 10 April 2013 at 09:33:03 UTC, Paulo Pinto wrote:
> Actually there is a game studio in Germany, Wooga that uses Erlang for their game servers, they are quite happy to have left C++ land.
>
> http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang
>
> --
> Paulo

No doubts, I was speaking about client-side. Server-side game-dev is more about servers than about game-dev ;) And Erlang is pretty good there.

On 10 April 2013 19:19, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 09:12:33 UTC, Manu wrote:
>
>> ... nar, I don't think so.
>> A class is a class, I'm not arguing for anything that's
>> kinda-like-a-class,
>> I'm talking about classes.
>>
>
> The question is then "what is class?". Because the very reason to have class is to have guaranteed polymorphic behavior, so that working with object via its base will always make sense without any fears about what behavior can be overriden. But that is mostly needed in OOP hell with few practical cases like plugins.
>

I think I've lost you here... this doesn't make sense. Where did I say
virtual was bad, and it shouldn't exist? And how does my suggesting affect
any guarantee of polymorphic behaviour?
How is working with an object via it's base where only a small subset of
the functions are designed to be overridden any less convenient? It makes
no difference.
What's more convenient is it's much more obvious what the user is meant to
override, and what it should do (presuming the rest of the API is designed
in a sensible way). The self documenting nature of the virtual keyword is
nice.
It's also _MUCH FASTER_!


If essentially coupling data and methods is needed, that is what struct
> does. I am not arguing that everything should be virtual, I am arguing that you actually need classes. It is not C++ and, in my opinion, structs should be much more common entities than classes, especially in performance-hungry code.
>

Struct's are inconvenienced by other stuff. You can't create a ref local, thus you can't use a struct as a class conveniently. It also has no virtual table, how do you extend it conveniently? I'm not talking about struct's, I'm talking about classes.

On Wednesday, 10 April 2013 at 09:33:13 UTC, Manu wrote:
> How much garbage were you collecting? How long were the collect times? Did
> you see the same relationship between the volume of garbage in JVM, C# and
> D?
> What was the performance relationship with respect to garbage volume? was
> it linear?

In D? Almost none. It was manual memory management with GC enabled side-by-side. If you want to compare D GC with JVM GC, don't pretend you are comparing D with Java. Problem with D GC is that collection cycles can still hit sometimes even if there are almost zero garbage and it does not matter that nothing is actually collected - the very existence of context switch and collection cycle creates latency spike.

On Wed, 10 Apr 2013 09:56:01 +0100, Manu <turkeyman@gmail.com> wrote:

> On 10 April 2013 17:01, Paulo Pinto <pjmlp@progtools.org> wrote:
>
>> On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
>>
>>> [...]
>>>
>>>
>>> I do use virtual functions, that's the point of classes. But most
>>> functions
>>> are not virtual. More-so, most functions are trivial accessors, which
>>> really shouldn't be virtual.
>>> OOP by design recommends liberal use of accessors, ie, properties, that
>>> usually just set or return a variable. Wen would you ever want @property
>>> size_t size() { return size; } to be a virtual call?
>>>
>>
>> Yes, if you want to change its behavior in a derived class.
>>
>
> That really shouldn't be encouraged. Give me an example?

I wrote some crypto code which had a property for the hash size, each derived class returned it's own size.  Now, in this case the property size() was called rarely, but it's still a valid example.

That said, I agree we don't generally want properties and other short-and-should-be-inlined methods to be virtual by default.  But.. is D really doing that?  I mean /actually/ really doing it.

I have read most of this thread in passing and I've seen the earlier discussion about classes in libraries etc and TBH I am not sure how/what D does in those situations.  Presumably if D does not have the source for the library then the library class would have to have all methods virtual - just in case it was derived from and I guess this is an issue that needs solving somehow.  But, I don't know if this is the case, or if this is even an actual problem.

That's not the most common case however, the common case is a class you're compiling with the rest of your classes and in this case D is not going to make your base class methods (which have not explicitly been overridden) virtual, they should be non-virtual and optimised/inlined/etc.  They just start out "virtually" virtual until the compiler is finished compiling them and all derived classes, at that point all non-override base methods should be non-virtual.

It would be interesting to see what the compiler actually does if, for example, you compile a file with a class then in a separate compile/link step compile a derived class and link.  Does D manage to non-virtual all non-overridden methods?  If so, can it do the same with a lib/dll combo?

> That's not an exampe. I want to see a class where every function SHOULD be
> overloaded... That sounds like a nightmare, how can anyone other than the
> author ever expect to understand it? The fewer and more deliberately
> controlled the virtuals, the better, by almost every measure I can imagine.

This isn't the reasoning behind making virtual the virtual default for methods.  The reason for doing it was simply so the compiler could be responsible for figuring it out without you having to label it manually.  You're already labelling the derived class method "override" and that should be enough.  This was a choice of convenience and ultimately performance because you won't accidentally make a method virtual that doesn't need to be.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 10 April 2013 19:44, Regan Heath <regan@netmail.co.nz> wrote:

> On Wed, 10 Apr 2013 09:56:01 +0100, Manu <turkeyman@gmail.com> wrote:
>
>  On 10 April 2013 17:01, Paulo Pinto <pjmlp@progtools.org> wrote:
>>
>>  On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
>>>
>>>  [...]
>>>>
>>>>
>>>> I do use virtual functions, that's the point of classes. But most
>>>> functions
>>>> are not virtual. More-so, most functions are trivial accessors, which
>>>> really shouldn't be virtual.
>>>> OOP by design recommends liberal use of accessors, ie, properties, that
>>>> usually just set or return a variable. Wen would you ever want @property
>>>> size_t size() { return size; } to be a virtual call?
>>>>
>>>>
>>> Yes, if you want to change its behavior in a derived class.
>>>
>>>
>> That really shouldn't be encouraged. Give me an example?
>>
>
> I wrote some crypto code which had a property for the hash size, each derived class returned it's own size.  Now, in this case the property size() was called rarely, but it's still a valid example.
>

But this is a trivial class, with 2 methods, size() and computeHash(). It's also a primitive tool that should probably live in a standard library. It's not the sort of code people are writing on a daily basis.

That said, I agree we don't generally want properties and other
> short-and-should-be-inlined methods to be virtual by default.  But.. is D really doing that?  I mean /actually/ really doing it.
>

Yes. People don't write final on everything. It's not a habit, and it's not even recommended anywhere.

I have read most of this thread in passing and I've seen the earlier
> discussion about classes in libraries etc and TBH I am not sure how/what D does in those situations.  Presumably if D does not have the source for the library then the library class would have to have all methods virtual - just in case it was derived from and I guess this is an issue that needs solving somehow.  But, I don't know if this is the case, or if this is even an actual problem.
>

It's a problem. And I don't believe it's 'solvable'.
The only solution I can imagine is to not force the compiler into that
completely unknowable situation in the first place, by making virtual
explicit to begin with.

That's not the most common case however, the common case is a class you're
> compiling with the rest of your classes and in this case D is not going to make your base class methods (which have not explicitly been overridden) virtual, they should be non-virtual and optimised/inlined/etc.  They just start out "virtually" virtual until the compiler is finished compiling them and all derived classes, at that point all non-override base methods should be non-virtual.
>

I don't see how this is possible, unless the instance was created in the
same local scope, and that's extremely unlikely.
Even if it has the source for my class, it can't ever know that the pointer
I hold is not a base to a more derived class. It could be returned from a
DLL or anything.
Everyone keeps talking like this is possible. Is it? I can't imagine any
way that it is.

It would be interesting to see what the compiler actually does if, for
> example, you compile a file with a class then in a separate compile/link step compile a derived class and link.  Does D manage to non-virtual all non-overridden methods?  If so, can it do the same with a lib/dll combo?


The compiler makes a virtual call. If a static lib, or a DLL is involved, I don't see how the optimisation could ever be valid?

 That's not an exampe. I want to see a class where every function SHOULD be
>> overloaded... That sounds like a nightmare, how can anyone other than the author ever expect to understand it? The fewer and more deliberately controlled the virtuals, the better, by almost every measure I can imagine.
>>
>
> This isn't the reasoning behind making virtual the virtual default for methods.  The reason for doing it was simply so the compiler could be responsible for figuring it out without you having to label it manually.


Yes but the compiler can't figure it out. It's not logically possible, it must always assume that it could potentially be derived somewhere... because it could.

 You're already labelling the derived class method "override" and that
> should be enough.  This was a choice of convenience and ultimately performance because you won't accidentally make a method virtual that doesn't need to be.


Sorry, I don't follow. How does this help?

Ok, lets Rewind for a sec.  I need some educating on the actual issue and I want to go through the problem one case at a time..


#1 If I write a class..

class A
{
  public int isVirt()  { return 1; }
  public int notVirt() { return 2; }
}

and compile it with another class..

class B : A
{
  override public int isVirt() { return 5; }
}

and this main..

void main()
{
  A a = new B();
  a.isVirt();    // compiler makes a virtual call
  a.notVirt();   // but not here
}

Right?


#2 But, if I do /not/ compile class B and have..

void main()
{
  A a = new A();
  a.isVirt();     // not a virtual call
  a.notVirt();    // neither is this
}

Right?


#3 If I put class A into a library (lib/dll) then compile/link it with..

class B : A
{
  override public int isVirt() { return 5; }
}

and..

void main()
{
  A a = new B();
  a.isVirt();    // compiler makes a virtual call
  a.notVirt();   // we're saying it has to make a virtual call here too
}

So, when the compiler produced the library it compiled all methods of A as virtual because it could not know if they were to be overridden in consumers of the library.

So, if the library created an A and passed it to you, all method calls would have to be virtual.

And, in your own code, if you derive B from A, then calls to A base class methods will be virtual.

Right?

R

On Wednesday, 10 April 2013 at 09:35:12 UTC, Manu wrote:
> I think I've lost you here... this doesn't make sense.

Same here, I am afraid it is just too hard to me to imagine type of architecture used in your project, so I'd better resort from doing stupid advice :) Beg my pardon.

On 10 April 2013 20:29, Regan Heath <regan@netmail.co.nz> wrote:

> Ok, lets Rewind for a sec.  I need some educating on the actual issue and I want to go through the problem one case at a time..
>
>
> #1 If I write a class..
>
> class A
> {
>   public int isVirt()  { return 1; }
>   public int notVirt() { return 2; }
> }
>
> and compile it with another class..
>
> class B : A
> {
>   override public int isVirt() { return 5; }
> }
>
> and this main..
>
> void main()
> {
>   A a = new B();
>   a.isVirt();    // compiler makes a virtual call
>   a.notVirt();   // but not here
> }
>
> Right?
>
>
> #2 But, if I do /not/ compile class B and have..
>
> void main()
> {
>   A a = new A();
>   a.isVirt();     // not a virtual call
>   a.notVirt();    // neither is this
> }
>
> Right?
>
>
> #3 If I put class A into a library (lib/dll) then compile/link it with..
>
> class B : A
> {
>   override public int isVirt() { return 5; }
> }
>
> and..
>
> void main()
> {
>   A a = new B();
>   a.isVirt();    // compiler makes a virtual call
>   a.notVirt();   // we're saying it has to make a virtual call here too
> }
>
> So, when the compiler produced the library it compiled all methods of A as virtual because it could not know if they were to be overridden in consumers of the library.
>
> So, if the library created an A and passed it to you, all method calls would have to be virtual.
>
> And, in your own code, if you derive B from A, then calls to A base class methods will be virtual.
>
> Right?
>
> R
>

All your examples all hinge on the one case where the optimisation may possibly be valid, a is _allocated in the same scope_. Consider:

void func(A* a)
{
 a.isVirt(); // is it? I guess...
 a.notVirt(); // what about this?
}

We don't even know what a B is, or whether it even exists.
All we know is that A's methods are virtual by default, and they could be
overridden somewhere else. It's not possible to assume otherwise.

Sorry, void func(A* a) should be void func(A a). C++ took me for a moment ;)


On 10 April 2013 20:39, Manu <turkeyman@gmail.com> wrote:

> On 10 April 2013 20:29, Regan Heath <regan@netmail.co.nz> wrote:
>
>> Ok, lets Rewind for a sec.  I need some educating on the actual issue and I want to go through the problem one case at a time..
>>
>>
>> #1 If I write a class..
>>
>> class A
>> {
>>   public int isVirt()  { return 1; }
>>   public int notVirt() { return 2; }
>> }
>>
>> and compile it with another class..
>>
>> class B : A
>> {
>>   override public int isVirt() { return 5; }
>> }
>>
>> and this main..
>>
>> void main()
>> {
>>   A a = new B();
>>   a.isVirt();    // compiler makes a virtual call
>>   a.notVirt();   // but not here
>> }
>>
>> Right?
>>
>>
>> #2 But, if I do /not/ compile class B and have..
>>
>> void main()
>> {
>>   A a = new A();
>>   a.isVirt();     // not a virtual call
>>   a.notVirt();    // neither is this
>> }
>>
>> Right?
>>
>>
>> #3 If I put class A into a library (lib/dll) then compile/link it with..
>>
>> class B : A
>> {
>>   override public int isVirt() { return 5; }
>> }
>>
>> and..
>>
>> void main()
>> {
>>   A a = new B();
>>   a.isVirt();    // compiler makes a virtual call
>>   a.notVirt();   // we're saying it has to make a virtual call here too
>> }
>>
>> So, when the compiler produced the library it compiled all methods of A as virtual because it could not know if they were to be overridden in consumers of the library.
>>
>> So, if the library created an A and passed it to you, all method calls would have to be virtual.
>>
>> And, in your own code, if you derive B from A, then calls to A base class methods will be virtual.
>>
>> Right?
>>
>> R
>>
>
> All your examples all hinge on the one case where the optimisation may possibly be valid, a is _allocated in the same scope_. Consider:
>
> void func(A* a)
> {
>  a.isVirt(); // is it? I guess...
>  a.notVirt(); // what about this?
> }
>
> We don't even know what a B is, or whether it even exists.
> All we know is that A's methods are virtual by default, and they could be
> overridden somewhere else. It's not possible to assume otherwise.
>

My understanding as based on dlang.org:

On Wednesday, 10 April 2013 at 10:29:05 UTC, Regan Heath wrote:
> Ok, lets Rewind for a sec.  I need some educating on the actual issue and I want to go through the problem one case at a time..
>
>
> #1 If I write a class..
>
> class A
> {
>   public int isVirt()  { return 1; }
>   public int notVirt() { return 2; }
> }
>
> and compile it with another class..
>
> class B : A
> {
>   override public int isVirt() { return 5; }
> }
>
> and this main..
>
> void main()
> {
>   A a = new B();
>   a.isVirt();    // compiler makes a virtual call
>   a.notVirt();   // but not here
> }
>
> Right?

No. A is not final. A has no internal linkage. It can be inherited from in other compilation unit. notVirt is virtual.

Other answers are matching ;)