Not exactly the same but the Closure Compiler has a "runtime type check"
mode that inject type checks. If you write jsdoc type annotations already
this can be an low resistance path but its usefulness depends on the
accuracy of those annotations.
On Aug 21, 2014 6:54 AM, "Curtis Steckel" wrote:
These are all great examples and resources. Thanks everyone.
On Thursday, August 21, 2014, Charles Pick wrote:
> Just to throw another example out there, here's a Design by Contract
> library which squeezes itself within existing ES syntax -
> https://github.com/codemix/contractual
>
___
Just to throw another example out there, here's a Design by Contract
library which squeezes itself within existing ES syntax -
https://github.com/codemix/contractual
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-d
Jonathan Barronville wrote:
+1 for https://research.microsoft.com/pubs/224900/safets.pdf ... some
really good research.
Yes, it's good.
As Mark said, though, it's more likely we'll get a fight than anything
productive from such a conversation, which is quite unfortunate :( .
Best thing alre
sort, whether starting from guards or from either of the approaches
> above.
>
> From discussions at TC39, it is clear that any such proposal would be a
> long fight. I don't know that anyone is willing to invest the time needed
> to lead that fight. I know I'm not -- it is
See also
http://disnetdev.com/blog/2011/08/23/Contracts.coffee-Contracts-For-JavaScript-and-CoffeeScript/
and http://research.microsoft.com/apps/pubs/default.aspx?id=224900
I am a fan of making it notationally easier to inject runtime validation of
some sort, whether starting from guards or from
hp?id=strawman:guards.
**I'm curious what TC39 and the es-discuss' current thoughts and attitudes
towards guards is at the moment.**
They seem to come up every once in a while in TC39 notes, but usually only
through a tangential mention followed by a mix of "that would eliminate the
p
> Aren't you assuming a certain kind of guards, namely converting rather than
> throwing? There's no way to future-proof without more agreement on what the
> default meaning of x :: Number would be, and (AFAIK) we don't have consensus
> yet.
Yes, in the future of
Aren't you assuming a certain kind of guards, namely converting rather than
throwing? There's no way to future-proof without more agreement on what the
default meaning of x :: Number would be, and (AFAIK) we don't have consensus
yet.
Anyway, no one is going to start wri
Once we have type guards, I would expect the JavaScript programming style to
slightly change. Currently, number-valued arguments are implemented like this:
function foo(x) {
x = Number(x);
}
With guards, you would use:
function foo(x :: Number) {
}
It might make sense
On Fri, Oct 14, 2011 at 5:23 AM, Peter Dekkers wrote:
> 1. JsDoc becomes a standard part of Language. This has to be a good
> thing even without using it is as basis for stronger typing: a
> uniform way of documenting code.
> 2. No new language constructs are required.
> 3. Relatively simple to i
2011/10/14 Peter Dekkers
>
> I checked the strawman and it looks nice. However the introduction of
> something like "::" would surely not run on older VM's that don't
> understand that construct. Is that not a perceived problem more in
> general: adding a nice new language constructs that people
On Fri, Oct 14, 2011 at 7:44 AM, Peter Dekkers wrote:
> Focus seems to be much on JsDoc, while I just meant it as an example.
> Didn't realize the sensitive nature of bringing up that documentation
> convention, sorry for that.
>
> I checked the strawman and it looks nice. However the introducti
the former -- contracts
>>>
>>> Contracts are not necessarily static. In many languages they are dynamic.
>>> The disnetdev.com/contracts.coffee/ work is a case in point.
>>>
>>
>> That's true. We've discussed contracts.coffee in the guar
is not a statically typed language, it's an overtly dynamic
>> language with prototypical OO. Using it as the former -- contracts
>>
>> Contracts are not necessarily static. In many languages they are dynamic.
>> The disnetdev.com/contracts.coffee/ work is a case in point.
&
2011/10/14 Jake Verbaten
>
>
> On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers wrote:
>
> I think the entire proposal based on auto generating gaurds from
> documentation is not that useful. It forces you into a type of
> documentation. I want to choose my documentation, I dont want these choic
pical OO. Using it as the former -- contracts
>
> Contracts are not necessarily static. In many languages they are dynamic.
> The disnetdev.com/contracts.coffee/ work is a case in point.
>
>
That's true. We've discussed contracts.coffee in the guards thread before
too -- whose syntax
On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers wrote:
> True of course that JS is a dynamic language by nature and it is not
> my suggestion/intention to make it more typed. I strongly believe the
> prototype part of JS is one of its main selling points.
>
> However a function expects certain typ
se -- predicates. They're
evaluated at runtime.
The guards strawman is intentionally also runtime-evaluated. In it, a
declaration such as let x :: G = v; cannot be evaluated statically in general.
G is an expression in the language evaluated in the same regime, and in the
order specif
True of course that JS is a dynamic language by nature and it is not
my suggestion/intention to make it more typed. I strongly believe the
prototype part of JS is one of its main selling points.
However a function expects certain type(s) of input parameters in
order to work properly. My suggestion
2011/10/14 Peter Dekkers
> Some of the advantages I could see:
>
> 1. JsDoc becomes a standard part of Language. This has to be a good
> thing even without using it is as basis for stronger typing: a
> uniform way of documenting code.
>
I fail to see why "One True Way" for everything would be a
,
>>
>> I'm new on this list, so please forgive me if this subject has already
>> been discussed in the past (I could't find a reference to that, but
>> perhaps looked in the wrong places) .
>>
>> I saw that some form of type guards are on the ag
Peter Dekkers wrote:
> All,
>
> I'm new on this list, so please forgive me if this subject has already
> been discussed in the past (I could't find a reference to that, but
> perhaps looked in the wrong places) .
>
> I saw that some form of type guards are on the agenda
All,
I'm new on this list, so please forgive me if this subject has already
been discussed in the past (I could't find a reference to that, but
perhaps looked in the wrong places) .
I saw that some form of type guards are on the agenda and was
wondering if anyone looked at using JsDoc
2011/10/13 Brendan Eich
> On Oct 13, 2011, at 3:29 PM, Kris Kowal wrote:
>
> > Your proposal resembles Waldemar’s guards and trademarks.
> >
> > http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
> > http://wiki.ecmascript.org/doku.php?id=strawman:gua
To say a bit more, since we have live strawman proposals for Harmony, these are
on the agenda. It wouldn't be kosher for an implementor to use :: for something
quite different (let's ignore E4X, shall we? ;-), or to add "guards" under
different syntax, without first at least
On Oct 13, 2011, at 3:29 PM, Kris Kowal wrote:
> Your proposal resembles Waldemar’s guards and trademarks.
>
> http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
> http://wiki.ecmascript.org/doku.php?id=strawman:guards
>
> You might consider building on these t
lationships --, I'd rather go with a predicate functions, but then that's
> even more expensive.
Quildreen,
Your proposal resembles Waldemar’s guards and trademarks.
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
http://wiki.ecmascript.org/doku.php?id=strawman:guar
hmayer
> Similar to the minimal classes idea: Is there a sweet spot between nothing
> at all and full-blown type guards that would have a chance to make it into
> ES.next?
>
> The minimal useful feature set that I can think of:
> 1. instanceof checks: is an argument an instance of
Similar to the minimal classes idea: Is there a sweet spot between nothing at
all and full-blown type guards that would have a chance to make it into ES.next?
The minimal useful feature set that I can think of:
1. instanceof checks: is an argument an instance of a given type?
2. property name
ument that is a string
>>>> and returns an integer. Perhaps MyType has to be an object with two
>>>> function properties named alpha and beta.
>>>
>>> Exactly! Some in TC39 want to research contract systems for JS.
>>
>> This is an altern
MyType is a
>>> can only be a function that takes a single argument that is a string
>>> and returns an integer. Perhaps MyType has to be an object with two
>>> function properties named alpha and beta.
>>
>> Exactly! Some in TC39 want to research contract sys
On Fri, May 27, 2011 at 4:43 PM, Peter Michaux wrote:
> Yes but I was thinking of the use of guards as a debugging/development
> tool. During development you can verify that foo is never called with
> bad values. Then during production, those checks do not need to be
> performed. By
>> Why?
>
> Because foo(7) produces a TypeError in one, and |undefined| in the
> other (assuming that MyType isn't Number).
Yes but I was thinking of the use of guards as a debugging/development
tool. During development you can verify that foo is never called w
On Fri, May 27, 2011 at 4:03 PM, Peter Michaux wrote:
> On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt
> wrote:
>> On Fri, May 27, 2011 at 1:59 PM, Peter Michaux
>> wrote:
>>>
>>> A minifier could, couldn't it?
>>>
>>> function foo(a::MyType) {}
>>>
>>> would be minified to
>>>
>>> func
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt wrote:
> On Fri, May 27, 2011 at 1:59 PM, Peter Michaux wrote:
>>
>> A minifier could, couldn't it?
>>
>> function foo(a::MyType) {}
>>
>> would be minified to
>>
>> function foo(a) {}
>
> These are not the same function at all.
Why?
Peter
_
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux wrote:
>
> A minifier could, couldn't it?
>
> function foo(a::MyType) {}
>
> would be minified to
>
> function foo(a) {}
These are not the same function at all.
--
sam th
sa...@ccs.neu.edu
___
es-discuss m
On Fri, May 27, 2011 at 1:44 AM, Brendan Eich wrote:
> On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
>
> > I'm looking at the strawman for guards.
> >
> > http://wiki.ecmascript.org/doku.php?id=strawman:guards
> >
> > I don't quite see how th
On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
> I'm looking at the strawman for guards.
>
> http://wiki.ecmascript.org/doku.php?id=strawman:guards
>
> I don't quite see how they are created.
>
> I understand this part about how they would be used
>
>
> Cormac's student Tim will work with
> DaveH to prototype this this summer. Not advanced to Harmony, pending
> more user experience.
How will more user experience be generated? Through a compiler to ES5?
--
The idea of guards in general seems extremely useful and could
potential
I placed guards and trademarks on the agenda for this month's meeting. They're
intentionally a relatively bare-bones and secure mechanism:
http://wiki.ecmascript.org/doku.php?id=strawman:guards
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
These partially rely on a mec
On 2010-11-22, at 14:33, Brendan Eich wrote:
> Is losing the braces really worth the added complexity?
Perhaps not. Braces are surely as good a way to denote keyword args as any
other flag. It occurred to me that there is no equivalent of object literals
in the languages I know that have keyw
On Nov 22, 2010, at 11:12 AM, Brendan Eich wrote:
>> Would keyword arguments ever be added to JS? Any chance that would
>> influence the choices made here?
>
> Imponderable unless we reserve : in call expressions such as
>
> foo(arg1: val1, arg3: val3);
>
> to mean named formal parameter asso
On Nov 22, 2010, at 10:58 AM, P T Withington wrote:
> On 2010-11-22, at 13:13, Brendan Eich wrote:
>
>> That, plus the relative rarity of annotated initialisers (in my best guess
>> -- we can argue about this or try to estimate by adding guards to existing
>> code)
On 2010-11-22, at 13:13, Brendan Eich wrote:
> That, plus the relative rarity of annotated initialisers (in my best guess --
> we can argue about this or try to estimate by adding guards to existing
> code), make me still favor (2).
The idea of guards as "adjectives" (ala
of saying, notation is user interface.
And how! But doubling a colon is not better interface. Especially when that
double-tax hits all declarations, not just object initialisers.
Let's see if I can write down some alternatives and list trade-offs:
0. let typedObj = { foo : 33 } : { f
On Mon, Nov 22, 2010 at 12:37 AM, Peter van der Zee wrote:
>
> Can't the guards proposal be applied to function parameters as well? Or am
> I stepping on land mines there? :)
>
Yes. Please look at the guards strawman. It's in there.
--
On Mon, Nov 22, 2010 at 1:09 AM, Brendan Eich wrote:
> [...] Before reaching in a reactive way for @, let's slow down and consider
> what got us here: over-eager bikeshedding of : instead of "in" [...]
>
That's not what got me here. For me the issue is uniformity of guard syntax
across all conte
; colons are required per property initialiser. There's no need for :: or
> anything else except to avoid a confusing re-use of colon. Which is an issue,
> but :: doesn't exactly address it!
>
>
> As you noted yourself in the other thread, if iterators take on the syntax
need for :: or
> anything else except to avoid a confusing re-use of colon. Which is an
> issue, but :: doesn't exactly address it!
>
>
As you noted yourself in the other thread, if iterators take on the syntax
of `for (var x : y : z)`, the single colon for guards would introduce
am
> Actually, for object literal I'd go for an equal sign (=), but that obviously
> won't fix var declarations where the colon is fine.
We're not changing object initialiser syntax.
> Can't the guards proposal be applied to function parameters as well? Or am I
>
# or @ ...
Actually, for object literal I'd go for an equal sign (=), but that
obviously won't fix var declarations where the colon is fine.
Can't the guards proposal be applied to function parameters as well? Or am I
stepping on land mines there? :) It seems like the same logic coul
On Nov 21, 2010, at 7:52 PM, Mark S. Miller wrote:
> On Sun, Nov 21, 2010 at 7:48 PM, Brendan Eich wrote:
>> The reason I chose "::" over ":" is not for a love of "::". Alternative
>> suggestions appreciated! However, I avoided ":" so that we could guard
>> properties within object literals
>>
IMHO.
>>
>
>
> Since this is a purely bikeshedding issue, I don't need to be too
> embarrassed by posting the first color. How about "@"?
>
If we think of guards as annotations, then this kinda sorta has a precedent
in Java annotations (if you squint hard enou
On Sun, Nov 21, 2010 at 7:48 PM, Brendan Eich wrote:
> :: is strictly less pleasant, and really kind of "taken" due to the
> precedents I cited. The "less pleasant" point is the big one IMHO.
>
Since this is a purely bikeshedding issue, I don't need to be too
embarrassed by posting the first co
new for syntax is confusingly similar to
>> long-standing future-proofing intentions around runtime type annotations
>> (aka guards or contracts).
>>
>> (BTW, I don't think :: is a good type annotation or guard punctuator, btw
>> -- it's the C++ namespace qual
tentions around runtime type annotations (aka
> guards or contracts).
>
> (BTW, I don't think :: is a good type annotation or guard punctuator, btw --
> it's the C++ namespace qualification operator, also specified for namespacing
> by ECMA-357 (E4X) and used that way i
On Sun, Nov 21, 2010 at 7:05 PM, Brendan Eich wrote:
> On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
> [...]
> Worse, the use of colon in this new for syntax is confusingly similar to
> long-standing future-proofing intentions around runtime type annotations
> (aka guar
58 matches
Mail list logo
