Yeah, tough questions. I don't know. I tried to make the API flexible by
allowing custom builders, and in fact if you look at the test suite you'll see
I did a proof-of-concept showing how you could generate the format that Mark
mentioned:
http://hg.mozilla.org/tracemonkey/file/2ce7546583f
>> - providing idiomatic syntax for calling the superclass constructor
>
> But what about subclass method calling superclass method(s)?
In terms of priorities, I think super-constructors are the single most
important use case for super. But I think super-methods fall out naturally from
the sema
I've been concerned about the schedule risk of classes for ES.next; following
are some thoughts about a minimal class feature that I believe satisfies the
most important needs while leaving room for future growth.
I think the bare-minimum requirements of classes would be:
- declarative class ex
> Self executing function expressions
Terminology nit: I think Ben Alman's right that "self-executing" is confused
terminology. I like his proposed term IIFE (pronounced: "iffy"):
http://benalman.com/news/2010/11/immediately-invoked-function-expression/
> (-> {
> // multi-line
> }())
>
> {||
>
So one thing that lambda really helps with, and where TCP is a serious
practical issue and not just philosophical, is macros.
Macros need the ability to create new kinds of control flow by taking
expressions and reordering and delaying them. You can use 'function' for this
but you don't want th
Hi David,
[A propos of nothing, can I ask that you either change your font or use
plain-text email? Your font shows up almost unreadably small in my mail client.]
> I'm currently working on the WeakMap documentation [1] and I have thought of
> two points:
> 1) myWeakMap.set(key, value) doesn't
The point is to encourage people to write *more* well-thought-out proposals
than can fit in an email, not less. Hence Allen's suggestion of blogs,
websites, or github. If language design issues can be resolved in bursts of 140
characters then I think I will need to find a new line of work. ;)
D
Agreed. Should be "must."
Dave
On Jun 1, 2011, at 3:42 PM, Brendan Eich wrote:
> Thanks for catching this, it goes back to
> http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_calls&rev=1273414092
> (first rev). Cc'ing Mark. I bet it is just a thinko for MUST and we can fix
> it quic
> P.S.: another question I have -- is it worth and makes sense to raise a topic
> on considering/standardizing the pattern matching (Dave's proposal)?
> http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan
> mentioned on Twitter that it's "too late" (?), but IMO this proposal
To a first, approximation, it would look something like this:
http://doc.racket-lang.org/reference/contracts.html
;-)
Seriously, the idea is to create contracts that can check structural properties
by wrapping values with proxies that lazily do the checking. The core idea,
known as higher-
IANA Rubyist, but I *think* the goal was for blocks to be downwards-only, so
that upvars could live on the stack and everything could be nice & speedy. So
they had to syntactically restrict blocks to enforce that they couldn't outlive
the frame in which they were created.
As Brendan says, that'
>> Mark and Tom used Ometa for http://code.google.com/p/es-lab/ --
>> slo-o-o-o-w.
>
> Yeah it has no memoization. Pretty cool nevertheless as far as what he was
> able to do. Though I really like what Dave is doing on narcissus.
No credit to me on the Narcissus parser; it was originally wr
Previously, you argued against the importance syntactic convenience, but it
seems what you really were opposed to was a new function form that wasn't a
true lambda. But now that there is one back on the table, you're OK with
counting conciseness as a win.
I don't mean to single you out on this-
> - they can share static information, such as sets of bindings (not that
> import * would not work with first-class modules)...
Oops, meant to say: "note that import * would not work"
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://ma
> Just a note on this: for me, that means Harmony modules
> are a step back from what I can implement in JS/now.
How is it a step back, if you can already implement it? We're not taking
objects away from JavaScript.
> Not
> having first-class modules has been a major drawback in
> Haskell (which
jsdefs.consts' as an alternative?
>
> From: Claus Reinke
> To: David Herman
> Cc: es-discuss@mozilla.org
> Sent: Friday, May 20, 2011 2:51 PM
> Subject: Modules first or second class (Re: I noted some open issues on
> "Classes with Trait Composition")
>
> Oh, it wasn't clear to me that we really want to have static members.
> I may be biased here, but I always viewed static members as just a
> poor man's substitute for a proper module system. Fortunately, it
> looks like we will have a real one instead!
I'm sympathetic to that view, but statics a
All exports of all declared/required modules are computed before execution
starts. So it doesn't matter what order things run in, you won't get any "no
such export" errors if you import a valid export.
Dave
On May 19, 2011, at 2:13 PM, James Burke wrote:
> Looking at harmony modules[1], I want
Yes, we've talked about this. One of the issues I don't know how to resolve is
if we want to allow the specification of class properties aka statics, then
those need *not* to be in the scope of the constructor arguments, which ends up
with very strange scoping behavior:
var x = "outer"
> Wouldn't introducing a new built-in constructor in some module scope
> actually have less risk (none?) of producing name clashes than messing
> with an existing object?
Yes, and I think it's worth considering. We still need to work out the
organization of the standard library in modules.
Dave
It's okay in Courier New but not in lots of other popular monospaced fonts. See
attached image.
Dave
<>
On May 18, 2011, at 3:30 PM, Allen Wirfs-Brock wrote:
>
> On May 18, 2011, at 3:14 PM, David Herman wrote:
>
>>> I think I like <: about as much as <|.
> I think I like <: about as much as <|. I'm not sure which is going to be
> more readable across a variety of fonts and sizes. <| does seem to be
> generally more visually distinct.
I just have to say that the pipe symbol in many fonts makes for a really
hideous triangle. It doesn't line up
> Using "new" for the constructor is one of my favorite feature's of Allen's
> proposal. Things I like about it:
>
> 1. It's terse. Since almost every class defines a ctor, this is helpful.
> "constructor" is a mouthful and repeating the full class name (like in Java,
> C++, etc.) is redundant.
Yes, I agree that separating them out is a good idea. Allen and I have been
working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
On May 17, 2011, at 6:55 PM, Luke Hoban wrote:
> - "self" is just another parameter, it can be called anything.
> - Function.prototype.call() and Function.prototype.apply() would have one
> parameter less.
> - IIRC, this is more or less how Python works.
> - Probably not worth it, migration-cost-wise.
This breaks the web, so regardless of whe
>> How do you define "non-method"?
>
> A function that is not invoked as method. Right now, the same kind of
> construct is used for both true functions and methods. I’m proposing a new
> construct (similar to the distinction that Python makes): a function that
> does not have an implicit |this
Evidence is good, but that's not exactly scientific. In particular, I'd wager
there's a material difference in this phenomenon between a language in which
*all* functions implicitly return and one in which this is only the case for a
specific convenience form.
That said, we could also consider
> There's no perfect answer. Shorter return syntax ("^" with an ASI change, or
> my "empty label" idea, "function f(){:g()}") is ugly, adds overhead, and can
> still be left off by mistake (making for the opposite problem from the
> capability leak one: returning undefined instead of the intende
> I want to make the language easier to beginners to learn, streamlining the
> syntax, replacing automatic semicolon insertion with statements that are
> by design semicolon free.
Can I ask what you mean by this? Just an illustrative example would probably be
enough.
Thanks,
Dave
__
> But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
> they are definitely not a representative
> Based on what evidence are "we" concluding that the majority of the
> javascript developers want -> syntax for functions? The fact that
> coffeescript is the hot buzzword? Was there some developer-community wide
> voting or poll that I missed? Or is it that a few vocal people on these lists
>
> JavaScript won't ever be known as a outstanding functional programming
> language until it has proper tail calls. This would give the language
> new capabilities it doesn't have now.
Proper tail calls are *already* in Harmony and totally orthogonal to the
question of new function syntax.
Dave
That sounds like a grammar bug -- no time to debug at the moment but I'll
address. A Program should be able to import but not export.
Dave
On May 2, 2011, at 12:50 PM, Erik Arvidsson wrote:
> http://wiki.ecmascript.org/doku.php?id=harmony:modules
> http://wiki.ecmascript.org/doku.php?id=harmony
IMO, writing these issues up as strawmen was a nice way to spark discussion but
I don't see any need for them to clutter the harmony: namespace with extra
proposals.
Why don't we just take the decisions and fold them into the existing proxy
proposals. Does that seem reasonable?
Dave
On Apr 28
Hi Claus,
Thanks for the bug report. I'm afraid I just don't have time for site
sysadminning at the moment. Eventually we are hoping to upgrade the wiki and
move it to our own (more reliable) servers, rather than the 3rd party server
it's currently hosted on. But I won't be able to work on this
> OTOH we don't need to standardize __proto__. We might instead poison-pill it
> in Harmony, so opting in involves an early error on every use of __proto__,
> and you have to migrate by switching to Object.getPrototypeOf or an object
> initialiser extension that allows presetting the new object'
rly early stage of design.)
Dave
On Apr 17, 2011, at 8:55 AM, Adam Stankiewicz wrote:
> By overwriting I meant creating a trap for === operator. Sorry for confusion.
>
> Adam
>
> 2011/4/17 David Herman :
>> I don't understand. What is "overwriting" an o
Claus,
Thanks for the suggestions. Let me see if I can summarize them and respond
briefly:
* functions with expression bodies
This was proposed for ES4 and implemented in SpiderMonkey. I believe there are
some unfortunate ambiguities in the grammar that came up, and I think they've
been treat
I don't like this idea. It's inconsistent with the behavior of the other traps,
it relies too subtly on a funky stateful idiom, and it's hard to predict when
the traps will actually fire (since it depends on how clients use the proxy).
If there's something being set once-and-for-all I prefer it
We've talked about this on TC39. We'll probably do something, but exactly what
is hard to say at this point. Designing future-proof pragma syntax requires a
bit of gazing into the crystal ball...
Dave
On Apr 17, 2011, at 2:13 AM, Claus Reinke wrote:
> Pragmas (ignorable source hints to an impl
I don't understand. What is "overwriting" an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
> Hello everyone,
>
> My idea is to disallow overwriting of === operator, and make 'compare'
> operator implement == instead. Why?
>
> 1. === means for me that two variables have re
The const functions proposal isn't about referential transparency. They still
encapsulate mutable state. What makes them "const" are the frozen property
table (recall that functions in ES are objects) and the local name that's bound
to the function.
Dave
On Apr 17, 2011, at 1:06 AM, Claus Rein
Forms like `fluid-let' don't actually make dynamic decisions about *scope* --
they just mutate an existing, statically-scoped variable. We're really just
talking about dynamic decisions about *where a variable is bound*, not *what
the current value of its binding is*. That said, I happen to know
distinction isn't actually all that important.
Regardless, it's clear I caused confusion by my usage. I'll make an effort on
es-discuss to be explicit about which I mean.
Dave
On Apr 15, 2011, at 6:48 PM, Mark S. Miller wrote:
> On Fri, Apr 15, 2011 at 6:28 PM, David Herman wrot
> P.S.: so having this issue as already solved (as a runtime error, but still
> -- the error!, not a typo-hazard!)
It doesn't always produce a runtime error. If the property happens to be there,
there's no error. Also, take a look at the confusing issues that arise from the
dynamic semantics of
The fact is that "dynamic scope" is used to mean multiple things: 1) the
"stack-like" semantics employed by e.g. the original Lisps, and 2) any
non-static scoping semantics. The former was so famous that it came to be the
common usage of the term, but #1 is really just a special case of #2. I've
Dynamic binding is bad, mmmkay? ;)
Seriously, it's not an efficiency thing. Dynamic scope is easy to write but
hard to predict. JS is lexically/statically scoped almost everywhere, except
for with, eval, and the global object. Strict mode solves with and eval.
Harmony solves the global object.
>> Or I guess, such cases will be replaced with function statements, right?
>>
>> if (isDebug) {
>>function debug() { ... }
>> } else {
>>function debug() { ... }
>> }
>
> Sure, that would be fine too.
Er, sorry, no -- block-local function declarations will be block-local in
Harmony.
D
Think of it this way: dynamic binding no, dynamic assignment yes.
> So this means, no function expressions depending on the condition? I.e.:
>
> this["foo"] = isDebug ? function () { ... } : function () { ... }
var foo = isDebug ? function() { ... } : function() { ... }
> Or I guess, such cases
I don't think this feature is worth all this discussion or time, which is why I
haven't said very much. But I don't like the idea.
It *is* ambiguous, in the sense that if you wrote the grammar in the natural
way it would be an ambiguous grammar, so you have to rewrite the grammar in
such a way
> Cool -- is this spec'ed yet?
http://wiki.ecmascript.org/doku.php?id=harmony:modules#this
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>> It'll be the WindowProxy as usual, in top level code. Dave has addressed
>> what it will be in a module recently.
>
> I have to look on Dave's explanation, seems I missed it. But this WindowProxy
> won't be assessable then, right? Will it be possible to define a new global
> property/variabl
Yes, that's the idea.
Best,
Dave
On Apr 11, 2011, at 7:45 AM, Axel Rauschmayer wrote:
> My understanding is limited, but here it goes:
>
> You load modules in ES.next as follows:
>> module JSON = require('http://json.org/modules/json2.js');
>
>
> A custom module loader (loosely related to a J
rogrammers
have to learn, and to date there's sadly not enough good, authoritative
material with that kind of advice ("how not to be anti-modular").
Dave
On Apr 11, 2011, at 7:07 AM, Mark S. Miller wrote:
> On Sun, Apr 10, 2011 at 11:21 PM, David Herman wrote:
>
I wondered if someone was going to make this point.
> That should be
>
> while (!{}.hasOwnProperty.call(obj, key))
>
> which works even if obj has an own property named 'hasOwnProperty'.
Not if someone mutates Object.prototype.hasOwnProperty or
Function.prototype.call. I don't think w
The module system was designed to make it as easy as possible to use, both for
general ease of use and to encourage modular programming. Once you move to an
approach where programmers have to write their own linking specifications, it
tends to get much more complicated. When you make modules mor
function getDefiningObject(obj, key) {
if (!(key in obj))
throw new Error("key " + key + " not found");
while (!obj.hasOwnProperty(key))
obj = Object.getPrototypeOf(obj);
return obj;
}
On Apr 10, 2011, at 10:24 AM, Axel Rauschmayer wrote:
> As far as I am aware, there
assage of a book from the 80's.
Dave
[1] If you don't know what call-by-value means here, don't worry about it. It
has nothing to do with call-by-reference, just an unfortunate overloading of
terminology. Nothing to see here, move along.
On Apr 9, 2011, at 10:24 AM, Wes Garland w
This would be brittle. Take all my arguments against the ^this feature
discussed in an earlier thread and repeat them here. Labels work just fine (and
better than numbers would) for this purpose.
Dave
On Apr 9, 2011, at 7:32 AM, Bradley Meck wrote:
> I think since we can only break/continue to
> [aside: as far as I understand Tennent, this has nothing to do
> with his principles of correspondence or abstraction, which
> are often misquoted and conjured with in the archives]
AFAICT, this traces back to a blog post by Neal Gafter:
http://gafter.blogspot.com/2006/08/tennents-corr
We shouldn't be making backwards-incompatible changes for features just because
they can be abused. Every feature can be abused. And simplifying the completion
type is not even remotely an important goal.
Sometimes labels are just necessary. Sometimes you have a loop that needs an
early return,
Yes. The RHS of a let binding is a dynamic expression, and involves no static
checking. The RHS of an import is a static module expression with validation --
it checks that the thing you're importing exists, and also prevents you from
importing the same name multiple times.
For example:
m
[Disclaimer: I'm not an expert at server code. That said...]
Don't you generally need to manage the policy for these kinds of requests
manually anyway? In particular, you can't actually tell if a user has abandoned
their session, since the browser doesn't let you know when that's happened. So
i
ork.
>}
>}
> }
>
> This would become more complicated with nested modules.
>
> On Apr 6, 2011, at 17:20 , David Herman wrote:
>
>>> - Does it ever make sense to access globals via "this"? If so, I assume
>>> there will be a use cas
> Why I was asking -- because I saw it in your talk on ES.next, where you used
> exactly this approach, i.e. module Foo = "http://modules.com/foo.js"; --
> without any `require`. That's it.
No problem, I didn't mean to chastise. Just trying to keep focussed.
> (should I fix my following present
> - 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.
Reflecting the globals via |this| preserves some web compatibility with
programs that dynamically test the global object. It allows you some
lightweig
The way I think about it is, whenever you have X: Y where X and Y are
identifiers, the one on the left is fixed and the one on the right is variable.
- In an object literal, the one on the left is a symbolic property name and the
one on the right is a variable.
- In destructuring, the one on th
> Allowing a callable module would go a long way towards bridging the
> gap with "settings exports" as that is the primary use of that
> feature, although it has been useful for text plugins to set the value
> of an AMD module to a text string (see loader plugins section).
I'll try to think up som
> 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
> Also, is it currently specified if rest parameters can have default
> values?
I'm more skeptical of this one. It's sort of treating empty arrays as falsey,
which they aren't. And I've never noticed a need for this. But that might just
be the BLUB principle in action. Do you have examples/use c
Hi Sean,
Yes, I'm interested in this possibility as well. It'll probably take some
careful working-through of the details to figure out exactly when/where this is
doable, but it's on my radar.
Thanks,
Dave
On Apr 1, 2011, at 7:37 AM, Sean Eagan wrote:
> Why not allow the spread operator to ap
Hi James,
> 1) Files as modules do not need module wrapper
>
> Just to confirm, if a JS file contains only a module definition, the
> module X{} wrapper is not needed?
That's correct.
>
> 2) Set module export value
>
>
> Is it possible to support settin
If I've got this right, the idea of soft bind is that the function
distinguishes whether it's called as a function or as a method; if called as a
function, it uses the lexical binding of |this|, and if called as a method, it
uses the dynamically pass-in binding of |this|.
Note that the .call an
On Mar 29, 2011, at 7:26 AM, David Herman wrote:
> This is what Sam is referring to -- we've been talking about exactly such a
> feature.
Sorry if that wasn't clear: at the last face-to-face we talked about allowing
you to give your own custom name for the |this|-parameter, s
This is what Sam is referring to -- we've been talking about exactly such a
feature. I continue to believe that something like the ^this feature we've been
talking about is as likely to introduce bugs as it is to fix bugs. It's like
special language support for off-by-one errors.
Dave
PS A pro
> I am really astonished to hear protection keys being thought
> of as "brittle" under transformation: that is just the opposite of what they
> are about!
Sorry to astonish you. :)
> Executive summary:
>
> - de Bruijn indices are a good assembly language of
> binding constructs, suitabl
> Allen makes the point that class D extends B {...} may look too much like
> languages where it means something quite different.
Yeah, I just don't buy the argument that having different semantics should lead
to different syntax: it proves too much. By definition, JS has a different
semantics
The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so it
Hi Claus,
Interesting idea; I'd never considered lifting some of these good syntax ideas
from Haskell before.
One issue with the Haskell `...` syntax directly is conflict with the
quasi-literals proposal, but we can think about alternatives offline (let's
*not* get into a discussion of concret
I wish you would make your proposal more precise; right now we have to infer it
from your single example. In my conversations with several others on the
committee, I'm already seeing lots of confusion about the semantics of what you
are describing here. Can you write this up as a strawman in mor
> Hoisting isn't nice in general, and from the "no use beforedeclaration"
> in [1], it seems that let bindings won't be hoisted,
> not even to their enclosing block.
That page is not yet complete. There's plenty more work to do on it, but we
probably won't be able to find much time to do
Brendan and Irakli both beat me to the punch here -- I would really like to see
stronger evidence that "an entire lexical scope" is really so onerous.
Everything you say about how Java mitigates the problem is just as applicable
to Harmony.
> Java doesn't formalize this, you're right — but if I
>>> right now, bracket notation is a superset of dot notation, but it would no
>>> longer be under the proposed syntax.
>>
>> I'm afraid I can't figure out what this means, but it doesn't sound true to
>> me.
>
> Right now, everything that can be expressed via dot notation has an analog in
> b
> right now, bracket notation is a superset of dot notation, but it would no
> longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to me.
> This gets at my other objection. Code is far harder to debug when every
> single property lookup
> typically this is seen as a quality of implementation issue. Note the we (and
> most other language specs.) don't say much (or anything) about GC in general.
> In one sense we don't need to say anything else about WeakMaps because it
> would be a lower quality implementation to retain objects
's algorithm
> or one that makes different tradeoffs (e.g., a rare O(N**2) in exchange for a
> lower constant overhead in the typical case), we should clearly leave to
> implementors. There is indeed nothing normative about this.
>
>
> On Sun, Mar 20, 2011 at 7:20 AM,
> I said that WHATWG has done some on work specifying what currently
> happens in browser (joining with your idea of "be[ing] compatible with
> existing event queue semantics"). One idea would be to see what they've
> done, get inspired and specify the event queue in ECMAScript.
OK. I'm on board f
size measurements.
(They'd be especially hard to automate, but I'd rather have the ability to test
manually than none at all.)
Anyone have experience with this from, say, the JVM and its weak references?
Dave
On Mar 20, 2011, at 8:20 AM, David Herman wrote:
>> It's weird, t
> It's weird, though--specifying anything about WeakMap reachability at
> all is a lot like specifying proper tail calls: it's hard to say what
> you mean without being a lot more concrete about the abstract machine
> the language runs on than you would be otherwise. The real requirement
> is simpl
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach to
specifying weak maps. I don't think we should be putting GC algorithms in the
spec at all; that would be overspecification. Instead, we should just focus on
defining reachability, and leave implementors free to com
>> It seems to me there are a couple pieces to Mark's concurrency proposal. One
>> part is formalizing the event queue that already exists.
> Is this already done in the current proposal? Because I haven't found it.
Sorry, I guess I should say, we can't add concurrency without having it be
comp
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists. Another part is
introducing new concepts and features to the language (like promises and vats).
I want to hear what Mark has to say at the TC39 meeting, but my gu
I agree with Dmitry on these points. In short: the new Generator(...) syntax
still requires its argument to be a generator function, so you've just added
pointless extra make-work to create one. And as Dmitry points out, you can
always implement that constructor yourself in JS.
What I think is
> P.S.:
>
> A small change, e.g. can be to make next as a getter since it doesn't accept
> arguments.
>
> g.next; // 1
> g.next; // 2
>
> But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterator. A
getter interface ob
[Oh sorry, I'm behind on the iteration-order mega-thread. I'll have to catch
up.]
On Mar 14, 2011, at 1:16 PM, David Herman wrote:
> Hi David,
>
> We have a strawman for making the enumeration order well-specified:
>
> http://wiki.ecmascript.org/doku.php?id=strawm
Hi David,
We have a strawman for making the enumeration order well-specified:
http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
Would that not be sufficient for the defineProperties case? I'd prefer that to
adding another trap.
Dave
On Mar 12, 2011, at 1:15 PM, David Bruant wrot
> A big favourite of mine (I'm biased, though...) is the Eigen2 library
> (LGPL3+):
I can't speak for other browser vendors, but I think that license isn't
compatible with Mozilla's codebase. But thanks for the reference.
> Using the small, fixed size subset of that lib and exporting the
> inter
> But I miss the linear algebra library to go with it.
Can you send references to example libraries for other systems that you would
like to see?
> Especially for the "binary data" approach, as it's removing an order
> that might be implicitly known - sorry, I don't know how to express that
> be
Hi Jeff,
I agree that the spec should deal with multiple global objects. I'm aware of a
few of the subtleties of multiple globals, but I wouldn't be surprised if there
are more. Thanks for raising this one. I created a placeholder strawman last
week, because I've been intending to get into this
>> So I think it might be a little misleading to say Harmony is strict-only.
>
> Who ever said that? :-P
Yikes... not playing who-said-what. For whatever reason, Waldemar got the
impression that someone said it, and I'm correcting the misconception, that's
all.
> I've written that Harmony is b
501 - 600 of 760 matches
Mail list logo
