Re: Ideas on type hinting and named parameters
Why can't we use proxy or a new global object call StrictType, or a new
property call definePropertiesType on the global Object
Than we could use the syntax style of the language :
Object.definePropertiesType(object,{
age:{type:Number},
name:{type:String},
height:{type:Float}
});
All of these additional feature will make the language hard to learn. Adding
on these new syntax in hope to please other comming from other programming
language. No matter what it'll never be 100% familiar to others that's come
from different languages. It becoming bulky in my opinion Pretty soon will
be in the same boat as w3c.
...it's almost like who every can make the most specific, understandable,
detail proposal will get the feature included in the language.
JS4Lf
On Jun 9, 2015, at 4:57 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
quick personal thoughts on this matter, leaving the named arguments part
beside (as it is looks kinda redundant/unnecessary effort that could wait)
We've been talking about types for long time in here and the good old
direction was *binary data* in the form of `StructType`
```js
const Point2D = new StructType({x:uint32, y:uint32});
let xy = new Point2D({
x: 0,
y: 0
});
```
Not only this option looks and feel more consistent with typed options we
have already in core such `Int32Array` and others, but it will be way easier
to gracefully migrate to such new pattern and fully, or partially, polyfill
for older engines.
Back to typed Array, I think this:
```js
var xyz = new Int32Array([1, 2, 3]);
```
is better than:
```js
var xyz = [
int32 = 1,
int32 = 2,
int32 = 3
];
```
or whatever repeated operation we could have per each `xyz` like variable of
that kind, so whatever would eventually work as StructType might be in my
opinion more suitable.
1. you recognize upfront what kind of duck you are working with
2. you define such type once instead of each time, reducing errors/typos
3. when you pass data around you can specify as example just `Point2D`
instead of `ArrayT Int32` and friends that are imo not so nice to have in a
scripting language
4. we have already tools capable of bringing in types in similar fashion
you proposed ... how about we do something better than some syntax tools
friendly, instead of some syntax optimized for developers?
Moreover about classes, you have defined properties that AFAIK are not
allowed by current specs. ES6 classes accepts only methods and/or getters and
setters so I'm not sure properties should be discussed together with types,
maybe worth waiting for better understanding on how properties will be?
That being said, I see why you used space instead of colon, and for literal
objects that indeed looks like a better approach.
Best Regards
On Tue, Jun 9, 2015 at 5:19 AM, Luke Scott l...@webconnex.com wrote:
Hello All,
I wanted to share some ideas with you for type hinting:
https://github.com/lukescott/es-type-hinting
I’m also putting this together for named parameters:
https://github.com/lukescott/es-named-arguments
The two are somewhat related. The type hinting doc uses white-space instead
of a colon. And in the named-arguments doc a colon is used for named
arguments.
I realize that there may be some strong opinions on a colon vs white-space.
Using white-space instead is an attempt to be compatible with existing ES
syntax (POJO uses colon already), while allowing for other new features,
such as named parameters.
Looking for feedback and any interest on any of the above.
Luke
___
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
Re: Label statement moveable
Please excuse me, I'm trying to move one email to another. Posting this to
clear up confusion.
JS4Lf
On May 20, 2015, at 1:46 PM, Emanuel Allen emanuelal...@hotmail.com wrote:
Yes:
foo: {
// ...
if (bar)
continue foo // (currently a SyntaxError)
// ...
}
in my first attempt at posting this I did something similar:
function foo(v){
return v + 1;
}
var i = 0;
baz:{
i += 1;
}
continue baz;//same as foo(i);
console.log(i);
But not that I want restriction on where continue can be use; only in block
scope. Rather that's in an if/else else if statement or a function statement.
And another important thing is I want label statement reachable from the
scope they are define.
So my first attempt example would actually be rewritten to:
var i;
foo:{
if(typeof i!=='number') break;
i+=1;
}
I =0;
{
if (i 5);
continue foo;
}
console.log(i);//log 4
Again the true aim for this is to lower function calls.
JS4Lf
On May 20, 2015, at 11:56 AM, Claude Pache claude.pa...@gmail.com wrote:
I occasionally (quite rarely) use the following variant of the classical
`do/while(false)` trick:
``
foo: do {
// ...
if (bar)
continue foo // meaning: restart from foo
// ...
break
} while (true) // not a real loop, just a hack
```
Maybe the following syntax could be used?
```
foo: {
// ...
if (bar)
continue foo // (currently a SyntaxError)
// ...
}
```
WDYT?
—Claude
Le 20 mai 2015 à 12:45, Sebastian McKenzie seb...@gmail.com a écrit :
So you want to add goto to JavaScript?
On Wed, May 20, 2015 at 11:42 AM, Emanuel Allen emanuelal...@hotmail.com
wrote:
Clarify:
My previous post was not that clear. That post display what I would like
to do in the language. Here is the actual code if I choose to do it as the
language is now:
var i = 0, n = 5;
l2: do {
i += 1;
l3: do {
if (in) continue l2;
else break l3;
} while (true);
break l2;
} while (true);
//just log the value n+1:
console.log('i:'+i);
loop through label l2 n amount of times before breaking.
This could be useful to escape function invocation cost, if it could be
simply express:
l2: {
i += 1;
}
l3: {
if (in) continue l2;
}
The function way is to:
function l2(){
i += 1;
}
l3: do {
if (in) l2();
else break l3;
} while (true);
I did a a href=http://jsperf.com/block-scope-vs-function-invocation;
jsprf /ato further my argument for a sudo goto/function effect:
http://jsperf.com/block-scope-vs-function-invocation
JS4Lf
On May 19, 2015, at 2:45 PM, L4L lv2lrn...@gmail.com wrote:
Since we have block scope, and we have continue statement to which we can
use in loops to jump back to the conduction statement part.
Than can we consider making label stamens moveable by its name.
I'll like to say that the side effect would be sudo(pseudo) function,
example:
function foo(v){
return v + 1;
}
var i = 0;
baz:{
i += 1;
}
continue baz;//same as foo(i);
console.log(i);
Note that I said sudo function. Its mobility is what of value; depending
on how JavaScript handle the continue statement in a loop to transport
that effect out side a loop.
Stripping this privilege to black scope; where the continue statement is
expanded to work only in block scope and nested block scope; to where it
can only jump to the beginning of that block or any other block scope
that is scoped to that outer block scope but not nested block scope with
in the scope... Like function.
Continue and break statement could be of more power; where we can avoid
some function call in speed matter application.
Excuse any grammar errors.
JS4Lf
___
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
Label statement moveable
Since we have block scope, and we have continue statement to which we can use
in loops to jump back to the conduction statement part.
Than can we consider making label stamens moveable by its name.
I'll like to say that the side effect would be sudo(pseudo) function, example:
function foo(v){
return v + 1;
}
var i = 0;
baz:{
i += 1;
}
continue baz;//same as foo(i);
console.log(i);
Note that I said sudo function. Its mobility is what of value; depending on how
JavaScript handle the continue statement in a loop to transport that effect out
side a loop.
Stripping this privilege to black scope; where the continue statement is
expanded to work only in block scope and nested block scope; to where it can
only jump to the beginning of that block or any other block scope that is
scoped to that outer block scope but not nested block scope with in the
scope... Like function.
Continue and break statement could be of more power; where we can avoid some
function call in speed matter application.
Excuse any grammar errors.
JS4Lf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
