NO! π all the things!
Just kidding ;) ... +1 adding the τ constant.
- Jonathan
On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
I'll admit to being a pi-ist, rather than a tau-ist, but I don't object to
adding Math.TAU. It's a fairly harmless easter egg.
I think that a possible compromise that can still make the ES6 module
system more compatible with both AMD and CommonJS modules is by this:
If there are no exports from a module, named or not, make the export
process implementation-defined. If an ES5 Node module uses module.exports,
then Node
Another +1. Would save me doing Math.TAU = 2 * Math.PI; at the top of all
my trignometry files :-)
On 1404030818733, Jonathan Barronville jonat...@belairlabs.com wrote:
NO! π all the things!
Just kidding ;) ... +1 adding the τ constant.
- Jonathan
On Sat, Jun 28, 2014 at 9:01 PM, C. Scott
Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively. I want the case for the module system to be as strong
as possible.
On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking of imports and exports has well-known
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith zenpars...@gmail.com wrote:
Static checking will be limited anyway. If you want to go this way you
should use typescript.
That's the point that I'm trying to make, shops will choose other
languages that provide more static information. We should
On Jun 29, 2014, at 12:50, Rick Waldron waldron.r...@gmail.com wrote:
Static analysis would be necessary if JavaScript ever wanted to make macros
possible in modules. I don't have exact numbers nor have I done any formal
surveys, but the general response to Sweet.js has been overwhelmingly
CommonJS falls a bit short on the import side because static analysis of
require calls is brittle. A special language syntax would enable a robust
static analysis of dependencies.
If you don't have static exports, then how are you going to know if what
you import is valid? You can't,
Static checking will be limited anyway. If you want to go this way you shoud
use typescript.
If you don't want static checking you should stick with ES3. Fixed that for you.
Yes big projects are possible with JS, I work on them everyday. It
would be nice if the language made them easier,
Bruno and John's arguments are classic examples of the straw man fallacy.
In my concrete examples I made no reference to static type systems (or any
type systems at all, for that matter). I merely pointed out that by
allowing the programmer to provide compile-time information in the form of
I'd be interested in knowing if it's possible that instead of changing
the ModuleImport form the default import/export idea could be
postponed instead.
It can. Just to be clear, that means that we'd have these two forms on the
import side:
module FS from fs;
import { stat } from
10 matches
Mail list logo
