JsDoc based type guards
Why have this be part of the language? You can write code by contract libraries (I have one : Raynos/contract ). And you can write a javascript to javascript compiler that parses jsDoc comments and generates code that interacts with a code by contract library automatically.
Yes there would be value in having such a compiler but building it into the language is overkill. Not to mention that jsDoc is not a good thing to standardize as it's a port from javaDoc. If we were to do this we should use something designed for javascript.
Regarding the JsDoc, I just mentioned that since it seems to be the most used convention right now why reinvent the wheel. But if there is an better alternative, that would of course also be very welcome (anything in mind ?).
I understand that you can easily write your own JavaScript pre-compiler that does this. But that is true for many things.
From what I have seen on the whole class proposal for ES.next, I guess
even that could also be done with just a pre-compiler.
But I would assume there would be some advantages of making this part of the language (so standardizing) and thereby achieve a some common best practice among developers. Both a standard for code documentation and some basic assistance in type guarding.
, Peter
2011/10/14 Peter Dekkers <peter at jbaron.com>
Some of the advantages I could see:
- 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 good thing. It's true that this aids community grow, but the JS dev community is already too heterogeneous for that to work. See the endless discussions about "Yay! Semicolons" vs "Yay! ASI", braces, indentation style, documentation style, object definition style, etc, etc, etc.
- No new language constructs are required.
That doesn't really make it an advantage. Unless the thing happens to be a de-facto standard, which I'd argue it isn't.
I think my major pet-peeve against using strict types for contracts is:
1.) JS is not a statically typed language, it's an overtly dynamic language with prototypical OO. Using it as the former -- contracts as a way of enforcing is-a relationships -- is just ditching the whole language already. For this to really work, we'd need ways to define abstract types, interfaces, etc, etc, etc. Otherwise it's just bothersome with no added benefits.
2.) What you proposed is better delegated to being supported by tooling alone, as Jake mentioned.
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 is just to formalize this a bit in order assist the developer how he should use that function. I guess it could also be done with just tooling. But as long as there is no standard way supported by both tools and libraries used, this won't fly. And I just thought of using the spec as a vehicle to achieve that. But perhaps too much ambition.
Just my 2 cents.
, Peter
On Oct 14, 2011, at 9:25 AM, Quildreen Motta wrote:
I think my major pet-peeve against using strict types for contracts is:
1.) JS 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.
as a way of enforcing is-a relationships -- is just ditching the whole language already. For this to really work, we'd need ways to define abstract types, interfaces, etc, etc, etc. Otherwise it's just bothersome with no added benefits.
As disnetdev.com/contracts.coffee/ shows, contracts do not require static types, in particular abstract interfaces, concrete classes, etc. All they require are pure functions returning true or false -- 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 specified by the strawman, as v (the initial value expression).
2.) What you proposed is better delegated to being supported by tooling alone, as Jake mentioned.
Nevertheless, guards are a strawman because having a single, extensible syntax for contracts, runtime checks, etc., could be useful to enough of the diverse JS community that standardization is worth the costs. We need more experience with this proposal, so I encourage people to implement it with a transpiler and experiment.
On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers <peter at jbaron.com> 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 type(s) of input parameters in order to work properly. My suggestion is just to formalize this a bit in order assist the developer how he should use that function. I guess it could also be done with just tooling. But as long as there is no standard way supported by both tools and libraries used, this won't fly. And I just thought of using the spec as a vehicle to achieve that. But perhaps too much ambition.
The standard way to do this is to create the tool then use it.
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 choices forced onto me.
However having a mechanism of syntax to deal with gaurding can be done. And there is a strawman on that. As brendan mentioned, there is more experimenting to do with that strawman.
2011/10/14 Brendan Eich <brendan at mozilla.com>
On Oct 14, 2011, at 9:25 AM, Quildreen Motta wrote:
I think my major pet-peeve against using strict types for contracts is:
1.) JS 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.
That's true. We've discussed contracts.coffee in the guards thread before too -- whose syntax I'm particularly keen to, only not in JS. I wasn't saying that contracts must be about static typing though, but that I got the impression that his post was hinting at using a is-a relationship to define contracts for certain functions.
Nevertheless, guards are a strawman because having a single, extensible syntax for contracts, runtime checks, etc., could be useful to enough of the diverse JS community that standardization is worth the costs. We need more experience with this proposal, so I encourage people to implement it with a transpiler and experiment.
Yes, guards are an interesting addition to the language. Not only for type safety (would we also be able to get multiple dispatch on type pattern matching then?), but for documentation. I personally like the optional typing in Dart, even though I'm a static-typing-hater (and the devs have already said they won't support type inference directly in the language), they're valuable as code intention annotations.
2011/10/14 Jake Verbaten <raynos2 at gmail.com>
On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers <peter at jbaron.com> 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 choices forced onto me.
+1
This is what I was trying to get at :3
On Fri, Oct 14, 2011 at 2:59 PM, Quildreen Motta <quildreen at gmail.com>wrote:
2011/10/14 Brendan Eich <brendan at mozilla.com>
On Oct 14, 2011, at 9:25 AM, Quildreen Motta wrote:
I think my major pet-peeve against using strict types for contracts is:
1.) JS 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.
That's true. We've discussed contracts.coffee in the guards thread before too -- whose syntax I'm particularly keen to, only not in JS. I wasn't saying that contracts must be about static typing though, but that I got the impression that his post was hinting at using a is-a relationship to define contracts for certain functions.
Nevertheless, guards are a strawman because having a single, extensible syntax for contracts, runtime checks, etc., could be useful to enough of the diverse JS community that standardization is worth the costs. We need more experience with this proposal, so I encourage people to implement it with a transpiler and experiment.
Yes, guards are an interesting addition to the language. Not only for type safety (would we also be able to get multiple dispatch on type pattern matching then?), but for documentation. I personally like the optional typing in Dart, even though I'm a static-typing-hater (and the devs have already said they won't support type inference directly in the language), they're valuable as code intention annotations.
This is a very useful construct, I find that not having some kind of annotating on my function parameters makes it hard to read (isolated) code. I've personally started using jsDoc style comments to indicate type which is an ugly solution to this issue. I don't actually want to know the type as much as I want to know what [[Prototype]]'s I expect the parameters to have
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 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 won't use due to the fact that xx% of VM don't support it?
So I believed it to boiled down to is the difference between:
function fn(x :: MyType)
and for example (and again just an example):
function fn(/** MyType */ x)
And for a greenfield language I would always go for the first option, no doubt. But the second option is much less interruptive for an exiting language with a huge installed base like JS while having similar benefits. But again if "documentation-neutral" is that high on most peoples agenda, only option 1 remains.
P.S thanks for all the feedback so far and having patience with a newbie on this list. Always useful and insightful to get a better understanding what other peoples main arguments are when coming to a certain decision.
,Peter
On Fri, Oct 14, 2011 at 7:44 AM, Peter Dekkers <peter at jbaron.com> 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 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 won't use due to the fact that xx% of VM don't support it?
So I believed it to boiled down to is the difference between:
function fn(x :: MyType)
and for example (and again just an example):
function fn(/** MyType */ x)
But I think a bigger problem for JavaScript is the meaning of "MyType".
If you limit types to the things returned by typeof operator, then you can succeed and few will care.
If you try to go beyond 'object', then you wander into a deep set of problems around the meaning of types. Many will care and your chances of success diminish.
jjb
2011/10/14 Peter Dekkers <peter at jbaron.com>
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 won't use due to the fact that xx% of VM don't support it?
Most ES.next proposals are already not compatible with ES5. Why? Because nice syntax matters. It's not just about the semantics, surely semantics are good and all, but considering the lack of flexibility on JS's language syntax for introducing such new functionality in a nice manner, proposing better and usable syntax becomes overtly important. After all, syntax is the primary interface for programmers to express their thoughts, thus, it deserves plenty of thought.
For functionality that should be backwards compatible, the support should come through APIs, frameworks, libraries and tooling. All of which can be already achieved for contracts.
On Fri, Oct 14, 2011 at 5:23 AM, Peter Dekkers <peter at jbaron.com> wrote:
- 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.
- No new language constructs are required.
- Relatively simple to implement (I would assume).
- Even more IDE's will start using this to assist developers with things like code completion.
- Code that uses this mechanism can still run on older VM's that don't support this. They are just normal comments for those VM's.
I agree with these points: I prefer to have a comment-based system because it works today and can be stripped for optimization easily. As you can probably sense, trying to standardize that approach on this list is probably unlikely. Or at least a long road.
What might work better is getting a coordinated effort together to make sure JSDoc (or whatever the comment syntax is, JSDoc is fine though) works well in editors that people use. Creating a communication list/site to hash out the issues/track progress is a good way to go. It is best to lay some groundwork first -- engage the JSDoc folks, work up a plan of attack and make sure there are some people who can make progress on the tasks.
I am not a doer for that set of tasks, but I am interested in following the effort if you do get it set up, and I would like to use this system for my own code. If you go that route, please post back with the details.
You may have already thought of this path, and I do not mean to stifle discussion of the issues on this list. Just trying to point to a route that will likely lead to results in a quicker timeline. Since it seems like the window is closing/closed for the next ES version proposals, spending the time working on the hard issues of getting this type of comment system in the tools used today will set up a better discussion of this approach for the ES version after next.
James
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 as a basis for that.
I noticed that nowadays already some IDE's take advantage of JsDoc to assist the developer in code completion. And this same mechanism could be also used by the JavaScript VM. Running the VM in some kind of development mode, would generate some pre- and post-conditions assertions based on the JsDoc for that particular function. This would aid the developer during his tests.
In normal production mode this additional code would not have be be generated. Much like some systems that support pre- and post-conditions (contracts) use to work. Additional benefit is that it can later be easily extended to more real pre- and post-conditions if ever required (hereby already my vote for at a notNull pre-and post-condition check ;)
Some of the advantages I could see:
, Peter