Namespace, scope and lazy loading

[SomMeri]

How is the namespace reference supposed to behave when the namespace is used before being declared? (Using mixins and variables before declaring them is legal.)

It seems like if I use mixin from namespace before declaring it, the mixin uses the caller mixins and variables scope. E.g. this:

 #abc1 { #space1 > .test1(); }
 #space1 {
  .mixin1() { color: red; }
  .test1() { .mixin1(); }
  .mixin1() { margin: 2 2 2 2; }
 }
 .mixin1() { content: "conflict"; }

compiles into:

#abc1 {
  content: "conflict";
}

The mixin test1 does not see other mixins declared in the same namespace. Is it a bug or was not supposed to use it this way?

If I put the first reference #abc1 { #space1 > .test1(); } after the #space declaration, then the mixin test1 starts to compile correctly.

[SomMeri]

I made another test and found that it does the same with mixins-closures:

.abc1 { .space1 > .test1(); }
.space1 {
 .mixin1() { color: red; }
 .test1() { .mixin1(); }
 .mixin1() { margin: 2 2 2 2; }
}
.mixin1() { content: "conflict"; }

ends up as:

.abc1 {
  content: "conflict";
}

[lukeapage]

I can see why less does this.. when you write #namespace > .mixin() it takes mixin from the namespace and "runs" it in the current context.

Ideally it should run it using first the namespace context and then if that fails, the current context. So I think it should be changed.. but it is a difficult one to gauge.

See #297

[SomMeri]

I understand that scoping is difficult and I'm not demanding it to be fixed within 5 minutes :). Consistent handling of the scope is important: the more consistent it is, the easier it is to read less files. And if I do not fill an issue for a problem I know about, I'm sort of contributing to it.

If mixin uses the scope of the namespace first, then the namespace can be used to encapsulate cooperating mixins. Then I can call mixin from the namespace and know what it will do. I do not have to worry about mixins in caller scope accidentally overriding namespace behavior. The namespace acts as a library.

Plus, my opinion is that the scoping of namespaces should be the same as the scoping of mixins. Mixins without namespaces use their own scope before caller scope, so namespaces should too.

The other issue #297 is interesting. If variables stay constants, then everything follows the same simple rule: define anywhere. Variables as real variables would complicate things, but maybe not by that much. The mixin or namespace could use variable value as it is at the declaration place.

Regardless which way you will go, the important for me is to know what is the supposed behavior, what is a bug and whether there are plans to change it. I do not want to rely on something that will change.

[lukeapage]

same with variables in #921

[fengdi]

.create-namespace(@n){
    (~"#namespace-@{n}"){
        font-family: "asdasd";
        .bar(){
            display: block;
        }
    }
}
.create-namespace("foo");
#namespace-foo>.bar(); //#namespace-foo > .bar is undefined