Regarding, import M.* via destructuring, it's also arguable whether we
don't need it since it looks like a with.
I don't see any sense in which it looks like a |with|. It's both syntactically
and semantically different. Syntactically, because it's a global (or
module-global) declaration
Hi,
2011/3/31 David Bruant david.bru...@labri.fr
Hi,
First, I'd like to say that I'm glad proxy-related issues have been
discussed during the last TC-39 meeting and that all have found an
agreement.
Then I have a something to say on
Le 04/04/2011 17:08, Tom Van Cutsem a écrit :
Hi,
2011/3/31 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Hi,
First, I'd like to say that I'm glad proxy-related issues have
been discussed during the last TC-39 meeting and that all have
found an
Binding this:
- Does it ever make sense to access globals via this? If so, I assume there
will be a use case in the upcoming modules rationale document.
- Should there be a keyword for the current module (a module-this, if you
will)? Accessing module-global data via this feels strange (I that is
Responding to a few of these:
On Mon, Apr 4, 2011 at 12:33 PM, Axel Rauschmayer a...@rauschma.de wrote:
- I think Python uses directories for namespace nesting, which has some pros
and cons compared to completely abstracting the file system structure.
It's necessary to completely abstract
Renaming:
- I find this syntax slightly unintuitive: import Geometry.{draw: drawShape}
At first glance this would mean for me: rename drawShape to draw. draw
feels to me like the result of the import.
This is based on the destructuring syntax, where this:
let {draw: drawShape} = ...
On 2011-04-04, at 12:40, Sam Tobin-Hochstadt wrote:
Renaming:
- I find this syntax slightly unintuitive: import Geometry.{draw: drawShape}
At first glance this would mean for me: rename drawShape to draw. draw
feels to me like the result of the import.
This is based on the destructuring
On 04.04.2011 18:40, David Herman wrote:
Though the other question is: why do we need `require` at all?
Purely for syntactic/practical reasons. Let's not bikeshed.
Why I was asking -- because I saw it in your talk on ES.next, where you
used exactly this approach, i.e. module Foo =
I take it that there might not be any standard support for inheritance in
ES.next beyond what is already there?
My personal favorite would be to get even more into Self-style (or Cecil-style)
class-less inheritance, but I realize that that’s not for everyone.
Until consensus is reached, how
I largely agree with Allen's point of approaching classification in a
dynamically typed language. I'm also a proponent of divorcing object
classification entirely from the inheritance hierarchy. In our traits.js
library, we decoupled traits from types, leaving the task of classifying
Hi,
I think it could be quite useful to spec parameter lists as mere
arguments destructuring sugar, something like this...
function f (this = defaultThis|a, , c = c, ...d) {
//...
}
...could desugar to...
function f () {
const this = __this__ ?? defaultThis;
var [a, , c = c, ...d] =
11 matches
Mail list logo
