3 ms·
>> The "module" would still suffer from monkeypatching-related collisions I mean that the module implementation will be a leaky abstraction because I can still
by lhorie 16y ago
>> The "module" would still suffer from monkeypatching-related collisions
I mean that the module implementation will be a leaky abstraction because I can still do something like "Object.prototype.boom = true" inside a module and cause widespread brokenness. This encapsulation/robustness problem isn't something a simple macro can fix very easily, unfortunately, so both the module proposal that you linked to and your macro proposal sound like using a hammer as a screwdriver for that particular problem.
>> The `s' in `defs' stands for "statement"
Ah, that clears things up. I'd prefer something like a "defexpression" though, which would allow
var a = module A {}
On a side note, var a = if (blah) would be cool to see too (well actually, I'd be more interested in var a = for(blah) ).
- andreyf 16y agoAh, that clears things up. I'd prefer something like a "defexpression" though, which would allow defexpression makes sense, too (but I'd call it `defe' - the more often you use something, the shorter it should be). For some reason, I had the intuition that it would be easier to add statements than expressions, but I don't see why it can't be as simple, as long as they start with some kind of unique token that can be considered a reserved keyword when parsing.
- lhorie 16y ago>> but I'd call it `defe' - the more often you use something, the shorter it should be I was going to write that, but I got the feeling you'd wonder what the "e" stood for :)