Oh, saya mengerti, tidak. Tapi kamu bisa..

.myselector () {
  <strong i="6">@return</strong>: 2px;
}

.class {
  .myselector;
  border: <strong i="7">@return</strong> solid red;
}

cukup jelek sekalipun.

Tentu saja. Mungkin bagus untuk memiliki nilai yang dikembalikan untuk fungsi warna khusus (dan fungsi nilai khusus lainnya) saat pelindung mixin terpasang. @return bisa menjadi variabel yang dicadangkan untuk KURANG. Seperti yang Anda katakan, agak jelek untuk hanya memiliki mixin yang tidak melakukan apa-apa selain penugasan variabel saat dipanggil.

Akan lebih baik untuk melihat contoh pertama yang saya posting didukung di beberapa titik. Alasannya adalah bahwa Anda memiliki spin, lighten, darken, dll yang berfungsi sebagai mixin bawaan, jadi logika untuk nilai pengembalian sudah ada di KURANG, itu hanya akan membuka pintu untuk mixin khusus.

Saya tidak berpikir bahwa pemrograman mengatakan fungsionalitas itu mudah bagi Anda, hanya saja itu akan memberdayakan orang untuk sedikit memperluas logika.

iya betul, tapi saya juga suka yang sekarang ini, dimana 'fungsi'nya semua javascript..

Tidak bisakah variabel menerima argumen dengan cara yang sama seperti yang dilakukan mixin? Usecase saya misalnya:

@boxGlow(<strong i="6">@spread</strong>: 5px, <strong i="7">@color</strong>: #f00): inset 0 0 <strong i="8">@spread</strong> @color;
.myselector {
   box-shadow: 1px 1px 1px #000, @boxGlow(2px, #00f);
}

Ini juga cukup analog dengan JavaScript di mana fungsi hidup dalam variabel biasa.

@cloudhead : Jika saya menghabiskan beberapa waktu untuk mengimplementasikan fitur itu (saya belum melihat sumber Less, jadi saya tidak bisa menjanjikan apa-apa), apakah Anda bersedia menambahkannya jika kodenya cukup bagus?

Menambahkan kemampuan return ke mixin akan mempertahankan pemetaan mixin ke fungsi JavaScript, sambil tetap memfasilitasi kasus penggunaan @jacobrask dan @matthewdl . Saya telah mendokumentasikan ini sedikit lebih banyak tentang masalah 637 .

duplikat #538

ups, ini #538

Ini akan menjadi solusi yang sangat, sangat berguna.

Saya mencoba menerapkan gambar yang mengubah ukuran secara dinamis (seperti [UIImage resizable...] di iOS) dan saya ingin menggunakan fungsi yang akan mengembalikan string URL, bukan pasangan properti/nilai.

Saat ini saya menggunakan solusi @cloudhead .

Hanya untuk mengikat ini dengan baik, ini harus disertakan ketika dukungan options.json ditambahkan. Edisi: #850

Mixin adalah mixin, kita tidak boleh menyamakan penggunaannya dengan fungsi. Jika memiliki kemampuan untuk mendefinisikan fungsi kustom dalam style sheet adalah sesuatu yang kita inginkan, itu bisa menjadi diskusi terpisah.

Mixin adalah mixin, kita tidak boleh menyamakan penggunaannya dengan fungsi.

Masalahnya adalah tidak ada cara untuk melarang penggunaan mixin sebagai fungsi. Dimungkinkan untuk menggunakan satu sebagai yang lain dan mereka (dan saya :) dapat menggunakan kemampuan itu. Jadi secara de facto ini hanya masalah gula sintaksis dan verbositas:

.sum(<strong i="8">@a</strong>, @b) {
    @-: (<strong i="9">@a</strong> + @b);
}

usage {
    width: @-;.sum(20px, 33px);
}

Menggunakan "fungsi" yang sama dua kali dalam "lingkup yang sama":

// short (since 1.6.2):
usage {
    & {width:  @-;.sum(55px, 77px)}
    & {height: @-;.sum(11px, 99px)}
}

// oldschool (since 1.4.x):
usage {
    .-() {width:  @-;.sum(20px, 33px)}
    .-() {height: @-;.sum(40px, 42px)}
    .-();
}

Apakah ada alasan untuk menemukan beberapa sintaks "Deklarasi/definisi kurang fungsi" baru (berbeda dari sintaks definisi mixin) hanya untuk tidak mengizinkan penggunaan width: .sum(20px, 33px); secara langsung?

Apa yang baru saja Anda lakukan di sana. Itulah beberapa peretasan tingkat berikutnya yang terjadi di sana, lol.

@lukeapage Saya minta maaf saya tidak dapat memahami keadaan masalah ini. Anda telah menempatkan referensi untuk masalah ini pada beberapa orang lain tetapi ini disetel sebagai ditutup. Apakah ada rencana untuk mengizinkan penggunaan mixin sebagai lambda atau apakah Anda menyarankan kami untuk memanfaatkan solusi pengaturan variabel global? Dalam masalah lain saya mengerti Anda berencana untuk menghapusnya di masa depan.

@seven-phases-max pendekatan Anda luar biasa tetapi tidak ada cara untuk meneruskan ke penjumlahan mixin hasil memanggil sum dua kali, apakah saya salah?
Berbicara dengan bahasa yang agak lebih universal, ini: foo(bar(1, 2), bar(3, 4))

@axelcostaspena Yah, semuanya mungkin menggunakan mixin, itu hanya masalah verbositas (jelas 5 atau 6 baris kode tidak terlihat seperti pengganti praktis untuk oneliner).

less-plugin-functions

kurang-plugin-fungsi

Wow. Bagus! Sungguh, satu-satunya hal yang akan saya tingkatkan dari segi sintaks jika ini dipindahkan ke inti, adalah mengubah blok luar menjadi @functions dan mungkin menghilangkan periode awal pada deklarasi mixin untuk konsistensi dengan bagaimana fungsi-fungsi ini digunakan di situs panggilan (yaitu; juga tanpa periode awal, sebagai fungsi Kurang nyata).

Misalnya

<strong i="10">@functions</strong> {
    foo(@x) {
        return: <strong i="11">@x</strong> * 2;
    }
}

Ini masih menyisakan masalah memiliki fungsi/mixin yang dapat ditetapkan ke variabel dan dapat dilewati sebagai parameter, sehingga mereka dapat digunakan sebagai delegasi lambda. Tapi ini di sini sudah merupakan cara yang sangat bagus untuk memisahkan mixin 'komputasi' dari mixin 'render'.

Wow. Bagus! Sungguh, satu-satunya hal yang saya akan tingkatkan dari segi sintaks jika ini dipindahkan ke inti, adalah mengubah blok luar menjadi

Ya, kita harus menghormati ini dari @cloudhead :

Mixin adalah mixin, kita tidak boleh menyamakan penggunaannya dengan fungsi.

Mendefinisikan fungsi sebagai ".foo" dengan meletakkannya di ".function" dan kemudian memanggilnya dengan "foo" tidak terlalu masuk akal sebagai sintaks.

@rjgotten Satu saran yang saya buat untuk sintaks Anda adalah untuk tidak membuat fungsi jamak, bahkan jika ada lebih dari satu fungsi di blok fungsi. Tampaknya lebih Kurang/CSS konsisten.

<strong i="15">@function</strong> {
    foo(@x) {
        return: <strong i="16">@x</strong> * 2;
    }
}

Juga, sebagai gula:

<strong i="20">@function</strong> foo(@x) {
     return: <strong i="21">@x</strong> * 2;
}

Saya berasumsi bahwa fungsi-fungsi ini hanya ditambahkan ke registri fungsi Less sebagai fungsi JS normal yang mengevaluasi ekspresi Less?

@rjgotten @matthew-dean : Sintaks yang bagus, saya telah merenungkan bagaimana seseorang dapat "dengan baik" menambahkan fungsi ke less untuk sementara waktu. Sintaks itu tampak jelas, intuitif, dan tidak ambigu.

Satu pertanyaan - apakah bagian return: diperlukan?

Namun satu pertanyaan - apakah pengembaliannya: bagian diperlukan?

Hmm, bagaimana Anda mengembalikan nilai tanpa menulis pernyataan pengembalian?

Hmm, bagaimana Anda mengembalikan nilai tanpa menulis pernyataan pengembalian?

Fungsinya bisa berupa ekspresi.

<strong i="8">@function</strong> foo(@x) { <strong i="9">@x</strong> * 2  }

Itu mungkin sebenarnya lebih bersih. Jadi, pada dasarnya, fungsi bisa menjadi cara mengabstraksi ekspresi yang mengevaluasi suatu nilai, alih-alih blok pasangan prop / nilai. Saya setuju, properti return: sepertinya semacam peretasan bahasa.

Dibuka kembali karena sepertinya kami mempertimbangkan kembali ini sebagai kemungkinan.

@matthew-dean Atau mungkin kita benar-benar harus mendengarkan @cloudhead dan membuat tiket baru? (Mungkin itu kesalahan saya dengan menautkan di sini alih-alih membuat yang baru ... Saya kira saya baru saja melewatkan alasan sebenarnya mengapa itu ditutup terakhir kali) ...

foo(@x) { <strong i="6">@x</strong> * 2 }

Oh tidak:

foo(<strong i="10">@x</strong>, @y) { 
    <strong i="11">@z</strong> * @w; 
    <strong i="12">@z</strong>: pow(<strong i="13">@x</strong>, @y);
    <strong i="14">@w</strong>  pow(<strong i="15">@z</strong>, @y); // wtf, I just missed : here
}

Ada alasan mengapa hampir setiap bahasa lain memiliki kata kunci return .

Ya, jika Anda ingin memiliki beberapa ekspresi dalam suatu fungsi, maka sintaks tersebut tidak akan berfungsi. Anda memperdebatkan sesuatu yang tidak saya usulkan. Anda bertanya bagaimana seseorang akan memiliki fungsi tanpa pernyataan pengembalian, dan begini caranya:

<strong i="6">@function</strong> foo(<strong i="7">@x</strong>, @y) { 
   pow(<strong i="8">@x</strong>, @y) * pow(pow(<strong i="9">@x</strong>, @y), @y)
}

Tidak yakin tentang kurung kurawal {} jika itu hanya ekspresi, tapi ya, itu bisa dilakukan. HARUS dilakukan adalah pertanyaan lain. Dan ya, kita bisa membuat masalah baru tentang fungsi. Apa pun yang masuk akal bagi Anda.

Sebuah ide yang berbeda baru saja muncul di kepalaku. Saya kebetulan sedang mengerjakan aplikasi VBScript lama, dan nilai yang dikembalikan ditetapkan ke nama fungsi. Ini mungkin lebih masuk akal dalam konteks "menetapkan" nilai (jika Anda menginginkan beberapa ekspresi), karena return: adalah jenis perluasan konsep pernyataan kembali. Seperti dalam:

<strong i="16">@function</strong> foo(<strong i="17">@x</strong>, @y) { 
    <strong i="18">@z</strong>: pow(<strong i="19">@x</strong>, @y);
    <strong i="20">@w</strong>: pow(<strong i="21">@z</strong>, @y);
    foo: <strong i="22">@z</strong> * @w; 
}

Dengan begitu, ini bukan properti "ajaib", tetapi penetapan nilai yang sebenarnya untuk fungsi tersebut. @battlesnake @seven-phases-max - apa pendapat Anda tentang itu?

Dan mungkin evaluasi ekspresi tunggal bisa menjadi gula? Terbaik dari kedua dunia? Ringkas dan fleksibel?

<strong i="6">@function</strong> foo(@x) { foo: <strong i="7">@x</strong> * 2;  }
// same as
<strong i="8">@function</strong> foo(@x) { <strong i="9">@x</strong> * 2; }

Meskipun saya tidak menyukai "pengembalian otomatis" di Ruby dan Groovy, ini adalah satu tempat yang mungkin menyenangkan - meskipun demikian, saya tidak terlalu berpendirian tentang hal itu, saya hanya menyukai beberapa kata kunci yang KURANG miliki. Mengingat waktu saya telah menyia-nyiakan debugging kode Grails di mana bug disebabkan oleh seseorang yang secara tidak sengaja mengembalikan nilai yang tidak mereka inginkan, saya agak setuju dengan alasan Anda untuk menyimpan semacam sintaks pengembalian eksplisit. Saya suka ide sintaksis VB itu (tidak pernah berpikir saya akan mengatakan kata-kata itu ...).

Mengizinkan sintaks VB, dan "pengembalian" mungkin bagus juga, seperti bagaimana Delphi mendukung "nama fungsi := nilai" dan "Hasil := nilai" dengan Hasil menjadi variabel ajaib untuk nilai kembalian.

Kasus penggunaan saya saat ini adalah untuk generator gradien "web 2.0" kecil yang norak:

<strong i="8">@function</strong> web2-control(<strong i="9">@direction</strong>, <strong i="10">@start</strong>, <strong i="11">@end</strong>, <strong i="12">@split</strong>: 50%, <strong i="13">@spread</strong>: 5%) {
    return: linear-gradient(<strong i="14">@direction</strong>, <strong i="15">@start</strong> 0%, <strong i="16">@start</strong> ((@split-@spread)), <strong i="17">@end</strong> ((@split+@spread)), <strong i="18">@end</strong> 100%)
}

.stupid-button {
    background: web2-control(to bottom, white, darken(skyblue, 10%));
    &:hover {
        background: web2-control(to bottom, white, skyblue);
    }
}

Nilai masalahnya, bukan maksud kodenya haha ​​:)

@battlesnake Lucu, contoh gradien linier Anda adalah hal yang saya pikirkan sejauh kasus penggunaan yang baik. Ada kalanya mengembalikan pasangan prop/nilai kaku ketika Anda ingin beroperasi pada sebagian nilai, terutama ketika nilai itu sendiri menerima banyak nilai. Contoh lain adalah sintaks transformasi. Terkadang mixin tidak cocok.

Dan ya, VBScript juga bukan favorit saya, tetapi seniman yang baik menarik inspirasi dari mana-mana. :-)

foo: <strong i="6">@z</strong> * @w; Dengan begitu, ini bukan properti "ajaib", tetapi penetapan nilai yang sebenarnya untuk fungsi tersebut.

Itu masih "properti ajaib" yang sama. Perbedaan nilai charcode antara f . o . o dan r . e . t ... tidak akan membuat perubahan logika apa pun (tidak termasuk bahwa jika nama fungsi tumpang tindih dengan beberapa properti yang ada, itu menjadi titik lain dari kebingungan pembaca... Juga menghitung tugas untuk mengganti nama foo ke bar setiap kali Anda menyalin beberapa cuplikan dari satu fungsi ke fungsi lainnya. Jadi secara pribadi saya tidak dapat melihat apa yang salah dengan return ... Ini hanya "setel nilai kembalian" pengenal.)

Sedangkan untuk membuatnya opsional. Oke, saya mengerti sekarang apa yang Anda maksud ... Yah, ya, ini salah satunya ... ah, tidak apa-apa: hanya -1 :)

Saya menginginkan gaya gradien linier yang sama untuk tombol dalam keadaan apa pun, hanya dengan warna atau kecerahan yang diubah, jadi:

<strong i="6">@function</strong> web2-gradient(<strong i="7">@direction</strong>, <strong i="8">@start</strong>, <strong i="9">@end</strong>, <strong i="10">@split</strong>: 50%, <strong i="11">@spread</strong>: 5%) {
    return: linear-gradient(<strong i="12">@direction</strong>, <strong i="13">@start</strong> 0%, <strong i="14">@start</strong> ((@split-@spread)), <strong i="15">@end</strong> ((@split+@spread)), <strong i="16">@end</strong> 100%)
}

<strong i="17">@primary</strong>: red;
<strong i="18">@contrast</strong>: 10%;

<strong i="19">@light</strong>: lighten(<strong i="20">@primary</strong>, @contrast);
<strong i="21">@dark</strong>: darken(<strong i="22">@primary</strong>, @contrast);
<strong i="23">@lighter</strong>: lighten(<strong i="24">@primary</strong>, ((@contrast*2)) );
<strong i="25">@darker</strong>: darken(<strong i="26">@primary</strong>, ((@contrast*2)) );

@button-normal-bg: web2-gradient(to bottom, <strong i="27">@light</strong>, @dark);
@button-hover-bg: web2-gradient(to bottom, <strong i="28">@lighter</strong>, @primary);
@button-down-bg: web2-gradient(to bottom, <strong i="29">@darker</strong>, @primary);

Saya benar-benar melihat untuk pindah ke Stylus setelah menemukan bahwa saya tidak dapat membuat fungsi yang menghasilkan nilai di Less, tetapi Stylus tidak memiliki perasaan deklaratif yang kurang saya sukai.

Saya lebih condong ke sintaks return: value sekarang - tetapi untuk satu baris, bisakah kita menggunakan sintaks OpenSCAD seperti:

<strong i="7">@function</strong> square(@x) = <strong i="8">@x</strong> * @x;

Jadi kami membuat pengembalian eksplisit di sana juga dengan menggunakan = dan ; sebagai ganti kurung kurawal.

Atau agar lebih seperti CSS:

<strong i="15">@function</strong> square(@x) : <strong i="16">@x</strong> * @x;

Menggunakan tanda titik dua sebagai ganti simbol sama dengan.

Itu masih "properti ajaib" yang sama.

Eh, tidak, karena return adalah properti yang dibuat-buat, dan foo didefinisikan oleh pengguna, tapi oke. Saya tidak begitu terikat padanya. Saya hanya berharap pengembalian itu tidak terlihat seperti properti, dan kemudian tidak. Tetapi selain menetapkan nama fungsi, saya tidak punya proposal yang lebih baik.

@battlesnake Opsi kedua adalah preferensi saya. Itu lebih masuk akal. Saya masih bertanya-tanya apakah ekspresi satu baris mungkin lebih disukai untuk kesederhanaan bahasa. Fungsi selalu bisa dirantai (nilai yang dihasilkan dikirim ke fungsi lain).

Jadi, saya tidak tahu. Mendefinisikan sintaks untuk blok multi-baris lain untuk menghasilkan hanya satu nilai tampaknya.... Saya tidak tahu, Less sudah memiliki begitu banyak jenis blok. Apakah ada banyak contoh dunia nyata di mana fungsi multi-baris diperlukan? Contoh multi-baris masih dapat diselesaikan dalam satu baris. Dan, jika memang, ada kebutuhan untuk membangun fungsi multi-baris yang kompleks, bukankah itu lebih baik dilayani oleh plugin sebaris? Sejauh bahasa Kurang, kebutuhan untuk pernyataan kembali hanya terasa seperti pertanda buruk bagi saya.

Jadi, apakah ada kasus dunia nyata di mana:
a) Anda ingin mengevaluasi ekspresi,
b) terlalu sulit atau rumit untuk melakukannya dalam satu baris (atau dengan fungsi berantai)
c) tidak bisa di plugin JS
?

oneliner

Saya masih tidak dapat melihat alasan mengapa saya _dipaksa_ untuk menulis
... (<strong i="8">@a</strong> + <strong i="9">@b</strong> + @c) * (<strong i="10">@a</strong> + <strong i="11">@b</strong> + @c);
bukannya biasa:

<strong i="15">@x</strong>: <strong i="16">@a</strong> + <strong i="17">@b</strong> + @c;
return <strong i="18">@x</strong> * @x;

bukankah itu lebih baik dilayani oleh plugin sebaris?

Berikut contoh sederhana untuk mengilustrasikan betapa mudahnya fungsi Less dapat menendang fungsi JS untuk banyak kasus penggunaan (sebenarnya selalu kecuali itu tentang kinerja atau beberapa fungsi yang sama sekali tidak ada di Less itu sendiri),
(buatan) Lebih sedikit fungsi ( format less-plugin-functions ) untuk mengembalikan opacity/alfa warna kuadrat:

.function-sqralpha(@c) {
    <strong i="26">@a</strong>: alpha(@c);
    return <strong i="27">@a</strong> * @a;
}

Sekarang kode yang diperlukan untuk melakukan hal yang sama di JS:

functions.addMultiple({
    sqralpha : function(c) {
        var a = c.alpha; // no docs and no guaranty this internal stays the same, but there's no easy way to reuse built-in Less `alpha()` here
        return new tree.Dimension(a * a); // Dimension? some kind of quantum mechanics?
    }
});

Dan faktanya, semakin kompleks (dalam hal melibatkan lebih banyak dan berbeda jenis nilai masuk, menengah dan keluar, fungsi bawaan digunakan kembali, dll.) suatu fungsi menjadi semakin sulit untuk ditulis dalam JS.

Jadi jujur ​​saja bagi saya ide-ide baru-baru ini terlihat ehm, ... saya bahkan tidak yakin ... aneh? :)

@matthew-dean : OpenSCAD hanya mengizinkan fungsi satu baris saya pikir, tetapi Anda bisa mendapatkan kemampuan yang sama dari fungsi muilti-line dengan menggunakan blok let di OpenSCAD.

Kalau dipikir-pikir, sintaks OpenSCAD untuk iterasi for dan untuk blok let mungkin berguna untuk KURANG, mengingat bahwa kedua bahasa tersebut merupakan cara deklaratif untuk mendefinisikan geometri dan gayanya.

@seven-phases-max Saya masih skeptis, dan saya merasa beban pembuktian ada pada contoh multi-baris. Yang mengatakan, return <strong i="5">@x</strong> * @x; terasa lebih baik daripada return: <strong i="7">@x</strong> * @x , karena lebih jelas secara logis bahwa fungsi menerima / mengembalikan nilai, daripada ditugaskan ke properti yang melakukan...sesuatu.

Tetapi pernyataan kembali terasa semakin berkurang seperti Kurang setiap saat.

Seperti ini:

Saya masih tidak dapat melihat alasan mengapa saya akan dipaksa untuk menulis
... (<strong i="14">@a</strong> + <strong i="15">@b</strong> + @c) * (<strong i="16">@a</strong> + <strong i="17">@b</strong> + @c) ;
bukannya biasa:

<strong i="21">@x</strong>: <strong i="22">@a</strong> + <strong i="23">@b</strong> + @c;
return <strong i="24">@x</strong> * @x;

Pertanyaannya lebih baik dinyatakan: apa alasan kuat untuk menambahkan lebih banyak sintaks ke bahasa hanya untuk membagi ekspresi itu menjadi dua baris? Beban harus membuktikan sintaks yang lebih verbose dengan kata kunci tambahan diperlukan, bukan sebaliknya. Tidak ada yang "normal" tentang itu, karena belum ada. Dan itu masih belum mendekati contoh dunia nyata. Contoh @battlesnake masih hanya ekspresi satu baris.

<strong i="29">@function</strong> {
    web2-control(<strong i="30">@direction</strong>, <strong i="31">@start</strong>, <strong i="32">@end</strong>, <strong i="33">@split</strong>: 50%, <strong i="34">@spread</strong>: 5%): 
        linear-gradient(<strong i="35">@direction</strong>, <strong i="36">@start</strong> 0%, <strong i="37">@start</strong> ((@split-@spread)), <strong i="38">@end</strong> ((@split+@spread)), <strong i="39">@end</strong> 100%);
}

Saya menyukai gagasan fungsi, tetapi akan mengecewakan jika kami menambahkan sesuatu yang lebih berat ke bahasa daripada yang benar-benar dibutuhkan/berguna. Kami sudah memiliki 3 jenis blok yang "melakukan sesuatu": mixin, kelas/id yang dapat "dievaluasi" dan diimpor ke ruang lingkup (yang menjadikannya semacam mixin non-parameter, tetapi agak berbeda), dan aturan yang terpisah. Jika Anda menambahkan blok fungsi, semua definisi ini memiliki sintaks yang tidak konsisten satu sama lain. Mixin tidak didefinisikan dengan kata kunci @ tetapi fungsinya. Blok aturan yang terpisah diberi tanda titik dua (dan harus diakhiri dengan titik koma), tetapi blok mixin tidak.

Saya pikir ini harus mengambil langkah mundur dan melihat sintaks secara keseluruhan. Sintaks @function dengan pernyataan kembali mungkin baik-baik saja, tetapi saya tidak melihat keselarasan logis antara semua bagian Less dan sintaks ini. Dan apakah ada penyelarasan logis antara fungsi Less dan fungsi plugin? Di suatu tempat rasanya bagi saya seperti kita kehilangan beberapa kohesi. Apa kamu tau maksud saya?

Artinya, pertimbangkan sejenak bagaimana tampilannya:

.class {
  prop: val;
}
.class(<strong i="6">@x</strong>, @y) {
  prop: <strong i="7">@x</strong> * @y;
}
<strong i="8">@class</strong>: {
  prop: val;
};
<strong i="9">@function</strong> class(<strong i="10">@x</strong>, @y) {
  return <strong i="11">@x</strong> * @y;
}

Saya tahu bahwa suatu fungsi harus didefinisikan secara khusus untuk membedakan antara blok lain, tapi mungkin itu masalahnya. Jika fungsi mengatakan @function maka mixin harus mengatakan @mixin . Menambahkan hanya satu menempatkan bagian-bagian dari blok yang dievaluasi dalam ketidaksepakatan. Jadi saya agak :-1: jika ini yang akan terjadi.

@matthew-dean saya agak tersesat. Jadi bagaimana tepatnya?

<strong i="6">@function</strong> web2-gradient(<strong i="7">@direction</strong>, <strong i="8">@start</strong>, <strong i="9">@end</strong>, <strong i="10">@split</strong>: 50%, <strong i="11">@spread</strong>: 5%)
    : linear-gradient(<strong i="12">@direction</strong>, <strong i="13">@start</strong> 0%, <strong i="14">@start</strong> ((@split-@spread)), <strong i="15">@end</strong> ((@split+@spread)), <strong i="16">@end</strong> 100%)

dari pada

<strong i="20">@function</strong> web2-gradient(<strong i="21">@direction</strong>, <strong i="22">@start</strong>, <strong i="23">@end</strong>, <strong i="24">@split</strong>: 50%, <strong i="25">@spread</strong>: 5%) {
    return: linear-gradient(<strong i="26">@direction</strong>, <strong i="27">@start</strong> 0%, <strong i="28">@start</strong> ((@split-@spread)), <strong i="29">@end</strong> ((@split+@spread)), <strong i="30">@end</strong> 100%);
}

menyelesaikan semua masalah yang Anda sebutkan? Mungkin masuk akal untuk memulai dengan mempertanyakan @function itu sendiri dan bukan {} ?

Saya tidak berkomentar @function (apakah Anda lupa siapa yang menyarankan @function atas? ;) awalnya hanya karena pendapat saya tentang hal itu sebagai radikal seperti biasa (jadi sekarang akan memulai pertarungan sintaks :):

Sejujurnya secara pribadi saya akan lebih senang dengan .function .foo , function foo , function:foo atau akhirnya foo:function (aneh tapi setidaknya mengikuti :extend ). Mengadopsi cara Sassish dalam menggunakan sintaks @at-rule untuk "directives" Less baru tampaknya hanya _terlalu_ terlambat untuk Less meskipun berpotensi tidak terlalu bertentangan dengan CSS seperti yang lainnya.

tapi saya tidak melihat keselarasan logis antara semua bagian Less dan sintaks ini

? Jadi Anda tidak benar-benar melihat kesamaan antara fungsi Less mixin dan (sintaks apa pun)? Saya bisa menebak banyak pengguna yang tidak mengerti mixin parametrik sama sekali menganggapnya sebagai semacam "CSS-properties-batch" primitif saja, tetapi dalam konteks fungsi/mixin khusus ini, hmm ...

Either way:
less-plugin-functions melakukan semuanya dalam ~50 baris kode (jika saya menghapus semua peretasan khusus plugin) persis karena ia menggunakan kembali kode inti yang ada untuk mengurai dan mengevaluasi mixin. Menyediakan semua fitur _yang ada dan didokumentasikan_ (Anda tidak wajib menggunakannya) secara gratis.
Jadi mengingat ini, sekarang saya hanya bertanya-tanya bagaimana:

.class {
  prop: val;
}
.class(<strong i="55">@x</strong>, @y) {
  prop: <strong i="56">@x</strong> * @y;
}
<strong i="57">@class</strong>: {
  prop: val;
};
<strong i="58">@function</strong> class(<strong i="59">@x</strong>, @y) : <strong i="60">@x</strong> * @y;

dapat berpotensi lebih baik untuk membenarkan kemungkinan besar implementasi yang lebih kembung (+ kode penguraian baru) untuk menyediakan fungsionalitas yang lebih terbatas?

Dan akhirnya, untuk mencadangkan "konsistensi fitur/sintaks" saya kira tabel yang diformat ulang dari fitur Less yang ada seperti yang saya lihat akan menarik (untuk berjaga-jaga):

name   {prop: val}  // a ruleset having some standard CSS selector as a name
<strong i="66">@name</strong>: value;        // variable
<strong i="67">@name</strong>: {prop: val}; // *unnamed* ruleset assigned to a variable as its value

// mixin
.name(<strong i="68">@x</strong>, @y) {
    prop: <strong i="69">@x</strong> * @y;
}

// function (whatever `func` directive)
<func> name(<strong i="70">@x</strong>, @y) {
    return: <strong i="71">@x</strong> * @y; // return property of the function
}

Tidak memiliki awalan untuk nama fungsi akan konsisten dengan status KURANG saat ini, yaitu

color: darken(<strong i="6">@base</strong>, 10%);
background: checkerboard(1em, lighten(<strong i="7">@base</strong>, 20%), white);

Tidak memiliki awalan untuk fungsi JS, sementara membutuhkan awalan untuk fungsi yang disediakan dalam kode KURANG yang sebenarnya tampaknya agak mundur.

Saya pribadi tidak melihat ada gunanya fungsi multi-baris, tetapi saya mungkin memiliki momen "yang membutuhkan> 640k RAM" di sini.

Jika ada kebutuhan nyata untuk fungsi multi-baris di masa mendatang, setelah kami mengadopsi sintaks <strong i="12">@function</strong> name(params) : expression; , kami selalu dapat mengizinkannya dengan menggunakan blok let gaya SCAD:

<strong i="16">@function</strong> multi-line-thing(<strong i="17">@a</strong>, <strong i="18">@b</strong>, @c) :
    let { <strong i="19">@sum</strong> : <strong i="20">@a</strong> + <strong i="21">@b</strong> + @c; <strong i="22">@product</strong> : <strong i="23">@a</strong> * <strong i="24">@b</strong> * @c; <strong i="25">@mean</strong> : <strong i="26">@sum</strong> / 3; }
        <strong i="27">@sum</strong> / <strong i="28">@product</strong> ~", " @mean;

Sintaks itu masih <strong i="31">@function</strong> name(params) : expression; . Sintaks untuk expression akan diperluas untuk mengizinkan let { assignments } expression .

Variabel dalam blok tersebut dicakup ke ekspresi yang mengikuti blok saja, mereka tidak bocor ke cakupan induk.

Dengan cara ini kami dapat menambahkan fungsi ekspresi tunggal sekarang, tetapi kami masih memiliki opsi untuk memperluasnya ke multi-baris di masa mendatang (jika diperlukan), dengan menggunakan fungsi gaya blok "resep" (dengan return ) atau fungsi gaya fungsional "sub-lingkup" (dengan let ).

Jika gaya blok akan digunakan, saya suka sintaks return: value; sintaks return value; - karena semua yang bukan blok masih merupakan pasangan key: value , dengan return (atau mungkin result ) hanya menjadi nama kunci khusus dalam fungsi. Sintaks @function eksplisit kemudian memastikan bahwa return: tidak diperlakukan sebagai nama atribut CSS.

Semuanya seperti aturan, termasuk fungsi, yang terlihat persis sama dengan mixin. Sungguh, ketika diringkas, satu-satunya diskriminator adalah bahwa mixin dapat mengatur properti CSS dan fungsi itu harus memiliki pernyataan kembali. (Anda tidak dapat dan tidak boleh melakukan keduanya.)

Jadi mengapa tidak mengandalkan perilaku itu secara langsung?

Misalnya

.mixin(<strong i="8">@a</strong>, @b) {
  value : <strong i="9">@a</strong> @b;
}
.func(<strong i="10">@a</strong>, @b) {
  return <strong i="11">@a</strong> @b;
}

Kemudian biarkan kompiler mencari tahu di _call site_ apakah itu memanggil mixin atau fungsi dan memunculkan pengecualian jika satu atau yang lain digunakan dalam konteks yang tidak pantas.

Atau, jika pengecualian bukan milik Anda:

• Tentukan keluaran CSS dari fungsi yang disebut sebagai mixin sebagai kumpulan aturan kosong.
• Tetapkan nilai pengembalian fungsi mixin sebagai kumpulan aturan dari semua properti CSS yang diterapkan dan kumpulan aturan bersarang yang dievaluasi ke status akhirnya, dikembalikan sebagai kumpulan aturan terpisah.

Hmm polimorfisme... masuk akal kurasa, mixin tidak bisa muncul di sisi kanan titik dua dan fungsi hanya bisa muncul di sana. Selama kami memastikan bahwa kesalahan muncul jika salah satu digunakan di tempat yang salah, menggunakan sintaks mixin untuk fungsi tampaknya ok.

Sungguh, ketika diringkas, satu-satunya diskriminator adalah bahwa mixin dapat mengatur properti CSS dan fungsi itu harus memiliki pernyataan kembali.

Inilah yang saya maksud. Haruskah kita membuat tipe aturan baru yang memiliki metode "define" yang berbeda?

Tapi... Saya juga setuju dengan ini:

Tidak memiliki awalan untuk fungsi JS, sementara membutuhkan awalan untuk fungsi yang disediakan dalam kode KURANG yang sebenarnya tampaknya agak mundur.

Saya selalu merasa bahwa persyaratan mixin yang diawali dengan . atau # jelek dan menjengkelkan. (Lihat bagian pertama dari: https://github.com/less/less.js/issues/1342.) Anehnya juga hanya dua dari tiga jenis pemilih umum yang dapat dikonversi ke mixin. Itu hanya relevan di sini jika kami mengizinkan mixin untuk mengembalikan nilai.

Namun, ada beberapa alasan untuk memiliki tipe yang terpisah, karena fungsi vars tidak boleh diimpor ke dalam lingkup pemanggil, dan fungsi tidak boleh memiliki penjaga, karena sulit untuk memahami apa artinya itu. Jadi ada perbedaan lain selain bisa mengembalikan nilai.

Saya tidak selalu menentang @function , jelas saya mendukungnya di awal utas. Saya hanya ingin tahu bagaimana semua ini cocok bersama, dan saya ingin kita berhati-hati. Perhatikan bahwa kritik saya bukan untuk menjauhkan kita dari menggunakan satu hal; itu untuk memastikan kita mengajukan semua pertanyaan yang diperlukan dan berpikir kritis.

Bahkan CSS terkadang melanggar aturannya sendiri, dan berisi hal-hal seperti properti vertical-align menyebabkan dua perilaku yang sama sekali berbeda. Jadi, Less juga dapat membuat konvensi baru. Saya hanya ingin membantu memastikan setiap solusi baru tetap Kurang mudah, intuitif, konservatif, dan ringkas.

Saya penggemar membatasi ekspresi satu baris, tetapi jika tampaknya terlalu sewenang-wenang dan membatasi orang lain, maka bentuk multi-baris yang tampaknya paling jelas mungkin memang:

<strong i="21">@function</strong> {
  foo(@a) {
    return @a;
  }
}
// and
<strong i="22">@function</strong> foo(@a) {
  return @a;
}

Mungkin argumen terbaik untuk "define" khusus adalah bahwa, berbeda dari mixin, definisi fungsi tidak dapat atau tidak boleh muncul beberapa kali (dalam cakupan yang sama). Jadi mereka lebih seperti fungsi @plugin dalam hal itu. Jadi, karena propertinya cukup berbeda dari mixin (vars pribadi, definisi tunggal, pernyataan pengembalian), mungkin mixin kooptasi tidak akan berfungsi.

Mengapa tidak mengizinkan javascript literal di dalam less? Pada dasarnya, ini akan memungkinkan Anda menggunakan semua fitur javascript di dalam CSS untuk membuat fungsi. Contoh:

function abs(a) { return Math.abs(a); }

.test { attribute: abs(-5px); }

Perhatikan dua hal:

1. Fungsi adalah javascript literal. Itu dapat dikenali dengan sesuatu seperti: "function /\w+/ ..." dan dihentikan oleh "}". Masalahnya adalah mengidentifikasi di mana "{" mulai dan di mana "}" berakhir. Karena kita dapat memiliki beberapa struktur internal, seperti if, for, dll.
2. Saya tidak memikirkan bagaimana parameter akan diteruskan ke fungsi. Misalnya, javascript apa yang akan diterima jika saya melewati 5px? Dan tentang melewatkan lebih sedikit fungsi, seperti abs(convert(5px, pt)) ?

@rentalhost
Pertama-tama, pernyataan javascript sebaris diperbolehkan dalam implementasi less.js :

div {
    <strong i="8">@x</strong>: -10.5;
    width: unit(`Math.abs(@{x})`, px);
}

Sekunder, Less dirancang sebagai superset CSS, dan CSS sangat sedikit hubungannya dengan bahasa seperti C dan JavaScript pada khususnya. Jadi pernyataan JavaScript langsung seperti function abs(a) {return Math.abs(a);} tidak hanya membingungkan dan tidak konsisten di sana, tetapi juga _berkonflik secara langsung_ dengan sintaksis Less/CSS asli.

Jadi dua alasan dasar, mengapa kode seperti di atas tidak boleh direkomendasikan untuk digunakan dan sintaksis seperti JS tidak boleh dipertimbangkan saat mendesain Lebih sedikit sintaks, sudah jelas:

1. Pernyataan javascript sebaris _memerlukan_ lingkungan JavaScript yang mendasari untuk kompiler (misalnya pernyataan seperti itu tidak akan pernah didukung di PHP atau C# atau port apa pun dari Less. Ini pada dasarnya merusak tujuan dari Less itu sendiri, yang dirancang sebagai platform/lingkungan agnostik bahasa mandiri).
2. "Jenis/entitas bahasa" mendasar dari CSS dan JS hanya ortogonal paling baik dan sekali lagi bertentangan secara langsung paling buruk. Seperti yang sudah Anda perhatikan sendiri, tidak ada cara bagi JavaScript untuk secara langsung mendukung nilai seperti 5px , red , url(//foo/icon.png) dan seterusnya dan seterusnya. Jadi untuk meneruskan nilai dan pernyataan CSS ke "javascript literal" Anda harus menyediakan sintaks perantara dan fasilitas konversi untuk menggabungkan hal-hal ortogonal itu dalam bahasa yang sama. Sebenarnya bukan masalah besar untuk mendesain bahasa seperti itu, tetapi itu tidak akan ada hubungannya dengan Less (yang sekali lagi dirancang sebagai superset CSS dan _tidak ada hubungannya dengan JS _sama sekali_).

Dengan kata lain, semua diskusi kami di atas bukanlah hasil dari apa yang disebut sindrom "tidak ditemukan di sini", tetapi hanya upaya untuk menyesuaikan sintaks definisi fungsi yang mungkin dengan basis sintaksis Less yang sudah ada semulus mungkin.

Mohon mohon mohon:

.halfway-between(<strong i="6">@large</strong>, @small) {
    max(<strong i="7">@large</strong>, @small) - (abs(<strong i="8">@large</strong> - @small) / 2);
}

:senyum:

@andrewhosgood Apa yang terjadi di sini?

.halfway-between(<strong i="7">@large</strong>, @small) {
    max(<strong i="8">@large</strong>, @small) - (abs(<strong i="9">@large</strong> - @small) / 2);
}
.halfway-between(<strong i="10">@large</strong>, @small) {
    property: value;
    foo: bar;
}
.rule {
    width: halfway-between(3, 2);
}

Pada akhirnya, mixin adalah kumpulan aturan berparameter yang dapat memiliki beberapa kecocokan, dan mengembalikan beberapa nilai, dan nama fungsi hanya dapat memiliki satu kecocokan (per cakupan) dan hanya dapat mengembalikan satu nilai.

Saya pikir @battlesnake memiliki proposal sintaks yang paling sederhana dan paling mudah:

<strong i="16">@function</strong> square(@x): <strong i="17">@x</strong> * @x;

Sedikit penyesuaian agar ruang lingkup @x tidak membingungkan:

<strong i="22">@function</strong> square(@x) { <strong i="23">@x</strong> * @x; }

Atau (mungkin) agar kita tidak bingung dengan fungsi berbasis JS:

<strong i="27">@expression</strong> square(@x) { <strong i="28">@x</strong> * @x; }

Saya pikir ekspresi sekali pakai akan lebih sederhana untuk grok, dan tidak akan mencemari pemahaman tentang mixin. Dan, juga akan melayani sebagian besar contoh yang diberikan. Pada dasarnya, Anda hanya memberikan ekspresi singkat (aliasing) untuk digunakan kembali dengan cepat. Pikiran? Saya bertanya-tanya apakah ada cara untuk "mendefinisikan" nama ekspresi tanpa aturan-at. Hmm.

@matthew-dean Poin diambil. Hanya mencoba menggunakan pola yang ada. Mengubah permintaan saya, apakah itu:

<strong i="6">@function</strong> halfway-between(<strong i="7">@large</strong>, @small) {
    max(<strong i="8">@large</strong>, @small) - (abs(<strong i="9">@large</strong> - @small) / 2);
}

Tidak khawatir tentang sintaks, tetapi ini akan memungkinkan saya melakukan hal yang tidak dapat saya lakukan saat ini.

Sintaks adalah bagian tersulit untuk diperbaiki. Dan Anda ingin melakukannya dengan benar karena ini adalah fitur bahasa baru.

Saya sedikit waspada terhadap @function sekarang, lebih dari saya ketika diskusi ini aktif di masa lalu, hanya karena @plugin -fungsi yang ditentukan dan fungsi yang ada di Less.js. Dan tanpa pernyataan pengembalian itu tidak terlalu berfungsi-y.

<strong i="9">@expr</strong> square(@x): { <strong i="10">@x</strong> * <strong i="11">@x</strong> };
<strong i="12">@expr</strong> halfway-between(<strong i="13">@large</strong>, @small): {
    max(<strong i="14">@large</strong>, @small) - (abs(<strong i="15">@large</strong> - @small) / 2)
};

Memikirkannya lebih lanjut, saya pikir tugas titik dua : dan titik koma ; terminator lebih logis. Dalam square(@x) itu diberikan nilai ekspresi yang dievaluasi. Ini tampaknya membuatnya lebih sesuai dengan aturan yang terpisah. Tanda kurung kurawal {} menunjukkan bahwa ruang lingkup @x bukanlah lingkup sekitar pernyataan, tetapi apa yang ditetapkan melalui alias ekspresi.

Saya suka konsep ekspresi yang dapat digunakan kembali yang lebih sederhana ini daripada "fungsi" (yang sudah berarti "ditentukan oleh bahasa penguraian" yaitu JavaScript). Jadi @expression atau @expr masuk akal bagi saya di sini. Saya pikir ekspresi yang dapat digunakan kembali memiliki utilitas yang lebih luas dan lebih mudah dipahami.

Saya suka konsep ekspresi yang dapat digunakan kembali yang lebih sederhana ini daripada "fungsi"

Pada dasarnya; mereka adalah ekspansi makro pra-prosesor parametrized seperti di C lama biasa, bukan? Tapi semoga _tanpa_ penyalahgunaan gila yang menyertainya, karena Less akan memiliki fungsi @plugin sebagai alternatif yang jauh lebih layak untuk pengangkatan yang lebih berat dan fungsi kompleks yang sebenarnya.

@rjgotten

alternatif yang jauh lebih layak untuk pengangkatan yang lebih berat dan fungsi kompleks yang sebenarnya.

https://github.com/less/less.js/issues/538#issuecomment -107247753. Meskipun tidak apa-apa.

Dan saya masih keberatan dengan penemuan sintaks khusus yang dikodekan ke contoh "satu liner" tertentu. Masih berbau seperti sindrom "Saya suka menciptakan sintaks baru yang keren".
Lagi pula itu hanya meminta lebih banyak masalah dari sudut pandang implementasi parser ... Misalnya ingat #2785 dan pikirkan betapa ambigunya

{
   foo();
   foo() - bar();
   bar();
}

menjadi sebenarnya. Di sana Anda harus memperkenalkan banyak aturan penguraian baru untuk mendeteksi pernyataan mana yang sebenarnya merupakan fungsi yang mengembalikan nilai dan mana yang hanya panggilan fungsi root (bahkan tidak menghitung pesan kesalahan ramah jika terjadi kesalahan).
Jadi singkatnya, saya pikir semua yang saya tulis di https://github.com/less/less.js/issues/538#issuecomment -107255583 masih berlaku.

Dan ya, menekankan Sassish @at-rule directive lagi - belum pernah di Kurang, jadi mengapa harus sekarang? (Sepertinya seseorang menggunakan PostCSS terlalu banyak baru-baru ini ;).

@seven-fase-max

{
   foo();
   foo() - bar();
   bar();
}

Saya menyiratkan bahwa multi-pernyataan tidak valid di sini (akan mengevaluasi ke satu ekspresi), sehingga tidak akan berlaku, TAPI ....

...menekankan direktif Sassish @at-rule sekali lagi - belum pernah di Less, jadi mengapa harus sekarang? (Sepertinya seseorang menggunakan PostCSS terlalu banyak baru-baru ini ;).

Saya belum pernah menggunakan PostCSS, tapi ya, menulis @function dan @expression membuat saya merasa agak kotor. Seperti yang saya sebutkan ketika masalah ini dikomentari ulang, banyak diskusi sintaksis telah bergerak lebih jauh dari kemungkinan ini. Less hanya tidak memiliki paradigma sintaksis yang cocok untuk ini, karena semuanya bersifat deklaratif. Artinya, bahkan dalam pernyataan pengembalian dalam mixin, kedua pernyataan ini secara wajar akan sama, karena nilai adalah konstanta untuk ruang lingkup (setelah diselesaikan).

.function-sqralpha(@c) {
    <strong i="14">@a</strong>: alpha(@c);
    return <strong i="15">@a</strong> * @a;
}

.function-sqralpha(@c) {
  return <strong i="18">@a</strong> * @a;
  <strong i="19">@a</strong>: alpha(@c);
}

Jadi, bagaimanapun, dengan apa yang dibahas sejauh ini, tampaknya lubang pasak / bundar agak persegi. Saya tidak berpikir mixin dapat berpura-pura menjadi fungsi (tanpa kompromi dan perilaku yang tidak terduga), dan mendefinisikan fungsi (atau ekspresi atau ekspansi makro) melalui Less (yaitu, dalam stylesheet Anda) telah terbukti juga bermasalah.

Pada catatan terpisah-

Satu hal yang mungkin membuat kami lebih condong untuk menutup utas ini: ketika saya melihat kembali melalui komentar, termasuk yang Anda tautkan, Anda menganggap ini bukan cara yang ideal untuk menyelesaikan masalah di atas.

functions.addMultiple({
    sqralpha : function(c) {
        var a = c.alpha; // no docs and no guaranty this internal stays the same, but there's no easy way to reuse built-in Less `alpha()` here
        return new tree.Dimension(a * a); // Dimension? some kind of quantum mechanics?
    }
});

Dengan Less 3.0, saya telah menyederhanakan pengembalian sehingga setiap non-Node (selain nilai falsey) yang dikembalikan oleh suatu fungsi dilemparkan ke Anonymous Node, sehingga mudah dikeluarkan ke CSS akhir Anda. Jelas, jika Anda ingin memasukkan hasil itu ke ekspresi lain, Anda harus eksplisit dalam tipe Node. Buuuuut.... 3.0 juga menyertakan fitur "penguraian terlambat" (semua nilai adalah Anonim hingga direferensikan - ini memungkinkan referensi properti tanpa membuat pekerjaan penguraian tambahan atau simpul tambahan), sehingga dapat digunakan kembali agar menjadi seperti:

functions.addMultiple({
    sqralpha : function(c) {
        var a = c.alpha; // docs have started! doing my best!
        return a * a;     // Cast to Dimension because Less is cool... maybe?
    }
});

Dan mengingat 3.0 harus semua tentang fungsi dan @plugin , dan daftar hal-hal lain yang perlu dirilis... Setidaknya saya akan mengatakan, ini bukan waktu yang tepat untuk fitur ini. Saya melakukan yang terbaik untuk menyederhanakan contoh terbaru, tetapi bahkan dengan itu, keberatan Anda valid, dan saya baik-baik saja untuk menutup untuk saat ini.

@seven-fase-max

538 (komentar). Meskipun tidak apa-apa.

Tidak tidak; Anda meningkatkan poin yang bagus.

Ada overhead yang cukup besar untuk jalan tengah, di mana Anda memiliki lebih dari sekadar ekspresi satu baris yang harus dilakukan, tetapi tidak cukup untuk menjamin menjalankan plugin JS dan menulis kode yang menangani semua pemetaan tipe simpul.

Sementara @matthew-dean mengemukakan poin bagus bahwa tipe pengembalian simpul dapat disimpulkan, itu masih terasa seperti banyak overhead untuk beberapa matematika sederhana atau interpolasi string. (Khususnya yang terakhir; interpolasi string _memerlukan_ variabel sementara, jadi Anda tidak akan pernah bisa menulis ekspresi satu baris untuknya.)

Jika mengerjakan pengembalian yang dapat digunakan ke dalam sintaks adalah masalahnya, lalu mengapa tidak melewatkan pernyataan pengembalian eksplisit sama sekali dengan _menentukan nama apa yang akan diikat oleh variabel keluar_:

.answer(<strong i="12">@a</strong>, @b):<strong i="13">@c</strong> {
  <strong i="14">@c</strong>   : ~"The answer is @{sum}";
  <strong i="15">@sum</strong> : <strong i="16">@a</strong> + @b;
}

Ini terasa alami dengan kemandirian tatanan dan sifat deklaratif dari bahasa Less. Itu juga secara langsung memperluas tanda tangan deklarasi mixin dengan cara yang tidak ambigu, yang dapat dicari oleh parser dan yang menghindari kebutuhan akan kata kunci @expression atau @function atau aturan khusus.

Ini juga berarti dapat bekerja sama dengan overloading mixin dan panggilan multicast. Jika mixin dipanggil seperti fungsi, itu _memerlukan_ bahwa ada deklarasi yang memiliki tanda tangan parameter yang cocok _dan_ parameter keluar yang dipisahkan titik dua yang ditentukan. Dan jika ada beberapa kelebihan yang cocok, nilai yang dikembalikan menjadi daftar panggilan yang relevan dalam urutan deklarasi mixin. (Sama seperti bagaimana beberapa kelebihan yang cocok saat ini mengeluarkan aturan dalam urutan deklarasi.)

Hah. Itu sebenarnya tidak terlalu buruk.

Pertanyaan: apa yang terjadi kemudian dengan properti, nilai, dan variabel lain yang dideklarasikan dalam mixin (jika disebut sebagai fungsi). Aman untuk menganggap mereka terisolasi dari cakupan pemanggil (karena properti tidak dapat dihilangkan di lokasi panggilan, jika panggilan berada dalam ekspresi nilai)?

Itu tidak terlalu buruk. Kami memperluas fungsi untuk dipanggil di mana-mana. Jadi bisa jadi mixin bisa dipanggil di mana-mana dengan pemeriksaan yang sama untuk melihat apakah output node yang dihasilkan legal di lokasi tersebut. Jadi fungsi = JS dan mixin = KURANG.

Saya juga menyukai cara Anda menangani dan menyelesaikan beberapa mixin yang cocok (hasilnya berupa daftar). Cerdik. Dan deklaratif.

Saya sudah siap untuk menyerah pada ide ini tetapi ini benar-benar tidak buruk.

Kami juga dapat memperbarui dokumentasi yang mencampur, secara default, "mengeluarkan" seperangkat aturan, kecuali jika output var (atau vars, atau $properties??) ditentukan.

Apakah sudah ada pembaruan untuk ini?

@distransient Ada lebih banyak diskusi mendalam seputar merancang solusi untuk ini di: https://github.com/less/less-meta/issues/16.

(Less-meta adalah repo untuk perencanaan tujuan tingkat yang lebih tinggi untuk Less.js, daripada masalah individu atau laporan bug.)

Masalah ini secara otomatis ditandai sebagai basi karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut yang terjadi. Terima kasih atas kontribusi Anda.