virtual-by-default rant

[Dmitry Olshansky]

On 19.03.2012 14:45, Artur Skawina wrote:
> On 03/19/12 08:30, Dmitry Olshansky wrote:
>> On 19.03.2012 2:17, Artur Skawina wrote:
>>> On 03/18/12 15:37, Dmitry Olshansky wrote:
>>>> On 18.03.2012 5:23, Manu wrote:
>>>>> The virtual model broken. I've complained about it lots, and people
>>>>> always say "stfu, use 'final:' at the top of your class".
>>>>>
>>>>> That sounds tolerable in theory, except there's no 'virtual' keyword to
>>>>> keep the virtual-ness of those 1-2 virtual functions I have... so it's
>>>>> no good (unless I rearrange my class, breaking the logical grouping of
>>>>> stuff in it).
>>>>> So I try that, and when I do, it complains: "Error: variable
>>>>> demu.memmap.MemMap.machine final cannot be applied to variable",
>>>>> allegedly a D1 remnant.
>>>>> So what do I do? Another workaround? Tag everything as final individually?
>>>>>
>>>>> My minimum recommendation: D needs an explicit 'virtual' keyword, and to
>>>>> fix that D1 bug, so putting final: at the top of your class works, and
>>>>> everything from there works as it should.
>>>>
>>>> Following this thread and observing that you don't trust optimizer and compiler in many cases or have to double check them anyway, I have a suggestion: do virtual dispatch by hand via func-pointer table and use structs.
>>>>
>>>> I'm serious, with a bit of metaprogramming it wouldn't be half bad, and as a bonus you don't have to pay for a monitor field per object as classes do, and in general less compiler magic to keep track of. You also gain the ability to fine tune their layout, the performance maniac side of yours must see the potential it brings :)
>>>
>>> I was going to suggest the very same thing - but there are (at least) two problems
>>> with that approach:
>>>
>>> 1) pass-by-value -- it's dangerous, ugly to work-around (and compiler bugs don't
>>>      help, like the one where just having a "this(this)" causes problems); the
>>>      workarounds also have compiler/ABI issues (like the 'File' case posted in D.learn
>>>      some time ago, or GDC not passing/returning the pseudo-refs in registers)
>>
>> GDC not passing pseudo-refs in registers is cleanly a non-issue, in a sense, that it's not a good excuse at all, as well the other bugs.
>
> Something that should work in theory, but does not behave as expected,
> *is* an issue, if it means you can't actually use that solution right now.
> [Note the GDC problem may or may not still be there; i tried it a while ago;
>   the other issues cause enough trouble anyway]
>
>> All in all, nobody is going to kill you if in performance sensitive code you'd use pointers:
>>
>> BigStruct* my_big = allocateSomewhere(...ctor_args...); //ultimately using emplace
>
> struct A{}
> struct B{A sup; alias sup this;}
> void f1(A* a) {/*...*/}
> // Fail:
> void f2(B* b) {f1(b);/*...*/}
> A* b = new B;
>
> // And, yes, "void f1(ref A a);" etc would work, but then it's just a question
> // of time before you'll end up searching the whole project for erroneous struct
> // copies, instead of virtuals. And the virtual methods are easier to find...
>

Sure sounds like fun challenge, that's my start before being killed by 
compiler internal error (damn, it's an *issue* after all)

Assertion failure: 't' on line 7911 in file 'mtype.c'

Anyway here is the code:

struct A{
   int a;
}

template Inherit(alias X)
{
   X __super;
   alias __super this;
}


struct B{
   mixin Inherit!A;
   int b;
}

struct PolyPtr(X)//no opaque pointers or loose polymorphism
{
	X* _payload;
	static if(is(typeof(X.init.__super)))
	{
		alias typeof(X.init.__super) Super;
//chain up the rest of possible super classes
		@property auto getSuper(){ return PolyPtr!Super(&_payload.__super); }
		alias getSuper this;
	}
//	alias _payload this;//multiple alias this, sigh
	auto opDispatch(string s)(){ return mixin("_payload."~s); }
}

template create(X)
{
	PolyPtr!X create(X, T...)(T args){
		return PolyPtr!X(args);
	}	
}

void f1(PolyPtr!A a) {/*...*/}
void f2(PolyPtr!B b) {f1(b);/*...*/}


void main(){
	auto b = create!B(42, 31);
}




>>> 2) no inheritance. ie 'struct A{}; struct B{A super; alias super this;}' cannot be
>>>      written as just 'struct B:A {}' - which would not be just syntax sugar, but also
>>>      allow (more) implicit conversions, (explicit) function overrides etc.
>>>
>>
>> Template mixins? I envision:
>> struct Foo{
>>      mixin Inherit!(Bar);
>> }
>>
>> I see that it is not a cake-walk but acceptable for the special nature of requirements.
>
> This thread was about larger non-trivial projects, and the difficulty in finding
> all methods that do not need to be virtual -- i don't know if replacing the whole
> class hierarchy with a template-mixin-wrapped-in-structs hierarchy would really be
> such a good idea. ;)
> Also, see the above example - doing struct inheritance by hand, w/o compiler help,
> quickly gets ugly and dangerous.
>
>>> So - yes, D structs should be enough for everything, but right now they're still
>>> missing some required basic features. Ideally "class" would just be sugar, and
>>> everything should be expressible using just structs - obviously in a much more
>>> verbose, but 100% compatible way (incl vtables, monitors etc)
>>
>> Yes, that the point. And if one doesn't like this kind of compiler sugar, he is free to synthesize Xylitol.
>
> I'm saying "use structs instead of classes" is a good suggestion, but *right now*
> the language and compiler do not provide enough support to make this practical.
> There's a lot of room for (backwards compatible) improvements, though.
>
> artur


-- 
Dmitry Olshansky