On Jul 12, 2015, at 2:48 AM, Benjamin Gruenbaum
benjami...@gmail.commailto:benjami...@gmail.com wrote:
I think my original post might have been confusing so allow me to clarify.
I'm not suggesting to add named parameters to the language, I did not intend to
start a discussion about named
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 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
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
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
On Mar 5, 2015, at 9:20 AM, Kevin Smith zenpars...@gmail.com wrote:
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
On Feb 19, 2015, at 9:23 AM, David Bruant bruan...@gmail.com wrote:
Hi,
Half a million times the following meta-exchange happened on es-discuss:
- if an attacker modifies Object.prototype, then you're doomed in all sorts
of ways
- Don't let anyone modify it. Just do
.
Best Regards
On Thu, Feb 12, 2015 at 6:32 PM, Luke Scott l...@cywh.com
mailto:l...@cywh.com wrote:
I would agree with that. I had a trait implementation that used classes as
traits, and it caused a lot of problems, especially since classes have
constructors. Traits should not have
On Feb 12, 2015, at 12:11 PM, Domenic Denicola d...@domenic.me wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Benjamin Gruenbaum
We have `Object.assign` that works fantastically for most classic trait use
cases.
Well, actually, it works extremely
On Feb 12, 2015, at 1:13 PM, Peter Seliger peter.seli...@googlemail.com
wrote:
As for JavaScript, I strongly believe, Role based composition patterns
like Mixins or Traits should be function based.
I assume by this you mean that it shouldn’t be a construct and any special
keywords. If
about extends keyword and use mixin
instead for everything, right?
From: Alex Russell mailto:slightly...@google.com
Sent: 12/02/2015 20:05
To: Andrea Giammarchi mailto:andrea.giammar...@gmail.com
Cc: Luke Scott mailto:l...@cywh.com; es-discuss@mozilla.org
mailto:es-discuss@mozilla.org
should be able to work and enrich any sort of class, not just some
specific one it has no notion about.
3. before everything else, since these should be stand-alone behaviors
unrelated with constructors
All marked as IMO, of course :-)
On Thu, Feb 12, 2015 at 9:33 PM, Luke Scott l
On Feb 12, 2015, at 8:35 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Without going down full specification/implementation details, does anyone
believe that classes should/could be used, in the future, as traits/mixins
too?
I find that an anty pattern.
I think traits
a TypeError exception.
From my reading of the spec, I think the idiomatic Foo.call(this) pattern
that Luke Scott described would work if we simply changed that line to
something slightly weaker:
2. If F’s [[FunctionKind]] internal slot
https://people.mozilla.org/~jorendorff/es6-draft.html#sec
On Feb 5, 2015, at 9:07 PM, Kevin Smith zenpars...@gmail.com wrote:
Hopefully I’m wrong in that Foo.call(this) is illegal, but if it is, this is
a devastating change, especially when traits are scheduled for ES7 or later.
Class constructors will now throw when called.
The changes to
I know traits are not something that will make it into ES6. This was the
suggested alternative on the mailing list:
class Thing extends mixin(Base, Trait1, Trait2) {...}
Unfortuantly since rev32 this is now seems impossible, as a custom
implementation of traits would need to this to work:
16 matches
Mail list logo
