4 ms·
Types in Javascript? Blasphemy! :) Jokes aside, you could easily write a preprocessor to do that. If the syntax you want is along the lines of keyword ident
by lhorie 16y ago
Types in Javascript? Blasphemy! :)
Jokes aside, you could easily write a preprocessor to do that. If the syntax you want is along the lines of
keyword identifier { body }
keyword identifier
it's just a matter of matching tokens, counting brackets and then replacing forms.
With that being said, the examples sounds like making busy-work for yourself. The "module" would still suffer from monkeypatching-related collisions (e.g. think document.getElementsByClassName in old versions of Prototype.js).
Also, javascript has both statements and expressions, so hypothetical macro-enhanced code like this
var a = module A {}
would break depending on what "module" expands to.
- andreyf 16y agoThe "module" would still suffer from monkeypatching-related collisions (e.g. think document.getElementsByClassName in old versions of Prototype.js). I'm not sure what you mean. I'm thinking you would annotate the beginning of foo.xjs (extended JavaScript) with /*macros: modules.jsm*/ Then run the preprocessor, which will generate foo.js - a plain old JavaScript file. The `s' in `defs' stands for "statement", so your example would throw the same error as "var a = if (x==4) ..." var a = module A {} ^ error: expected expression
- thwarted 16y ago/*macros: modules.jsm*/ Whenever I see stuff intended for non-human consumption (doc-comments don't count, because they are just a standardization of a format so they can be more easily consumed by humans, and things like vim modelines don't count because they are not intended to change the meaning of the rest of the file) inside comment markers, I'm reminded of this old JWZ rant about the CDDB format http://www.jwz.org/doc/cddb.html http://www.jwz.org/doc/cddb.html
- 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 :)
- cracki 16y agocounting brackets will get you in trouble if you have to read over strings. there's no way around a real tokenization.
- lhorie 16y agoCrap, you're right. I completely forgot about strings and regexps (and E4X, for that matter) when I wrote that.