.Mixin() within .Mixin results in error

[tyler-dot-earth]

Less code like this:

.container() {
    // css properties
}

.container {
    .container();
}

... Results in an error when compiled. It seems to be because they share the same name, although they are different (one is a mixin with empty arguments and one is just a class).

I'm using the ruby less gem to compile on Ubuntu.

[ChrisCinelli]

Easy fix: use a different name ;-)

[tyler-dot-earth]

Well, I'm trying to create the option of letting the user have an unsemantic ruleset if they'd like it and the unsemantic ruleset would have the same code in .container as the .container() mixin -- so changing the name isn't particularly an option (or "fix").

[cloudhead]

As the compiler sees it, they are the same. Classes in LESS are mixins, and mixins with no parameters are classes.

[lancehunt]

I just ran into this same issue when parsing the .clearfix() mixin in bootstrap using lessc and nodejs(v0.58)

I commented on their change that caused this, here:
twbs/bootstrap@39aca91

It would be nice if less.js at least gave a more descriptive error rather than just "undefined" when this happens. Or better yet, why not just create a hashmap to alias class names and mixins differently.

[n0nick]

+1 on this one.
If this is a syntax error, less.js should display it, and not just crash.

This is especially critical because this exact problem caused WEBrick to crash as well (trying to serve the less file through Rails' assets pipelines)

[krulik]

I get an error with the following code:

@direction: ltr;

.left(@v) when (@direction = ltr) { left: @v; }
.left(@v) when (@direction = rtl) { right: @v; }
.right(@v) when (@direction = ltr) { right: @v; }
.right(@v) when (@direction = rtl) { left: @v; }

.carousel-control {
  /* ..css.. */

  &.right {
    .left(auto);
    .right(15px);
  }

}

I don't want to change the mixin name because its a convention and maps one-to-one with the corresponding CSS property. I also can't change the class name because its a 3rd party framework (bootstrap), that I'm porting to RTL support.

So I'm +1-ing it :)

[OlsonDev]

I just ran into this. I don't agree with the syntax in the documentation:

.wrap () {
  text-wrap: wrap;
  white-space: pre-wrap;
  white-space: -moz-pre-wrap;
  word-wrap: break-word;
}

pre { .wrap }

I think parametric mixins taking no arguments should be invoked as if they were a function. .wrap and .wrap() should not be equivalent. Use two hashmaps if you need to. I realize this is a breaking change but the current behavior is counter-intuitive. Sure, there are plenty of languages out there where properties and methods can't share the same name or getters/setters can't have different accessibility levels. But, this just feels wrong. I didn't even realize I could do .wrap when only .wrap() is defined until I ran into a stack overflow error and resorted to your documentation. I've always used .wrap() to mixin something I wanted to hide from the CSS output.

[lukeapage]

I'm planning on just fixing this so it won't recurse/pull in a mixin on the
current path. Then everyones happy?

[OlsonDev]

I don't agree with it but I'll take it over nothing.

[matthew-dean]

Can you explain / give an example of the different output you expect?

On 2012-10-24, at 7:56 AM, Josh Olson notifications@github.com wrote:

I just ran into this. I don't agree with the syntax in the documentation:

.wrap () {
text-wrap: wrap;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
word-wrap: break-word;
}

pre { .wrap }

I think parametric mixins taking no arguments should be invoked as if they
were a function. .wrap and .wrap() should not be equivalent. Use two
hashmaps if you need to. I realize this is a breaking change but the
current behavior is counter-intuitive. Sure, there are plenty of languages
out there where properties and methods can't share the same name or
getters/setters can't have different accessibility levels. But, this just
feels wrong. I didn't even realize I could do .wrap when only .wrap() is
defined until I ran into a stack overflow error and resorted to your
documentation. I've always used .wrap() to mixin something I wanted to hide
from the CSS output.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/413#issuecomment-9742516.

[OlsonDev]

@MatthewDL, I would expect an error in the example provided in the documentation. .wrap as a class (to be output & usable as a mixin) was never defined; .wrap() was. Proper usage would therefore be:

.wrap() {
  text-wrap: wrap;
  white-space: pre-wrap;
  white-space: -moz-pre-wrap;
  word-wrap: break-word;
}

pre { .wrap(); }

[matthew-dean]

Ohhhh.... Yes, I get what you mean.

.wrap should theoretically bring up a class definition. .wrap() should bring in a mixin definition.

I think you make a good point, and I don't disagree, but it's unfortunately a breaking change. And changing the behavior I don't feel is advantageous enough to force that change. For now, I'd say just don't have mixin definitions clash with class definitions. It's documented well enough that currently, the parentheses are not required.

Also, I wonder if this is a case for LESS to have "warnings" generated and not just errors.

[matthew-dean]

Having said that... I did just see @krulik's example. Hmm... @agatronic, your thoughts?