Ideas on type hinting and named parameters

L4L lv2lrn4lf at gmail.com
Tue Jun 9 15:35:49 UTC 2015


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.giammarchi at 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 <luke at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/0627cf85/attachment-0001.html>


More information about the es-discuss mailing list