Addition dynamic function ("Mixin name interpolation").

[kbdsbx]

Sometimes we should make function in compiling time, like this:

@{prefix}-@{function-name}-@{suffix} () {
};

Because we expert the function which don't output to the finial .css file, but it can be used in compiling time. if any function has been output, the finial .css file is so large. ( 400 line come to 20000+ line etc. )

In current occasion, it has been output:

.prefix-function-suffix () {
}

[seven-phases-max]

Please provide more details on what you're trying to achieve (instead of how you think you could do that). A proposal w/o a clear use-case is barely going to get anywhere (see Feature requests).

Usually a code like in your example is an XY-problem - e.g. similar to this (I.e. if you provide your actual use-case I can give a hint on the proper way of handling it w/o the dreadful interpolations).

[kbdsbx]

Sorry for you, English isn't my native language.

This is code fragment:

// library.less
.media-select ( @tag, @value, @min ) when ( @min > 0 ) {
    @{tag} {
        @media ( min-width: @min ) {
            @value();
        }
    }
}

first called:

// library.less
.media-select ( 'xs-none', { display : none }, 768px );

next:

// project.less
.page {
    .xs-none;
}

In the end, It is output:

@media ( min-width: 768px ) {
    .xs-none {
        display: none;
    }
}

@media ( min-width: 768px ) {
    .page {
        display: none;
    }
}

I hopes it didn't output .xs-none in the final project.css, but .page did.

/* in fantasy */
@media ( min-width: 768px ) {
    .page {
        display: none;
    }
}

In current version, the only way to not outputting mixin is append the "()" after the style name like this:

.mixin () {            // It can't be output.
    display: none;
}
.page {
    .mixin;
}

But when the style name is variables or include variables, It doesn't work.

// library.less
.media-select ( @tag, @value, @min ) when ( @min > 0 ) {
    @{tag}() {          // error.
        @media ( min-width: @min ) {
            @value();
        }
    }
    ~"@{tag}()" {          // error.
        @media ( min-width: @min ) {
            @value();
        }
    }
    @_tag : @tag + "()"
    @{_tag} {          // error again.
        @media ( min-width: @min ) {
            @value();
        }
    }
}

@seven-phases-max

[seven-phases-max]

Well, this is exactly the case I pointed to above (#2702 (comment)). In such use-cases you do not encode a hardcoded device ("screen-size") name into the mixin name, but provide it as the mixin parameter simply because it is nothing but a mixin parameter.
E.g. this:

// project.less
.page {
    .xs-none;
}

should really be this instead:

// project.less
.page {
    .none(xs);
}

Then instead of trying to define multiple @{name}-@{parameter} mixins by multiple .media-select calls, you simply define the only .name(@parameter) mixin that can handle any arbitrary screen-size.
Yet again see the examples in the discussion after #2702 (comment) (counting that depending on your coding preferences an exact implementation may vary quite dramatically, e.g. not necessary involving any plugins or so. E.g. see http://stackoverflow.com/questions/41721356 for another relevant example... etc.).

---

_{Honestly I do know a hack to get (sort of) interpolated-parametric-mixin-identifiers but I don't think I even should have metioned this at all. But well, just in case.}

[seven-phases-max]

I'm tending to close this as duplicate of #2702 (I renamed that one accordingly), unless there're any objections.

[kbdsbx]

OK, thank you for your response.

The simply way is put the argument into the argument list, but in my less library, the two occasion is existed.

first occasion, the output css label can be use in html class attribute. such as:

<div class="xs-none l-block"></div>

second, when I changed the switch, like this:

// @params output
//     true : output all label which can be use in the html class
//     false : just working as a library function.
@ouput : true;

All of less call such as xs-none are only can be calling in other less file, but do not output to the css file.

however, the two occasion is sharing one code.

maybe the one who in you put link is a same idea.

[seven-phases-max]

the two occasion is sharing one code.

In general the idea of reusing front-end CSS styles as back-end reusable components is usually considered flawed for many reasons but primarily because that way you create an unnecessary coupling between totally orthogonal stuff (back-end and front-end, or in other words, the identifiers you use in HTML (your actual CSS styles) and identifiers you use in Less itself (i.e. reusable components)). This usually leads to a maintenance nightmare (in a half of a year they'll ask you to change .xs-none style in one project and will you remember that this also affects .page in another? And what if it shouldn't?)
So it's still preferred to be:

// library.less
.xs-none {
    .none(xs);
}
// project.less
.page {
    .none(xs);
}

(yes, it's more verbose but it will save you hours and days of the debugging-headache / rewriting-everything eventually. Simply because, as it goes further, a "CSS theme/framework library" != "CSS building-blocks library", even if they share a lot of code and the former can use the latter, most attempts to have two-in-one are going to fail... Because the more complex it will go the more orthogonal and often directly opposite/mutually-exclusive requirements these two will imply).

---

Either way for things like:

All of less call such as .xs-none are only can be calling in other less file, but do not output to the css file.

the dedicated solution is @import (reference) ...(no need for any true/false variable hackery).

[matthew-dean]

Yes, close in favor of #2702