Errors - Re: Signals and Slots

[Tom S]

Chris Miller wrote:
> Using the example straight from 
> http://www.digitalmars.com/d/phobos/std_signals.html (and yes using DMD 
> 0.173) I get the following compiler errors:
> 
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): undefined identifier 
> _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): function expected before 
> (), not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(174): undefined identifier 
> _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(174): function expected before 
> (), not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(235): undefined identifier free
> c:\dmd\bin\..\src\phobos\std\signals.d(235): function expected before 
> (), not fr
> ee of type int
> 
> 
> I think this is finally a real mixin limitation being exposed. You 
> probably only tested std.signals inside the signals.d source file, where 
> the mixin had access to std.signals' imports. But use std.signals from 
> another file and the mixin cannot access std.signal's imports because 
> it's accessing the mixed-in scope. In other words, I think to remove 
> these errors, std.signals' imports would need to be imported inside the 
> mixin template (hack?), or change how mixins work.

++mixinVictims;

Thanks for bringing up that problem, Chris. I've begged for a change in 
mixins' visibility rules some time ago. Maybe we could restart the 
discussion now ?

Mixins are unlike any other construct in D, thus they are a trap for 
programmers expecting uniform behavior in the whole language.
The biggest problem with mixins is what has just been demonstrated by 
Chris - they exist in instantiation scope and that's where they look for 
symbols. But when we write a module with some template meant to be used 
as a mixin, the module will probably contain other stuff and we'll want 
our mixin to use it. So we use that symbol in the mixin and it works in 
the module... But then we import the module somewhere else, try to use 
the mixin and BANG! Lots of 'undefined identifier' errors.

To be consistent, mixins should by default see their declaration scope 
and only access the instantiation scope thru a special keyword or 
construct. If it were up to me, I'd use 'outer'. E.g.

template Foo() {
	alias foo a;	// uses 'foo' from the declaration scope
	alias outer.foo b;	// uses 'foo' from the instantiation scope
}

That's all is needed to avoid unpleasant surprises with mixin visibility 
rules.

On a last note, this is not the only problem with mixins. I hope that we 
can finally get around to fixing them all...

--
Tomasz Stachowiak