www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mixin mystic

reply Georg Wrede <georg.wrede iki.fi> writes:
On December 14, Nick Sabalausky wrote:
 That explains a certain mystery I encountered in a library I wrote.
 Everything *seemed* like it should have worked with "scope" instead
 of "auto" but it never did. The variables that were mysteriously
 unconvertable to "scope" were declared in a mixin.

 This makes me wonder though: should mixins be implicitly creating a
 new scope at all? Clearly there are cases where it's desireable to not
 have that implicit scope, and with the current behavior I don't see a
 workaround. Are there cases where an implicit new scope would be
 desired? If so, could those cases be sufficiently worked around by
 explicitly creating a new scope in the mixin?

For some reason, nobody seemed to have read this question. One would think that the mixin not creating a new scope would be what the programmer expects. Or at least hopes... On a related note, seems an object of a scope variable in a mixin doesn't get destructed. Is this a result of some hack, or intended behavior? Below, instance "scope_mixi_a" never gets destructed. ====================================================== import std.stdio; class Ob { string myname; this(string s) { myname = s; // writeln("Ob ", myname, " created."); } ~this() {writeln("Ob ", myname, " destructed.");} } template mixi() { scope mixi_a = new Ob("scope_mixi_a"); auto mixi_b = new Ob("auto_mixi_b"); } void main() { scope x = new Ob("scope_x"); auto y = new Ob("auto_y"); { scope a = new Ob("scope_a"); auto b = new Ob("auto_b"); mixin mixi; scope c = new Ob("scope_c"); auto d = new Ob("auto_d"); writeln(" -- last line of inner scope"); } scope z = new Ob("scope_z"); auto u = new Ob("auto_u"); writeln(" -- last line of outer scope"); } ====================================================== Output: -- last line of inner scope Ob scope_c destructed. Ob scope_a destructed. -- last line of outer scope Ob scope_z destructed. Ob scope_x destructed. Ob auto_u destructed. Ob auto_d destructed. Ob auto_mixi_b destructed. Ob auto_b destructed. Ob auto_y destructed.
Apr 04 2009
parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:gr8a9l$grv$3 digitalmars.com...
 On December 14, Nick Sabalausky wrote:
 That explains a certain mystery I encountered in a library I wrote.
 Everything *seemed* like it should have worked with "scope" instead
 of "auto" but it never did. The variables that were mysteriously
 unconvertable to "scope" were declared in a mixin.

 This makes me wonder though: should mixins be implicitly creating a
 new scope at all? Clearly there are cases where it's desireable to not
 have that implicit scope, and with the current behavior I don't see a
 workaround. Are there cases where an implicit new scope would be
 desired? If so, could those cases be sufficiently worked around by
 explicitly creating a new scope in the mixin?

For some reason, nobody seemed to have read this question. One would think that the mixin not creating a new scope would be what the programmer expects. Or at least hopes...

The other strange thing about it is that what a string mixin creates is not so much an implicit scope as it is an implicit "semi-scope". Ie, if you declare a non-scope variable in a string mixin, it'll outlive the mixin (which is good, string mixings would be far less useful otherwise), but with a normal manual scope that would not be the case.
Apr 04 2009