Enable &:extend() to take a class as a variable

[paulhhowells]

Feature Request

It would be very powerful if :extend could be passed a class name as a variable.

e.g. something like:

&:extend(@{extending-class-string});

or:

&:extend(@extending-class);

Use Cases:

(tl;dr this would be brilliant for making mixins reusable and for grid systems)

If you want to extend a class with numbered additions it is possible, as long as you create a mixin for every class you want to extend.

for example:

.dec-loop (@length) {
  @i: @length;

  .extended-class {
    float: left;
  }

  .loop (@i) when (@i > 0) {   
    @loop-class: ~".dec-@{i}";   
    @{loop-class} {
      &:extend(.extended-class);
    }    
    .loop(@i - 1);
  }
  .loop(@i);  
}
.dec-loop(4);

will create:

.extended-class,
.extended-class-4,
.extended-class-3,
.extended-class-2,
.extended-class-1 {
  float: left;
}

However the name of the class being extended is hard coded into the mixin, requiring a new mixin for every class you want to extend in this way. But imagine if this worked:

.inc-loop (@extending-class-name; @total) {
  @i: 1;
  @extending-class-string: ~".@{extending-class-name}";

  .loop (@i) when (@i =< @total) {   
    @loop-class: ~".@{extending-class-name}-@{i}";   
    @{loop-class} {     
      &:extend(@{extending-class-string}); // feature request
    }    
    .loop(@i + 1);
  }
  .loop(@i);  
}

.extended-class {
  float: left;
}
.inc-loop(extended-class, 8);

or even better, if this worked!:

.inc-loop (@extending-class-name; @total) {
  @i: 1;
  @extending-class-string: ~".@{extending-class-name}";

  .@{extending-class-name} { // another feature request?
    float: left;
  }

  .loop (@i) when (@i =< @total) {   
    @loop-class: ~".@{extending-class-name}-@{i}";   
    @{loop-class} {
      &:extend(@{extending-class-string}); // feature request
    }    
    .loop(@i + 1);
  }
  .loop(@i);  
}

.inc-loop(extended-class, 8);

Because this would allow us to have a SINGLE mixin, that could create and extend many different classes. Which might be just what you want if you are working on a grid layout system.

P.S.
I suspect that:

.@{extending-class-name}{}

may not work for quite a different reason. Somehow it does not create a class that can be extended, however this probably ought to be a separate Feature Request or Bug Issue.

[lukeapage]

technically, its feasible.. though it again relies on interpolating the variable and then parsing the result into a selector

[kent78]

Plus one for this feature.

[NetzwergX]

This is more or less a must-have. You can not extend Font-Awesome 4.0 anymore due to this. They have the basic functionality defined as .@{fa-css-prefix}{ /* stuff here */}. Might not be the smartest move in their part, but the way LESS currently works you have to hope that the other lib you want to use does it "right" (in this case, not using the full capabilities of LESS).

[Soviut]

A considerable amount of discussion was had regarding the development of the extend() but not every edge case can always be caught. The more examples you can provide, the easier it is to justify additional development AND gives concrete tests that can be applied.

[NetzwergX]

Well, I think Font-Awesome 4.0 is already a pretty good example of why it is bad. It just seems very odd that you can not use one feature of LESS (in this case, .@{fa-css-prefix}) without breaking another one (here extend).

Things that are implemented should work in any case (I hardly think this is an "edge case").

I don't have additional examples, because FA is where this caught my eye. And it isn't even mentioned in the docs anywhere, that extend supports only a very limited functionality.

[mailvidi]

Not sure what's the priority on this one, but would be very useful to extend using variables; so +1 for these feature!

~VS