Proposal keyword 'outer' (mixins)

[Rioshin an'Harthen]

"Tom S" <h3r3tic at remove.mat.uni.torun.pl> wrote in message 
news:e7o633$1ms9$1 at digitaldaemon.com...
> Don Clugston wrote:
>> It's really important that mixins be able to access outer variables 
>> without knowing how deep they are.  I think this is quite different from 
>> the situation for inner classes.
>>
>> ie, in a mixin, if you had to write
>>
>> outer.outer.outer.x
>>
>> mixins would lose most of their power.
>
> Wouldn't this be a problem only in case of instantiating mixins 
> recursively inside other mixins ? I'd then use an alias in the recursive 
> mixin template that brings the required symbol to the mixin's scope, like 
> 'private alias outer.foo foo'. Then the nested mixin would only have to 
> use 'outer.foo' to get the indefinitely deep symbol.

What about instantiating a mixin from an inner class? Wouldn't the first 
outer then access only those items in the inner class, and a second one be 
needed to get to the next class upwards?

Now, you would need to alias those symbols in the inner class for the mixin.

> That combined with my previous proposal: 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39135
>
> would make it at least workable...
>
>
>> I'd be in favour of syntax which said:
>> (a) this template is intended for use as a mixin; and
>
> Agreed. 'mixin template foo() {}' or just 'mixin foo() {}' would be much 
> more explicit...

Of these, I prefer the syntax of mixin template foo() {}. That states more 
clearly what is intended - that the template following is intended to be 
used as a mixin.

Should it also be illegal to use a mixin template as anything other than a 
mixin? Tentatively, I'd say yes.

>> (b) I'm importing the next symbol from _somewhere_ outside the mixin.
>
> This would also be an option for the 'outer' keyword. 'outer.foo' could 
> just mean that. Take 'foo' from _somewhere_ outside the mixin.

I would actually go for this for both mixins and inner classes. I think it 
would be preferable to be consistent with the use of the keyword; i.e. if we 
make

mixin template Gnusto()
{
      outer.b = outer.a;
}

to mean any variable in the scope, following a chain of scopes through outer 
classes, from where Foo is instantiated, then so should

class Foo
{
    public int a;

    class Bar
    {
        public int b;

        class Baz
        {
            void blorb()
            {
                outer.b = outer.a;
            }

            void gnusto()
            {
                mixin Gnusto!();
            }
        }
    }
}

work, as well. Basically, the code brought in by the mixin in gnusto, 
matches exactly the same code in blorb. Both evaluate to outer.b = outer.a, 
and if one method is allowed, while the other would require outer.b = 
outer.outer.a, then I for one would see it as broken.