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
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).
On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison lbljef...@gmail.com 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 6/10/15 1:46 PM, Mark Miller wrote:
On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison lbljef...@gmail.com
mailto:lbljef...@gmail.com wrote:
Instead, the purpose of initializers outside of the constructor
are to increase expressivity in a different sense than what I
think you
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(),
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 =
On Jun 9, 2015, at 1:57 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto: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
On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott l...@webconnex.com 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
On Jun 9, 2015, at 1:21 AM, Thaddee Tyl thaddee@gmail.com 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
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
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
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
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
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; }
```
At
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 prototype
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 are
On Jun 9, 2015, at 9:23 AM, Kevin Smith
zenpars...@gmail.commailto: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
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;
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 initializers outside
Inline replies
On Tue, Jun 9, 2015 at 9:01 PM, Kevin Smith zenpars...@gmail.com 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
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
21 matches
Mail list logo
