>
>
> 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 }
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
expor
> 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, tha
> 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? Y
2014-06-29 0:58 GMT+02:00 Kevin Smith :
> 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 be thinking
> about expa
On Jun 29, 2014, at 12:50, "Rick Waldron" 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
> positive. It woul
On Sun, Jun 29, 2014 at 12:25 PM, John Barton
wrote:
>
>
>
> On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith 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
>>
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith 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 be thinking
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 wrote:
>
>>> Static checking of imports and exports has well-known advantages and
>>>
Another +1. Would save me doing Math.TAU = 2 * Math.PI; at the top of all
my trignometry files :-)
On 1404030818733, Jonathan Barronville wrote:
> NO! π all the things!
> Just kidding ;) ... +1 adding the τ constant.
>
> - Jonathan
>
>
> On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian
> wrote
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 coul
NO! π all the things!
Just kidding ;) ... +1 adding the τ constant.
- Jonathan
On Sat, Jun 28, 2014 at 9:01 PM, C. Scott Ananian
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.
> --scott
>
>
>
12 matches
Mail list logo
