for some reason my previous post appears to have get lost. so let me say again that the one reason to remove require.extensions that i fully dig is: it's global. meaning that #1 you can't have, say, one package written in coffeescript use one version of that language and another package use another version of that language, as long as they share extensions. likewise, when loading a certain module introduces a new extension `.foo`, then that might clash with the semantics of `.foo` files in another package. all these conflicts are fine and to be expected, but they can not be solved using a global require.extensions.
let me again say that i am all for using languages that transpile to javascript, and i am all for the renewed interest for homegrown languages—it is exciting to see that! i find the often-aired disgust at distributing modules in languages other than javascript a bit narrow-minded. after all, one great thing about having an interpreted / a scripting language is that—and this is an important point!—you do not have to 'compile' anything in the traditional meaning of the word, and also that you have a vm with known properties; this means that you can (1) program in a platform-independent way, (2) keep the semantics of your code open for everyone to read. in the C world, the code you write is pretty remote from the code you execute, and the code you execute (the 'binaries', aptly called so for their being 'unintelligible' to the average human programmer) is devoid of all the names and the higher-level constructs that the programmer introduced. javascript, perl, python—these languages are great because they literally 'execute what you wrote'. when people choose coffeescript over javascript, they might do so because they see value in the clarity of its syntax (i certainly do). i certainly believe that a transpiling language should strive to retain that clarity (readability) as much as possible when producing their javascript target. still, i do not want to bother about that representation of my code too much, and having it done invisibly, on the fly, in memory is just fine for me. nodejs is a very young community, and it has so far never failed to amaze me how people in this community arrive at very sensible, pragmatic, and open-minded solutions and conventions that empower people rather than putting them on a very narrow track (java comes to mind). so lest this thread veers off to shouting 'just compile before you publish' and discussing obfuscation techniques, let us rather discus: given that it is a good thing that new languages are sprouting up—languages that may be beneficial in their expressiveness for computing at large and getting stuff done; given that this expressiveness is there for humans to read; given that this expressiveness can always be verified / inspected / reasoned about in a unified way when needed—by explicit translation into the known entity that is javascript; given that it has been shown that it is feasible and of utility to have the translation be done transparently, in the background; given that, quite possibly, for many in the transpiling community the blunt call to 'compile before you publish' is, at best, problematic and, at worst, exclusivist; given that require.extensions is problematic for being a global: what conventions / best practices / techniques can we come up that will allow us to 'publish in my language, run as javascript' the day that require.extensions is gone? i envision that i will put a standardized, constant index.js in each of my module folders that will do the bootstrap transpiling business quite transparently. but i'm not sure what do to when i just want to require a single sub-module (say, `require 'timezones/berlin.coffee'` as a stupid example). -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
