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 `Array<T 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

Reply via email to