Re: Ideas on type hinting and named parameters

On 6/10/15 1:46 PM, Mark Miller wrote: On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison > wrote: Instead, the purpose of initializers outside of the constructor are to increase expressivity in a different sense than what I think you meant about constructo

Re: Ideas on type hinting and named parameters

On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison wrote: > > Instead, the purpose of initializers outside of the constructor are to > increase expressivity in a different sense than what I think you meant > about constructor initialization: It allows initialization that isn't based > on logic in the

Re: Ideas on type hinting and named parameters

I will accept any syntax that can pass muster (the weird hybrid between colon and C style I came up with is never getting in :P) btw, I do think having generics/template syntax is useful (at one point I was planning on implementing templates in my transpiler, which is why I support the syntax). At

Re: Ideas on type hinting and named parameters

On 6/9/15 4:01 PM, Kevin Smith wrote: how about introducing a well known concept in JS as `own` ? ```js class Person { static name String: "A person name" own name String: "anonymous" own items Array: [] Let's take a step back and ask: what's the motivation for

Re: Ideas on type hinting and named parameters

Inline replies On Tue, Jun 9, 2015 at 9:01 PM, Kevin Smith wrote: > > > Let's take a step back and ask: what's the motivation for having these > property declarations and initializers outside of the constructor? > The same motivation of having `static` properties definition in it ... it was jus

Re: Ideas on type hinting and named parameters

> > how about introducing a well known concept in JS as `own` ? > > ```js > class Person { > static name String: "A person name" > own name String: "anonymous" > own items Array: [] > Let's take a step back and ask: what's the motivation for having these property declarations and initialize

Re: Ideas on type hinting and named parameters

how about introducing a well known concept in JS as `own` ? ```js class Person { static name String: "A person name" own name String: "anonymous" own items Array: [] constructor(name) { if (name) this.name = name; } } var anon = new Person, me = new Person('AG'); anon.items

Re: Ideas on type hinting and named parameters

> > Also static properties are on __proto__, so it seems a bit strange that > instance properties would not also be on .prototype. Somewhat of a > consistency issue I suppose. > Methods declared as "static" in ES6 are defined on the constructor itself. Apparently, "static" data properties in TS ar

Re: Ideas on type hinting and named parameters

On Jun 9, 2015, at 9:23 AM, Kevin Smith mailto:zenpars...@gmail.com>> wrote: Anyway, I'm curious to know why do you think getters and setters are OK and properties are not. I don't see any technical difference, specially considering get/set for lazy property computation/assignment through the

Re: Ideas on type hinting and named parameters

TypeScript was just an example, but being class a different Syntax beast than just prototype (right?) why would that be bad? It will be indeed not-unexpected as Kevin mentioned later on. Using classes thinking prototypes feel something developers won't do (specially new comers) so TypeScript behav

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 t

Re: Ideas on type hinting and named parameters

> > Syntax for putting properties on the prototype was long-ago rejected > because of footgun potential. > Correction: *data* properties. : ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Ideas on type hinting and named parameters

> > Anyway, I'm curious to know why do you think getters and setters are OK > and properties are not. I don't see any technical difference, specially > considering get/set for lazy property computation/assignment through the > prototype getter anyway. > Syntax for putting properties on the prototy

Re: Ideas on type hinting and named parameters

On Tue, Jun 9, 2015 at 9:13 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Mark, properties on the prototype are in TypeScript, and probably every > other OOP based language. Defaults can be easily defined as such, i.e. > > ```js > class Person { name = 'anonymous'; age = 0; } > ```

Re: Ideas on type hinting and named parameters

Mark, properties on the prototype are in TypeScript, and probably every other OOP based language. Defaults can be easily defined as such, i.e. ```js class Person { name = 'anonymous'; age = 0; } ``` Not only, defaults could be optimized upfront by parsers without needing to infer or do extra anal

Re: Ideas on type hinting and named parameters

On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott wrote: [...] > It currently uses `=` to define properties. And there is some debate > whether or not properties should be initialized in the constructor or be on > the prototype. > There is no debate about whether per-instance state (of whatever form)

Re: Ideas on type hinting and named parameters

On Jun 9, 2015, at 1:57 AM, Andrea Giammarchi mailto: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

Re: Ideas on type hinting and named parameters

> On Jun 9, 2015, at 1:21 AM, Thaddee Tyl wrote: > > I like that syntax. > > I wonder about the runtime semantics of it, though. (I know TypeHint > is a TODO, but…) > Is there any implication at runtime of a function that returns a String? > Is this: > > ```js > var point = { > x Number, > y

Re: Ideas on type hinting and named parameters

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 = n

Re: Ideas on type hinting and named parameters

I like that syntax. I wonder about the runtime semantics of it, though. (I know TypeHint is a TODO, but…) Is there any implication at runtime of a function that returns a String? Is this: ```js var point = { x Number, y Number }; ``` … the same as this? ```js var point = { x: Number(),

Ideas on type hinting and named parameters

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