Closed pepkin88 closed 5 years ago
If this were rhendric/LiveScript, I would consider doing this. But having ^
as an alias for **
was advertised by gkz as one of the earliest changes differentiating LiveScript from Coco. He's seen fit to remove features from that era, but as a guy who is just stewarding someone else's language, I don't feel right doing so unless there's an obvious flaw in the feature that needs correcting—gkz liked having ^
, and maybe some other early adopters of LiveScript did too, and I'm not going to mess with that on a speculative basis.
future of pseudo-classical inheritance? no, please, lets deprecate classes)
We could ask him, right? Nope? I know he's busy, so I don't know if it's "worthy" enough issue to mention him.
Regarding pseudo-classical inheritance - it's just an example, and you don't need to use any inheritance related features to make use of private fields. Classes can be used without inheritance.
I do think, if I were to get only one get-a-gkz-opinion-free card, I would definitely use it on some other issue than this one. But as far as I know that isn't the case, and I haven't really tried summoning him since he gave me collab bits, so suuure, why not I guess? Let's see if he feels like weighing in!
<stands before mirror> gkz, gkz, @gkz?
@pepkin88 yeah, i know they can be used without inheritance, but in this case simple {}
can be used, right. i think that the discussion about context is more important than about this deprecation. so okay, lets deprecate ^
and use **
. personally i stopped using ^
a while ago. i think it should become some kind of operator which works with (or mutates) data (object/arrays).
I don't see a point of keeping ^
. Of course we'd need a deprecation period.
Why:
**
, which is now a part of ECMAScript and therefore suits more the JS ecosystem**
is easy, in most of the cases simple search/replace is enough^
could be more useful for other things, especially when it's only 1 character longExamples of future usage of
^
:::
seems to be more popular option)#
, which wouldn't work in LS, for obvious reason. Of course JS class support is required for it.I'm not sure what for and when it will be used, but I think it's better to prepare for it by deprecating it first. The earlier, the better, that's why I think maybe even for v1.6.0. I have prepared code for a PR with a deprecation warning, in case it's needed.
Thoughts?