Re: const VS features detection

2013-12-20 Thread J B 
As far as the compiler is concerned it is only defined once. The
preprocessor strips the second const out before the compilation phase.

Let me correct my earlier statement: "Your C comparison was
apples-to-oranges, #ifdef is evaluated before compilation."


On Fri, Dec 20, 2013 at 1:02 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> many launches --harmony by default with node, many others surf the web on
> the edge. I don't want to tell anyone what to do in order to use a library,
> they know experimental is experimental, and as Developer I would like to be
> able to feature-detect experiments or at least know that I am in an
> experimental Environment.
>
> Once again, this is off-topic here, but Proxy is a very good example for
> this problem, so are generators in older Spidermonkey versions, so are ...
> you name it, avoiding vendor prefixes for not finalized yet stuff is a hell
> of a foot-gun for both specifications and developers ... maybe we don't see
> this as a problem today, even if there are already concrete examples like
> this, but I am sure it will come back soon.
>
>
> On Fri, Dec 20, 2013 at 3:05 AM, Claude Pache wrote:
>
>>
>> Le 20 déc. 2013 à 08:36, Andrea Giammarchi 
>> a écrit :
>>
>> > as side note: in node.js using --harmony flag ... what a developer
>> should do there to understand that a partially non standard version of
>> Proxy is there instead of the real one?
>> >
>> > Let's imagine I am a client/server library author ... just for a
>> second, I'd like to grant one behaviour across platforms ... I'd love V8 to
>> flag experimental features as v8Proxy instead, at least I know what I am
>> dealing with!!! Don't care about multiple checks, as long as I can grant
>> consistency.
>> >
>> > This is a concern of mine that keeps coming up ... off topic here
>> >
>>
>> Surely not the answer you want, but as developer, I would consider the
>> following actions:
>>
>> * Putting a prominent warning in my library doc: Do not use outdated
>> builds with experimental features enabled. It would make babies cry.
>> * Opening a bug against implementations, asking that builds with
>> experimental features enabled must have an expiration date. It may annoy
>> users, but at least, it will prevent kitten from being killed.
>>
>> —Claude
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const VS features detection

2013-12-20 Thread J B 
Your C comparison was apples-to-oranges, #ifdef is evaluated at compile
time.


On Fri, Dec 20, 2013 at 8:32 AM, Andreas Rossberg wrote:

> On 20 December 2013 04:05, Brendan Eich  wrote:
> > Andrea Giammarchi wrote:
> >>
> >> why is this not possible, giving the ability to understand through
> typeof
> >> if there is a value or not?
> >>
> >> ```javascript
> >> // defined as const
> >> // reserved in this scope
> >> // but not assigned yet
> >> const WHATEVER;
> >> if (condition) {
> >>   // first come, first serves
> >>   WHATEVER = 123;
> >>   // that's it! const defined for the whole scope
> >>   // immutable from now on
> >> } else {
> >>   WHATEVER = 456;
> >> }
> >
> >
> > Past JS2/ES4 designs have allowed this, but it requires definite
> assignment
> > analysis and use-before-defining-assignment error checking.
> >
> > In general, such checks can't be static in JS, so the language and VM
> > complexity blow up a bit with runtime checking for an "uninitialized"
> (not
> > same as undefined) sentinel value that must be guarded against by a read
> > barrier where it can't be proven unnecessary.
> >
> > This is pretty obnoxious for implementors, not great for users either
> (did I
> > declare const IMPORTANT; and forget to assign IMPORTANT= in some branch
> of
> > control flow that my tests miss?).
> >
> > It's not in Harmony. We require an initialiser as part of the const
> > declaration syntax. What you are doing here, by many measures, is
> varying a
> > variable from its default (undefined) value to a new value.
> >
> > If you want that variable to stop varying after, and you need it as a
> global
> > (window) object property anyway, use Object.defineProperty to make it
> > non-writable.
> >
> > BTW, the last version your head post gave,
> >
> > const ES6_PROXY = function(){
> >
> >   try {
> > new Proxy({},{});
> > return true;
> >   } catch(o_O) {
> > return false;
> >   }
> > }();
>
> Of course, the problem here is hardly specific to feature detection,
> or const, but simply an instance of the general annoyance induced by
> the old-school statement/expression separation. What you'd really want
> to write is something like
>
>   const ES6_PROXY = try new Proxy({}, {}), true catch (_) false;
>
> For ES7 I would like to revive the do-expression proposal (hopefully
> at the next meeting), so that one can at least approximate the above
> with
>
>   const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false
> } };
>
> Of course, semantically the function is equivalent, and a fine
> solution, if a bit verbose.
>
> /Andreas
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question about reusing object used in Object.defineProperty

2013-09-23 Thread J B 
*oops:

obj.value = 0;
Object.defineProperty(this, 'foo', obj);
obj.value = 1;
Object.defineProperty(this, 'foo2', obj);


On Mon, Sep 23, 2013 at 4:30 PM, J B  wrote:

> *Would the former method help with reducing object allocation (and
> therefore gc), or are there compiler optimizations that will automatically
> make the latter as efficient?
>
>
> On Mon, Sep 23, 2013 at 4:28 PM, J B  wrote:
>
>> var obj = {};
>>
>> Object.defineProperty(this, 'foo', obj.value = 0);
>> Object.defineProperty(this, 'foo2', obj.value = 1);
>>
>> vs.
>>
>> Object.defineProperty(this, 'foo', {value:0});
>> Object.defineProperty(this, 'foo2', {value:1});
>>
>>
>> Would the former method help with reducing object allocation (and
>> therefore gc), or are there compiler optimizations that will automatically
>> make the former as efficient?
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question about reusing object used in Object.defineProperty

2013-09-23 Thread J B 
*Would the former method help with reducing object allocation (and
therefore gc), or are there compiler optimizations that will automatically
make the latter as efficient?


On Mon, Sep 23, 2013 at 4:28 PM, J B  wrote:

> var obj = {};
>
> Object.defineProperty(this, 'foo', obj.value = 0);
> Object.defineProperty(this, 'foo2', obj.value = 1);
>
> vs.
>
> Object.defineProperty(this, 'foo', {value:0});
> Object.defineProperty(this, 'foo2', {value:1});
>
>
> Would the former method help with reducing object allocation (and
> therefore gc), or are there compiler optimizations that will automatically
> make the former as efficient?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Question about reusing object used in Object.defineProperty

2013-09-23 Thread J B 
var obj = {};

Object.defineProperty(this, 'foo', obj.value = 0);
Object.defineProperty(this, 'foo2', obj.value = 1);

vs.

Object.defineProperty(this, 'foo', {value:0});
Object.defineProperty(this, 'foo2', {value:1});


Would the former method help with reducing object allocation (and therefore
gc), or are there compiler optimizations that will automatically make the
former as efficient?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
"That said, note that your sentiment has been graciously heard. What you
are asking for is well-represented by rigorous research going into
TypeScript, which is very closely aligned with work and proposals that came
out of these discussions. I believe it is fair to interpret Brendan’s last
sentiment, “This again puts unsound warning "types" outside of the
standards track for a while. But carry on with TypeScript etc. — TC39 is
tracking”, not as “no”, but as “not yet”."

Thanks Kris, That's all I wanted to know; I don't have anything remaining
to say on the subject.

Thank you.


On Fri, Aug 23, 2013 at 3:39 PM, Kris Kowal  wrote:

> On Fri, Aug 23, 2013 at 1:20 PM, J B  wrote:
>
>> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
>> is depressing.
>>
>
> J B,
>
> You’re entitled to a dissenting opinion. However, this archives one of the
> best moments for the evolution of the language. It was a commitment to
> focus on deliberate, consistent, incremental change. We are realizing the
> rewards for the Harmony agenda today with property descriptors (which
> formalized and exposed an existing concept), new collections, and Proxies.
> The cesura on namespaces have provided an opportunity for much much more
> deliberately designed modules. Innovation has returned and the pace is
> good, neither hasty nor stagnant.
>
> That said, note that your sentiment has been graciously heard. What you
> are asking for is well-represented by rigorous research going into
> TypeScript, which is very closely aligned with work and proposals that came
> out of these discussions. I believe it is fair to interpret Brendan’s last
> sentiment, “This again puts unsound warning "types" outside of the
> standards track for a while. But carry on with TypeScript etc. — TC39 is
> tracking”, not as “no”, but as “not yet”.
>
> Kris Kowal
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
https://brendaneich.com/2007/11/my-media-ajax-keynote/ I liked reading
this...

https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
is depressing.


On Fri, Aug 23, 2013 at 2:50 PM, J B  wrote:

> @Brendan "Those are warnings, but WarnScript was a bad name" --you mean
> the tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
> debugger, for instance, right?
>
>
> On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich  wrote:
>
>> J B wrote:
>>
>>> @Brendan - The typing wouldn't be used at all during run-time. So,
>>> unlike AS3, it wouldn't check if types were valid, and it wouldn't try an
>>> kind of implicit coercion.
>>>
>>>
>> Ok, that's not "typing" (I mean not a type system).
>>
>> "Those are warnings, but WarnScript was a bad name" - me at JSConf.au
>> last November.
>>
>> The unsoundness means you have something that needs strong tool support,
>> not just an error or JS console in which to spew. TypeScript got this right.
>>
>> This again puts unsound warning "types" outside of the standards track
>> for a while. But carry on with TypeScript etc. -- TC39 is tracking.
>>
>> /be
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
@Brendan "Those are warnings, but WarnScript was a bad name" --you mean the
tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
debugger, for instance, right?


On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich  wrote:

> J B wrote:
>
>> @Brendan - The typing wouldn't be used at all during run-time. So, unlike
>> AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
>> implicit coercion.
>>
>>
> Ok, that's not "typing" (I mean not a type system).
>
> "Those are warnings, but WarnScript was a bad name" - me at JSConf.au last
> November.
>
> The unsoundness means you have something that needs strong tool support,
> not just an error or JS console in which to spew. TypeScript got this right.
>
> This again puts unsound warning "types" outside of the standards track for
> a while. But carry on with TypeScript etc. -- TC39 is tracking.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
@Brendan - The typing wouldn't be used at all during run-time. So, unlike
AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
implicit coercion.

@Jeremy - "The implication being that implementors start shipping static
compilers where this parsing/stripping takes place (i.e., as a precursory
step to being interpreted)?"  --You would probably know better than me. I'm
not too sure how the various implementations work, but the idea is to
simply ignore all the special typing code.

"The problem with this statement is that "key features" is open for
interpretation." --You're right in that it's open for interpretation, but I
think we can both agree that there are things that most devs would agree
are key features, and most would not, and there are some where it would be
a coin flip; but, as there is a JS extension called "TypeScript" (the key
feature is in the very name), and there is a section in that list I linked
to dedicated to this key feature, I think it's a bit more important than...
generics... for instance.

"The fact is that devs already are building "large scale" projects using
plain ol' JS" --I prefer to have the option of static typing, because there
are definite benefits that are hard to ignore, especially when it's code
refactoring time. I'm not saying building large scale projects with untyped
code can't be done, or even that loose typing is a bad thing (it's not),
but static typing can often make things a whole hell of a lot easier for
larger projects with large amounts of developers.

"I'd be interested in seeing data that the de facto standard is to use
compile-to-JavaScript languages.  My own experience has been quite the
opposite." --For large scale/professional development? I think it's the
very reason why TypeScript exists, and why Visual Studio supports it. Also,
a description given for TypeScript is [1]: "TypeScript is a language for
application-scale JavaScript development."


[1] http://www.microsoft.com/en-us/download/details.aspx?id=34790




On Fri, Aug 23, 2013 at 2:03 PM, Jeremy Martin  wrote:

> > I mean the parser will strip all of the typing info out before it's
> compiled/interpreted.
>
> The implication being that implementors start shipping static compilers
> where this parsing/stripping takes place (i.e., as a precursory step to
> being interpreted)?
>
> > but it's been made worse by ECMAScript's lack of key features
>
> The problem with this statement is that "key features" is open for
> interpretation.
>
> > if JS was a little more large scale development friendly (like
> TypeScript), devs could just use plain ol' JS
>
> The fact is that devs already are building "large scale" projects using
> plain ol' JS (I myself have worked on JS projects with 100k+ loc without
> feeling the need for static typing).  The same goes for Python, PHP, Ruby,
> etc. - this isn't an attack against static typing, but it's hardly
> necessary for a language to be "friendly" for "large scale development".
>
> > Sure, some would still use language extensions like TypeScript, but at
> least it wouldn't be the defacto standard because of core inadequacies in
> base language.
>
> I'd be interested in seeing data that the de facto standard is to use
> compile-to-JavaScript languages.  My own experience has been quite the
> opposite.
>
>
> On Fri, Aug 23, 2013 at 2:24 PM, J B  wrote:
>
>> @Jeremy: I mean the parser will strip all of the typing info out before
>> it's compiled/interpreted.
>>
>> @Axel: "Evolving a language standard used as broadly as ECMAScript takes
>> time" -- I agree.
>> "You can see TypeScript as exploring future options for ECMAScript." --
>> Wasn't AS3 already doing this?
>> "Guards" -- Looks good...
>> "TypeScript tracks JavaScript very closely, I would not consider it a
>> different language." It's compiled, and it's one of many options available,
>> which presents a problem in that if one code base is written in TypeScript,
>> and another in JavaScript++ will they be compatible? Even if the resulting
>> JS is, devs will be required to learn several variants of JS. It's not that
>> this isn't happening elsewhere (libraries written in Java vs C#), but it's
>> been made worse by ECMAScript's lack of key features, which has caused a
>> good many of these languages to appear, and to be used. My point is, if JS
>> was a little more large scale development friendly (like TypeScript), devs
>> could just use plain ol' JS! Sure, som

Re: Optional Strong Typing

2013-08-23 Thread J B 
Also, unlike other language features, static typing has it's own section in
that list; and they're not all in that section: "Some of the ones listed
below are also statically typed, such as mobl, GWT, JSIL, NS Basic, and
Haxe."

So, yeah, I don't think it qualifies as a "pet feature".

None of this was a problem when plugins were the norm, but now that they
appear to be going away, more and more devs have been transitioning over to
JS for serious development (games, frameworks, engines..), but JS wasn't
ready for this, so all of these other JavaScript like languages crept in to
fill the gaps... That's good, but shouldn't that be a short term solution?
Also, maybe this was part of the reason why ES4 got a little carried away,
but come on, that doesn't mean ECMAScript shouldn't be extended so that it
can also support larger scale development.


On Fri, Aug 23, 2013 at 1:24 PM, J B  wrote:

> @Jeremy: I mean the parser will strip all of the typing info out before
> it's compiled/interpreted.
>
> @Axel: "Evolving a language standard used as broadly as ECMAScript takes
> time" -- I agree.
> "You can see TypeScript as exploring future options for ECMAScript." --
> Wasn't AS3 already doing this?
> "Guards" -- Looks good...
> "TypeScript tracks JavaScript very closely, I would not consider it a
> different language." It's compiled, and it's one of many options available,
> which presents a problem in that if one code base is written in TypeScript,
> and another in JavaScript++ will they be compatible? Even if the resulting
> JS is, devs will be required to learn several variants of JS. It's not that
> this isn't happening elsewhere (libraries written in Java vs C#), but it's
> been made worse by ECMAScript's lack of key features, which has caused a
> good many of these languages to appear, and to be used. My point is, if JS
> was a little more large scale development friendly (like TypeScript), devs
> could just use plain ol' JS! Sure, some would still use language extensions
> like TypeScript, but at least it wouldn't be the defacto standard because
> of core inadequacies in base language.
>
>
> On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:
>
>> I mean it's a parse error that will throw prior to attempting to execute
>> it.  For example, consider:
>>
>> (function() { var foo:String; })
>>
>> This will throw an error, despite the fact that the function hasn't been
>> invoked.  I replied in haste, though... your point is obviously valid for
>> other scenarios.  Nonetheless, as a non-authoritative response, you're
>> going to need an argument far more compelling than I can think of to see
>> static typing seriously considered.
>>
>>
>> On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:
>>
>>> Are you referring to browsers like Chrome that compile the JS first?
>>> Then, yeah, I mean it shouldn't throw an error at compile time.
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin wrote:
>>>
>>>> > var foo:String;
>>>>
>>>> That's already a compile-time error (as opposed to runtime not sure
>>>> if that's what you meant by the interpreter throwing an error).
>>>>
>>>>
>>>> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>>>>
>>>>> And just to be clear, I'm not asking for run-time type checking or
>>>>> coercion; I'm simply asking that the interpreter not to thrown an error
>>>>> when it encounters something like this: var foo:String;
>>>>>
>>>>>
>>>>> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>>>>>
>>>>>> For one, I wouldn't describe strong typing as a "pet feature". Two,
>>>>>> no, as far as I know, most of those languages in that list don't offer
>>>>>> macros or lots of parentheses; and, if they did, then, yeah, maybe it 
>>>>>> does
>>>>>> say something.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>>>>>> dome...@domenicdenicola.com> wrote:
>>>>>>
>>>>>>> In general ECMAScript lacks lots of features. You may well ask why
>>>>>>> it doesn't have any other pet feature, and you can often point to
>>>>>>> compile-to-JS languages that add those. This doesn't imply that the 
>>>>>>>

Re: Optional Strong Typing

2013-08-23 Thread J B 
@Jeremy: I mean the parser will strip all of the typing info out before
it's compiled/interpreted.

@Axel: "Evolving a language standard used as broadly as ECMAScript takes
time" -- I agree.
"You can see TypeScript as exploring future options for ECMAScript." --
Wasn't AS3 already doing this?
"Guards" -- Looks good...
"TypeScript tracks JavaScript very closely, I would not consider it a
different language." It's compiled, and it's one of many options available,
which presents a problem in that if one code base is written in TypeScript,
and another in JavaScript++ will they be compatible? Even if the resulting
JS is, devs will be required to learn several variants of JS. It's not that
this isn't happening elsewhere (libraries written in Java vs C#), but it's
been made worse by ECMAScript's lack of key features, which has caused a
good many of these languages to appear, and to be used. My point is, if JS
was a little more large scale development friendly (like TypeScript), devs
could just use plain ol' JS! Sure, some would still use language extensions
like TypeScript, but at least it wouldn't be the defacto standard because
of core inadequacies in base language.


On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin  wrote:

> I mean it's a parse error that will throw prior to attempting to execute
> it.  For example, consider:
>
> (function() { var foo:String; })
>
> This will throw an error, despite the fact that the function hasn't been
> invoked.  I replied in haste, though... your point is obviously valid for
> other scenarios.  Nonetheless, as a non-authoritative response, you're
> going to need an argument far more compelling than I can think of to see
> static typing seriously considered.
>
>
> On Fri, Aug 23, 2013 at 2:00 PM, J B  wrote:
>
>> Are you referring to browsers like Chrome that compile the JS first?
>> Then, yeah, I mean it shouldn't throw an error at compile time.
>>
>>
>> On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin wrote:
>>
>>> > var foo:String;
>>>
>>> That's already a compile-time error (as opposed to runtime not sure
>>> if that's what you meant by the interpreter throwing an error).
>>>
>>>
>>> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>>>
>>>> And just to be clear, I'm not asking for run-time type checking or
>>>> coercion; I'm simply asking that the interpreter not to thrown an error
>>>> when it encounters something like this: var foo:String;
>>>>
>>>>
>>>> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>>>>
>>>>> For one, I wouldn't describe strong typing as a "pet feature". Two,
>>>>> no, as far as I know, most of those languages in that list don't offer
>>>>> macros or lots of parentheses; and, if they did, then, yeah, maybe it does
>>>>> say something.
>>>>>
>>>>>
>>>>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>>>>> dome...@domenicdenicola.com> wrote:
>>>>>
>>>>>> In general ECMAScript lacks lots of features. You may well ask why it
>>>>>> doesn't have any other pet feature, and you can often point to
>>>>>> compile-to-JS languages that add those. This doesn't imply that the 
>>>>>> feature
>>>>>> should be added to the language.
>>>>>>
>>>>>> Here, let me try:
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> I'm aware of LispyScript, as well as all of these:
>>>>>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>>>>>> .
>>>>>>
>>>>>> But those languages appear to have been created precisely because
>>>>>> ECMAScript lacks features like lots of parentheses or macros. How many of
>>>>>> those languages offer lots of parentheses? I count quite a few... Doesn't
>>>>>> that say something?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> The existence of a feature in other languages does not imply it
>>>>>> should be added to ECMAScript. You'll have to justify better than that 
>>>>>> why
>>>>>> you think strong typing would be valuable to a language that has
>>>>>> historically rejected it. (I'll wait for one of the old timers to chime 
>>>>>> in
>>>>>> about the ES4 days here.)
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
Are you referring to browsers like Chrome that compile the JS first? Then,
yeah, I mean it shouldn't throw an error at compile time.


On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin  wrote:

> > var foo:String;
>
> That's already a compile-time error (as opposed to runtime not sure if
> that's what you meant by the interpreter throwing an error).
>
>
> On Fri, Aug 23, 2013 at 1:56 PM, J B  wrote:
>
>> And just to be clear, I'm not asking for run-time type checking or
>> coercion; I'm simply asking that the interpreter not to thrown an error
>> when it encounters something like this: var foo:String;
>>
>>
>> On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:
>>
>>> For one, I wouldn't describe strong typing as a "pet feature". Two, no,
>>> as far as I know, most of those languages in that list don't offer macros
>>> or lots of parentheses; and, if they did, then, yeah, maybe it does say
>>> something.
>>>
>>>
>>> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
>>> dome...@domenicdenicola.com> wrote:
>>>
>>>> In general ECMAScript lacks lots of features. You may well ask why it
>>>> doesn't have any other pet feature, and you can often point to
>>>> compile-to-JS languages that add those. This doesn't imply that the feature
>>>> should be added to the language.
>>>>
>>>> Here, let me try:
>>>>
>>>> ---
>>>>
>>>> I'm aware of LispyScript, as well as all of these:
>>>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>>>> .
>>>>
>>>> But those languages appear to have been created precisely because
>>>> ECMAScript lacks features like lots of parentheses or macros. How many of
>>>> those languages offer lots of parentheses? I count quite a few... Doesn't
>>>> that say something?
>>>>
>>>> ---
>>>>
>>>> The existence of a feature in other languages does not imply it should
>>>> be added to ECMAScript. You'll have to justify better than that why you
>>>> think strong typing would be valuable to a language that has historically
>>>> rejected it. (I'll wait for one of the old timers to chime in about the ES4
>>>> days here.)
>>>>
>>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
And just to be clear, I'm not asking for run-time type checking or
coercion; I'm simply asking that the interpreter not to thrown an error
when it encounters something like this: var foo:String;


On Fri, Aug 23, 2013 at 12:45 PM, J B  wrote:

> For one, I wouldn't describe strong typing as a "pet feature". Two, no, as
> far as I know, most of those languages in that list don't offer macros or
> lots of parentheses; and, if they did, then, yeah, maybe it does say
> something.
>
>
> On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> In general ECMAScript lacks lots of features. You may well ask why it
>> doesn't have any other pet feature, and you can often point to
>> compile-to-JS languages that add those. This doesn't imply that the feature
>> should be added to the language.
>>
>> Here, let me try:
>>
>> ---
>>
>> I'm aware of LispyScript, as well as all of these:
>> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
>> .
>>
>> But those languages appear to have been created precisely because
>> ECMAScript lacks features like lots of parentheses or macros. How many of
>> those languages offer lots of parentheses? I count quite a few... Doesn't
>> that say something?
>>
>> ---
>>
>> The existence of a feature in other languages does not imply it should be
>> added to ECMAScript. You'll have to justify better than that why you think
>> strong typing would be valuable to a language that has historically
>> rejected it. (I'll wait for one of the old timers to chime in about the ES4
>> days here.)
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
For one, I wouldn't describe strong typing as a "pet feature". Two, no, as
far as I know, most of those languages in that list don't offer macros or
lots of parentheses; and, if they did, then, yeah, maybe it does say
something.


On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> In general ECMAScript lacks lots of features. You may well ask why it
> doesn't have any other pet feature, and you can often point to
> compile-to-JS languages that add those. This doesn't imply that the feature
> should be added to the language.
>
> Here, let me try:
>
> ---
>
> I'm aware of LispyScript, as well as all of these:
> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
> .
>
> But those languages appear to have been created precisely because
> ECMAScript lacks features like lots of parentheses or macros. How many of
> those languages offer lots of parentheses? I count quite a few... Doesn't
> that say something?
>
> ---
>
> The existence of a feature in other languages does not imply it should be
> added to ECMAScript. You'll have to justify better than that why you think
> strong typing would be valuable to a language that has historically
> rejected it. (I'll wait for one of the old timers to chime in about the ES4
> days here.)
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
So the defacto response for large scale JS development will always be: Use
X?


On Fri, Aug 23, 2013 at 12:35 PM, Jeremy Martin  wrote:

> I haven't personally used it, but you may find that TypeScript provides
> what you're looking for: http://www.typescriptlang.org/
>
>
> On Fri, Aug 23, 2013 at 1:26 PM, J B  wrote:
>
>> Is there any particular reason my JS doesn't support (optional) AS3 style
>> strong typing? All the typing info would be ignored at run-time, but it
>> would be helpful for compile-time checking, code hinting, and general
>> readability of code. Tools like the closure compiler could even strip out
>> all the typing info, and it wouldn't make any difference at run-time. I'm
>> probably beating a dead horse here, but why?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Strong Typing

2013-08-23 Thread J B 
I'm aware of TypeScript, as well as all of these:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

But those languages appear to have been created precisely because
ECMAScript lacks features like typing. How many of those languages offer
strong typing? I count quite a few... Doesn't that say something?



On Fri, Aug 23, 2013 at 12:29 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> You may be interested in [TypeScript](http://typescript.codeplex.com/).
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Optional Strong Typing

2013-08-23 Thread J B 
Is there any particular reason my JS doesn't support (optional) AS3 style
strong typing? All the typing info would be ignored at run-time, but it
would be helpful for compile-time checking, code hinting, and general
readability of code. Tools like the closure compiler could even strip out
all the typing info, and it wouldn't make any difference at run-time. I'm
probably beating a dead horse here, but why?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __proto__ : Spec & web compatibility

2013-08-21 Thread J B 
I recently wrote a AS3 to JS transcompiler that relies quite heavily on
__proto__. The outputted JS works perfectly in both Chrome (SVG SUPPORT IS
HORRIBLE, sorry, unrelated) and Firefox, and maybe even IE11 --I need to
verify. Anyway, for projects like mine, it's very important that IE matches
the same functionality as the other browsers --even if it's not up to spec.

Also, if it wasn't for __proto__, I don't think I could have supported the
entire AS3 spec... so, no hating on __proto__ =)


On Wed, Aug 21, 2013 at 7:44 PM, Brendan Eich  wrote:

> I implemented __proto__ ages ago and it caught on like a non-lethal social
> disease, and that's how it works. The way it works ought to be how Annex B
> specifies it.
>
> /be
>
> Suresh Jayabalan wrote:
>
>>
>> According to sections B.3.1 > 7Ejorendorff/es6-draft.html#**sec-B.3.1>#6.a
>> and 16.1.1.1.2 > **sec-16.1.1.1.2>#3,
>> implementations are expected to throw a TypeError exception if an object’s
>> __proto__ is set with anything other than null or an object. Today the
>> existing implementations (Chrome or Firefox) treat such assignments as a no
>> op.
>>
>> Interestingly there are instances of web pages who assign /undefined/ to
>> an objects __proto__ are found. For example yelp.com <
>> http://www.yelp.com/biz/**potbelly-sandwich-shop-**seattle-4>
>> assigns undefined to __proto__ via a function call as follows.
>>
>> function(f) { return { __proto__:f } }
>>
>> Implementing as per the specification would break the zoom in/out
>> functionality of Yelp as this function would throw a TypeError. Similarly a
>> radio player on myspace.com  would not work either.
>> The fact that there are few instances we have seen in the wild would mean
>> there could be more websites that could break.
>>
>>
>> Is the v8/spidermonkey behavior of silently ignoring primitive
>> assignments to __proto__ a bug? Or should the spec mandate silently
>> ignoring assignments of primitives (or just undefined) to __proto__?
>>
>> - Suresh
>>
>> __**_
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss
>>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss