Re: Uninteresting parameters

[Mike Shaver]

On Wed, Sep 28, 2011 at 9:11 PM, Brendan Eich  wrote:
> No worries, array extras are a great addition, we just need to keep rolling.

Oh, no offense taken.  I just meant to say that there may be
consistency-with-existing-pattern reasons to prefer one hole behaviour
over another, is all.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Uninteresting parameters

[Mike Shaver]

On Wed, Sep 28, 2011 at 2:50 PM, Brendan Eich  wrote:
> I agree holes need better handling in future arraylike "extras". Design
> effort there can start now, using today's JS. I'd welcome it. Perhaps
> underscore does well already?

IIRC I chose the hole behaviour in the ES5 array extras based on the
behaviour of some existing library, though I don't see the rationale
documented in any of the bugs I can find.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Class Syntax Proposal, Complete With Arguments For and Examples.

[Mike Shaver]

On Sun, Sep 18, 2011 at 1:36 AM, Jonathan Dumaine
 wrote:
> You could go
> all the way and make classes a very strict subset of the language: throw an
> error if the user tries to set a property of a class instance that has
> already been declared private
[...]
> I would personally prefer the prior route: sacrifice some of javascript's
> dynamic attributes in favor of better abstraction and encapsulation
> capabilities.

But one problem here is exactly related to abstraction and
encapsulation: the class's implementation can't add a new private
property without risking breaking of existing clients: if they were
using the newly-claimed name as an "expando" property's name, then the
changes to the "encapsulated and abstracted" internal representation
will cause them to error out.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: IDE support?

[Mike Shaver]

On Fri, Sep 16, 2011 at 1:55 AM, Andreas Rossberg  wrote:
> Being able to detect when a condition is violated is not equivalent to
> knowing that it always holds.

You're right, of course. Thanks for slicing that more finely for me.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: IDE support?

[Mike Shaver]

On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg  wrote:
> On 14 September 2011 00:00, Brendan Eich  wrote:
>>
>> So, static+dynamic. The static side has some powerful algorithms to bring to 
>> bear. Dynamic is necessary due to eval and kin, and gives strictly more 
>> information (and more relevant information!).
>
> Nitpick: I believe you are mistaken about the "strictly more" bit.
> There is information that _only_ static analysis can derive. Consider
> e.g. aliasing or escape analysis, or other kinds of global properties.

There are systems that handle escape analysis cases via write
barriers, no?  Alias detection (or more importantly non-alias
determinations) seem amenable to the assume-and-guard model used for
PICs and trace selection and other code specialization patterns seen
all over modern JS engines.

The TraceMonkey engine tracks many global properties (including the
properties of globals) to deoptimize as needed and optimize where
possible; our TI and IonMonkey work goes even further.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Language modes (Was: Block scoping and redeclarations)

[Mike Shaver]

On Wed, Aug 24, 2011 at 11:30 AM, Allen Wirfs-Brock
 wrote:
> The "modern" mode won't seem very modern twenty years from now.
> allen

My understanding is that anything after the Middle Ages is fair game,
and I see strict as the middle age between ES.now and ES.future. :-)

MIke
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript terminology: non-function-valued property

[Mike Shaver]

Which primitives have own properties?  I thought even "str".length
conceptually came from the prototype.

Mike
 On Jul 22, 2011 6:13 PM, "Axel Rauschmayer"  wrote:
> To contrast non-method properties with methods:
> - To say that instances usually only have non-method properties.
> - To say that primitives can have non-method properties, but don’t have
their own methods (they borrow them from their wrapper types).
>
> Maybe “non-method property” is good enough for that purpose.
>
> On Jul 23, 2011, at 0:00 , Brendan Eich wrote:
>
>> On Jul 22, 2011, at 2:55 PM, Axel Rauschmayer wrote:
>>
>>> I’m still wondering if there is an established term for a
non-function-valued property in the JavaScript community (where method is a
term for a function-valued property). Possibilities that I see are:
>>
>> Why do you need this term? In what practical sentence would you use it?
>>
>> /be
>>
>>
>>>
>>> - instance variable
>>> - member variable
>>> - field
>>>
>>> OO literature sometimes uses the term “attribute” but that is already
taken by ES-262.
>>>
>>> --
>>> Dr. Axel Rauschmayer
>>>
>>> a...@rauschma.de
>>> twitter.com/rauschma
>>>
>>> home: rauschma.de
>>> blog: 2ality.com
>>>
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> --
> Dr. Axel Rauschmayer
>
> a...@rauschma.de
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pure win: Array.from and Array.of

[Mike Shaver]

On Sun, Jul 10, 2011 at 7:09 AM, Dmitry A. Soshnikov
 wrote:
>> If I hadn't made map skip holes, then the fill pattern would be simple
>> enough:
>>
>> Array(4).map(function (_,x) x * x);
>>
>
> It's in particular case, you try to multiply indices, which in current
> implementation of `map` anyway gives unfortunately nothing.

Yes, as I said it *would* work if map had been specified not to skip holes:

js> [undefined,undefined,undefined,undefined].map(function(_,x)x*x)
[0, 1, 4, 9]

Is that not what you want?

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pure win: Array.from and Array.of

[Mike Shaver]

On Sun, Jul 10, 2011 at 6:06 AM, Dmitry A. Soshnikov
 wrote:
> The problem:
>
> Array(4).map(function(x) x * x); // [NaN, NaN, NaN, NaN]

I think it actually produces just [ , , , , ], because map skips
holes.  (If you see the NaN behaviour in FF, please file a bug.)

If I hadn't made map skip holes, then the fill pattern would be simple enough:

Array(4).map(function (_,x) x * x);

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

On Fri, Jul 1, 2011 at 2:50 PM, Mike Samuel  wrote:
> 2011/7/1 Mike Shaver :
>> On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel  wrote:
>>> 2011/7/1 Mike Shaver :
>>>> What can someone do with that password, though? Just change your
>>>> subscription settings, afaik, so the security in place seems proportionate.
>>>>
>>>> Could report it upstream to the mailman team, I suppose.
>>>
>>> Use it to do a better job of impersonating.  Try it out on other sites.
>>
>> I don't understand how you could impersonate better, could you
>> explain?  You can send mail with any From: you want without bothering
>> to go through someone's mailman account, and you can't even send mail
>> from the mailman interface!
>>
>> Since mailman passwords are randomly generated at subscription time
>> (and virtually never changed), password reuse is pretty unlikely.
>
> Can't a mailman account holder associate a public key with a mailman instance?

Not in stock mailman (http://www.gnu.org/s/mailman/features.html), but
there is a fork which permits it, I think.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel  wrote:
> 2011/7/1 Mike Shaver :
>> What can someone do with that password, though? Just change your
>> subscription settings, afaik, so the security in place seems proportionate.
>>
>> Could report it upstream to the mailman team, I suppose.
>
> Use it to do a better job of impersonating.  Try it out on other sites.

I don't understand how you could impersonate better, could you
explain?  You can send mail with any From: you want without bothering
to go through someone's mailman account, and you can't even send mail
from the mailman interface!

Since mailman passwords are randomly generated at subscription time
(and virtually never changed), password reuse is pretty unlikely.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Mailing list reminder: password is sent in the clear

[Mike Shaver]

What can someone do with that password, though? Just change your
subscription settings, afaik, so the security in place seems proportionate.

Could report it upstream to the mailman team, I suppose.

Mike
 On Jul 1, 2011 10:09 AM, "Axel Rauschmayer"  wrote:
> That’s a good start, thanks. Still find it a bit scary that there’s no
encryption.
>
> On Jul 1, 2011, at 16:07 , André Bargull wrote:
>
>> Log-in at [1] and remove the option to send a monthly password remainder?
>>
>>> Get password reminder email for this list?
>>> Once a month, you will get an email containing a password reminder for
every list at this host to which you are subscribed. You can turn this off
on a per-list basis by selecting No for this option. If you turn off
password reminders for all the lists you are subscribed to, no reminder
email will be sent to you.
>>>
>>
>>
>> [1] https://mail.mozilla.org/options/es-discuss
>>
>>> Can this be fixed? I’ve already sent feedback, but didn’t get a
response.
>>>
>>> Preferably, passwords would also be encrypted for storage.
>>>
>>> --
>>> Dr. Axel Rauschmayer
>>> axel at rauschma.de
>>> twitter.com/rauschma
>>>
>>> Home: rauschma.de
>>> Blog: 2ality.com
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> twitter.com/rauschma
>
> Home: rauschma.de
> Blog: 2ality.com
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: prototype focus

[Mike Shaver]

On Jul 1, 2011 1:14 PM, "Brendan Eich"  wrote:
>
> On Jul 1, 2011, at 2:21 AM, Tim Smart wrote:
>
>> I quite the current prototype model we have in ecma5. My only gripes
would be that `prototype` to too wordy,
>
>
> Do you use it that often?

15 years ago, writing an overwrought prototype hierarchy for a server-side
JS project, I experimented with

P = "prototype";

function Thing () { }
Thing[P] = { ... }

Wasn't worth it, I decided, because it didn't match the (then scant, now
abundant) documentation of delegation. Same principle applies here for
adding synonyms, I think.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Mike Shaver]

On Tue, Jun 28, 2011 at 3:34 PM, Bob Nystrom  wrote:
> I like the simplicity of this, but I'm not crazy about how it merges two
> distinct objects into one. TodayJS (and most class-based languages) let you
> distinguish two things:
> 1. A set of properties relevant to the class itself.
> 2. A set of properties shared by each instance of the class.
> In a class-based language, #1 up there is "static" methods and fields. So
> when you do something like this in Java:
>   Integer.parseInt("1234");
> The "parseInt" method isn't a method that you can call on an integer, it's a
> method you call on the Integer class itself.

Actually, in Java, you can (or could, when last Java and I spoke) call
class methods on instances:
  Integer boxed = new Integer(5);
  boxed.parseInt(42);

That doesn't work well in JS, because obviously there's no prevention
of name collisions.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[Mike Shaver]

On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer  wrote:
> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
>
> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance 
> that this kind of API will make it into Harmony? It would be really useful 
> for a variety of generative/meta-programming tasks.

I'm interested in this too, for a number of applications, but I keep
getting stuck on one thing.

Would you standardize the resulting parse tree, too?  That would
probably mean that every engine would have two parsers, since I'm sure
we produce different parse trees right now, and wouldn't want to lock
down our parser mechanics for all time.

If you don't standardize the parse tree, is it still useful?  More
useful than just using narcissus or whatever other parsing libraries
exist?

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: block-lambda revival

[Mike Shaver]

On Jun 23, 2011 6:14 PM, "Jorge"  wrote:
>
> The C language is still (and -ISTM- will be for a long time) important, so
-IMO- every little bit of JS's C-like syntax is a plus: less to learn: an
old, popular, widely used, well-known, and familiar syntax.

The fraction of JS programmers who have ever used C is small and shrinking
fast.  Even for other Algol suburbs.

> JS -unlike other languages- is important enough that it does not need to
follow these (dubious) trendy fashions to become popular. Nor to survive.

Do you really believe that these proposals are motivated by fashion?

> Proper punctuation aids comprehension and we're programming, not writing
quick SMSs.

Punctuation can be valuable, especially for indicating the relationship
between words and phrases, or disambiguating (c.f. uncle Jack and the
horse).

But we shouldn't make authors illuminate their leading caps, or write !!!1!
whenever they want to exclaim. Abbreviations and are popular in speech
because they make expression easier as well as shorter.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Object.defineProperty shorthand

[Mike Shaver]

On Thu, May 26, 2011 at 11:54 AM, Sean Eagan  wrote:
> On Thu, May 26, 2011 at 1:43 PM, Mike Shaver  wrote:
>> On Thu, May 26, 2011 at 11:37 AM, Sean Eagan  wrote:
>>> // ! implies non-writable, ~ implies non-enumerable
>>> // all assignment operators can be used
>>> ! a.b += c
>>
>> Legal parse today, though I'm not sure you can get runtime semantics
>> that aren't an error.
>
> Correct, I was intending for it to no longer be an error.

I don't understand how that could work.  By the time you get the
runtime error (trying to increment a boolean value), we have already
performed a property access, which can have side-effects.  More
practically, an engine would have to reconstruct the original
syntactic form from the runtime result.

addto(c, not(get(a, "b")))

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Object.defineProperty shorthand

[Mike Shaver]

On Thu, May 26, 2011 at 11:37 AM, Sean Eagan  wrote:
> // ! implies non-writable, ~ implies non-enumerable
> // all assignment operators can be used
> ! a.b += c

Legal parse today, though I'm not sure you can get runtime semantics
that aren't an error.

> !~a.b++
> !(~(a.b++))

Legal expressions today with valid meanings.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing out-of-memory and stack-depth-exceeded errors?

[Mike Shaver]

On Wed, Mar 23, 2011 at 8:21 PM, Garrett Smith  wrote:
> Bad quoting made it confusing, but I was (am) right. Edited as intended below:
> On 3/23/11, Garrett Smith  wrote:
>> On 3/23/11, Mike Shaver  wrote:
>>> On Wed, Mar 23, 2011 at 6:21 PM, Garrett Smith 
>>> wrote:
>>>> javascript: alert(new InternalError("Got on tha inside, bitch!"));
>>>>
>>>> Hrm. seems odd to expose the constructor publicly.
>>>
>>> Necessary to permit instanceof testing, no?
> [...]
>>>
>> No; instanceof uses [[HasInstance]] which compares the Function's
>> prototype property to the each objet in the object's prototype chain.
>> If there is a match, the result is true. Otherwise, the result is
>> false.

I mean that you need the constructor exposed to test instanceof for
InternalError.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing out-of-memory and stack-depth-exceeded errors?

[Mike Shaver]

On Wed, Mar 23, 2011 at 6:21 PM, Garrett Smith  wrote:
> javascript: alert(new InternalError("Got on tha inside, bitch!"));
>
> Hrm. seems odd to expose the constructor publicly.

Necessary to permit instanceof testing, no?

> The infinite recursion could be detected and reported early. Where
> does that happen? Does any engine report early for infinite recursion?

No engine in all of computer science does so.

http://en.wikipedia.org/wiki/Halting_problem

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bringing setTimeout to ECMAScript

[Mike Shaver]

On Sun, Mar 20, 2011 at 12:24 PM, John J. Barton
 wrote:
> Looping as fast as possible is likely to be a bug. It's not similar to
> queuing events.

It's the behaviour intentionally (if unwisely) requested by a lot of
animations and games, for what it's worth.  There are better models
becoming available (*RequestAnimationFrame, for example), but not
standardized or universal.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: About private names

[Mike Shaver]

On Mar 20, 2011 3:34 PM, "Kyle Simpson"  wrote:
>>
>> BTW, if you know that a property name is foo, why would you ever code
obj["foo"] instead of obj.foo?
>
>
> The most obvious reason is if the name of the property contains a
character which cannot be an identifier character in the property name...
like a unicode character, for instance.

"Unicode characters" (non-ASCII) other than whitespace are pretty much all
permissible in property names via dot syntax, FWIW. Lambda and pi are the
most common, though I've seen other math/greek as well.

A property name with whitespace is not expressible with dot syntax, but
unlikely to be used except in object-as-hashtable cases.

> Are we talking about the difference between obj['foo'] and obj[foo]? I
think perhaps that was a subtle shift in this conversation that I missed
until just now?
>
> Without private names, is there (and what is it?) an important distinction
between:
> 1. obj[foo] and obj.foo; AND
> 2. obj['foo'] and obj.foo

The former case of #1 refers to a property named by the value of the
variable |foo|. All other cases refer to a property named "foo". So the
cases in #2 are equivalent, but the ones in #1 are not.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native JS Encryption

[Mike Shaver]

On Sat, Mar 19, 2011 at 2:45 PM, Robert Accettura  wrote:
> Are there any successful key based encryption schemes that have actually 
> succeeded with "normals"?

TLS would be the obvious example, bitlocker and other encrypted file
systems as well.  We have hopes for the Firefox sync mechanism too,
though we built our own cryptosystem to some extent, so...we'll see.

Most "normals" don't use crypto APIs of any kind, so I'm not quite
sure what you mean.

>  In my view when we look at GPG, PGP, the complexity was always the key to 
> failure (pardon the pun, I couldn't resist).

API complexity?  That's the reason for things like Keyczar: they
provide an API where the simplest thing to do is also the safest, and
provide fewer places for people to slip up in mode selection, key
management, etc.  Crypto is hard, and even very experienced
practitioners get it wrong a lot.  Giving people raw AES/SHA-256/etc.
is unlikely to lead to them building secure systems, though it will
likely let them believe that they did.

Keyczar et alii are not a panacea: you still need to actually manage
the environment, but they take away a lot of error surface, and remove
the need for a lot of arcane mathematical knowledge.

> While I'm not opposed to something along those lines, I do think that the 
> more traditional schemes should be considered though perhaps discouraged.

I don't see the value of adding something that we immediately
discourage people from using.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native JS Encryption

[Mike Shaver]

On Sat, Mar 19, 2011 at 10:09 AM, Mark S. Miller  wrote:
> I agree about outside domain experts. In fact, I wish we could invite
> outside domain experts participate in all tc39 activities as we deem
> appropriate. I do not understand the rationale for bounding invited expert
> participation.

I think this would be a good idea.  If nothing else, providing "raw"
crypto APIs can be a footgun, given the difficulties in actually using
these ciphers and key management systems correctly.

Thomas Ptacek has a good post on this, and I've invited him to send me
an elaboration that I'll forward to the group.

http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html

TL;DR, at the risk of my mis-sumarizing Thomas' excellent exposition:
APIs like Google's Keyczar, which provide a more complete and
harder-to-misuse set of capabilities, would likely be a better idea,
and invite fewer missteps.  They would not be simple to implement
robustly, and neither Keyczar nor cryptlib are licensed liberally
enough to be baked into all implementations.  That's a sign that it's
a hard problem more than that those are bad solutions, though.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing __proto__

[Mike Shaver]

On Fri, Mar 18, 2011 at 5:11 PM, John-David Dalton
 wrote:
> Extending the Object.prototype is a compatibility nightmare

It was a compatibility nightmare when people didn't namespace, and
when you couldn't make non-enumerable properties.  Using a namespace
for additions to the prototype chain and using ES5's defineProperty to
keep those additions from affecting enumeration behaviour seems like
it overcomes those, at least to me.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing __proto__

[Mike Shaver]

On Fri, Mar 18, 2011 at 1:53 PM, John-David Dalton
 wrote:
> Ya, some people have that reaction at first, but after use it's not
> bad. Most of the time you create a string or value once then pass
> around the variable.
> Because these sandboxed natives chain, usage is natural. As such
> fuse.String(...).split(' ') produces a sandboxed Array so you go from
> 1 sandboxed native to another without hassle.
> Same goes for fuse.Array(1,2,3).join() -> a sandboxed String value.
>
> Generics are also supported fuse.String.concat(str, other) so you can
> pass in regular natives too.
>
> PrototypeJS and other libs use wrapper/utilities for strings, DOM
> elements, arrays, ... so using fuse.String() is just as easy as say
> $w().
> By using the framework it becomes second nature to assume, for
> example, fuse(...).getAttribute(..) returns a sandboxed String value.

But AIUI the point of sandboxing is to keep different libraries from
stepping on each other's toes, and AFAICT such libraries use literals
(string, array, object and regexp) quite liberally.  In Prototype all
4 are used.  In jQuery all 4 are used and passing in a String object
where a string primitive is expected will fail because of explicit
typeof checks.

If you *do* control the code in question, you can just write your code
to use a namespace (Object.prototype.ns.method(),
Object.prototype.ns2.method()) as easily as sprinkling |fuse.|
everywhere, and without giving up the ability to use literals or
closures (!).

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing __proto__

[Mike Shaver]

On Fri, Mar 18, 2011 at 10:45 AM, Oliver Hunt  wrote:
> I think so -- my proposal doesn't take instances, nor produce instances, it 
> takes the constructor function (Image is one of a handful of DOM constructor 
> that can actually be used to construct things) and returns a new constructor 
> that will produce an instances of the target object with a modified prototype 
> chain.

Andreas in IM that we hang it on the prototype chain, so that we get
it everywhere without repetitive specification.  How about:

Function.prototype.createDelegatingTo = function (obj)
{
  var o = new this; // really new-with-apply(arguments) here
   o.__proto__ = obj;
   return o;
}

Then Array.createDelegatingTo, Boolean.createDelegatingTo, Image, etc.
should all work.  (I like the longer, grosser name because I think
it's sort of a gross pattern, and not something that should use up a
concise name.)

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing __proto__

[Mike Shaver]

On Fri, Mar 18, 2011 at 9:29 AM, John-David Dalton
 wrote:
> @Mike Shaver
> For other possible uses please check out:
> http://msdn.microsoft.com/en-us/scriptjunkie/gg278167
> https://github.com/jdalton/fusebox#readme

Those all look like they are needing custom-initialization, not
arbitrary mutation at any point.  Would you agree?  For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those prototypes.

Preserving (or adding to other engines) arbitrary prototype chain
mutation in order to work around name collisions seems wrong to me.
Mutable proto just happened to be the hack that worked (though so did
iframes), and I can't really find anything other than Fuse that uses
it on the web today.  The solution to name collisions is simple
modules, IMO, not monkeypatching of the builtin prototype hierarchy.

I think you can also achieve what you want with Harmony proxies, so
you'll have that option in the next edition of ES.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardizing __proto__

[Mike Shaver]

On Fri, Mar 18, 2011 at 9:14 AM, John-David Dalton
 wrote:
> The __proto__ property is a powerful language feature that cannot be
> reproduced through any existing part of the language.
> Current proposals like,
> http://wiki.ecmascript.org/doku.php?id=strawman:array_create, are too
> limiting, (it's useful for more than just arrays) and don't cover the
> full functionality/flexibility of __proto__.

It would be good to hear more about the use cases that aren't met by
Object.create and Array.create.  Mutation of prototypes of builtin
objects or host objects seems unlikely to be interoperable even today.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Harmony is a super-set of ES5 strict"

[Mike Shaver]

On Fri, Feb 25, 2011 at 7:36 AM, David Bruant  wrote:
> Does it mean that the "use strict" directive is implicit whenever an
> ESHarmony feature is used? (this sounds wrong, but I'm asing the question
> anyway)

It means that the semantics of Harmony are based on ES5-strict, not
ES5-unstrict, yes.  There will be no with, |this| will not be coerced
to an object wrapper, etc.

I don't know, tbh, what it means for things like Proxies which can be
implemented in ES5 contexts and therefore be accessed by non-strict
code, but I would expect that their semantics (values of |this|, f.e.)
would match those of strict mode, however they were called.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: idea: try/catch and "rethrow"...?

[Mike Shaver]

On Tue, Feb 1, 2011 at 10:53 AM, Kyle Simpson  wrote:
> ?I have something that annoys me about how JavaScript try/catch error
> handling currently works. Don't get me wrong, I totally understand why it
> works that way, and it makes sense. But having the option to get around that
> behavior would be really nice.

I believe that catchguards have been accepted as Harmonious.
Spidermonkey has had them since the ES3 days, but they weren't
standardized due to making things too hard for someone's debugger.

try {
  throw 5;
} catch (e if e == 4) { // not caught
   four(e);
}

try {
  throw 5;
} catch (e if e == 4) {
  four(e);
} catch {  // fallback
  other(e);
}

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stupid i18n use cases question

[Mike Shaver]

On Sun, Jan 30, 2011 at 10:32 AM, Shawn Steele
 wrote:
> I'm still trying to grok "word processing in JavaScript" (beyond the simple
> case)

What's to grok?  Microsoft is putting word processors on the web,
even.  They don't want to go back to the server for all processing
(word breaking, etc.) on entered text, I'm sure, and I doubt anyone
else will want to either.

Maybe you could be more explicit about what about the implementation
language being JavaScript (which must currently include server-side
applications like Node, of course) makes you confused, or why you
think some specific application is inappropriate to perform in JS.

I'm doing simple stemming and word-breaking by hand in JS on both
server and client side, to facilitate "fuzzy" search over a moderate
corpus.  Making it work in non-English languages is a daunting
prospect both implementation-wise and in terms of finding expertise in
all relevant languages, and I don't think it should be that way.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stupid i18n use cases question

[Mike Shaver]

On Sat, Jan 29, 2011 at 9:24 PM, Shawn Steele
 wrote:
> I realize what line breaking's for, but I didn't think that would often be
> done in JavaScript.  You "preformat some text" in JavaScript?

Yeah, for use in SVG or rendering atop canvas, for example.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: promises | Communicating Event-Loop Concurrency and Distribution

[Mike Shaver]

On Thu, Jan 27, 2011 at 9:37 PM, Mark S. Miller  wrote:
> I don't understand why single-frame continuations are not at least as
> vulnerable to the criticism you make above. They are even more unproven
> among JavaScript programmers than are the concurrency abstractions in the
> strawman. The main benefit of moving support for single-frame
> continuations into the language is notational, which you dismiss above. I
> don't get it.

We have some experience with single-frame continuations in the Firefox
code base (and elsewhere such as threads.js from Neil Mix), based on
our years-old implementation.  The thing *I* like most about it,
versus working from a callback-based model, is that you can use the
language's flow control constructs.  Having to turn everything inside
out via function chaining hurts a lot, even with helper libraries that
are popular in the node.js community.

for (var i in hash) {
  doSomethingAsyncAndWait();
}

versus gross hackery like breaking out of the enumeration every time
and deleting the just-processed property.  Nothing that code to be
written out of order, or shattered by function decomposition and glued
back together in the programmers mind, will be as satisfying I fear.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operator Overloading

[Mike Shaver]

On Mon, Jan 10, 2011 at 10:55 AM, Brendan Eich  wrote:
> In light of the incubation argument and big-ticket items, I don't think value 
> proxies break our complexity budget but they are very new. They're unlikely 
> to get into ES6. Let's keep discussing here and working on the wiki as 
> interest and time allow, and not try to kick them out for some false economy.

I'd also add, from my perspective helping direct Mozilla's efforts on
the JS engine, that having more implementations doing experimental
work to get experience with specific features (including how they can
be made high-performance, and how they compose with key stack cohorts
like the DOM) would be a huge help, and I think could dramatically
improve the resulting quality of the spec.  Erik: can the V8 team help
in this way?

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property / Literal stealing using Object.defineProperty

[Mike Shaver]

On Thu, Dec 30, 2010 at 9:15 AM, Allen Wirfs-Brock
 wrote:
> Chrome is non-compliant with the ES5 spec. in this regard.
>
> The specification of object literals in section 11.1.5 uses 
> [[DefineOwnProperty]] to install object literal properties.  It is not 
> supposed to trigger any inherited get/set functions.
>
> Try it in FF4 or Safari 5.0.3 or a IE9 preview to see the correct behavior.

Yeah, we actually had to fix this in FF3.5 (2 years ago!) to deal with
JSON data leaks based on our getter/setter extensions:

https://developer.mozilla.org/web-tech/2009/04/29/object-and-array-initializers-should-not-invoke-setters-when-evaluated/

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: natively negotiating sync vs. async...without callbacks

[Mike Shaver]

On Thu, Dec 9, 2010 at 12:22 PM, Getify Solutions  wrote:
> 1. I'm not trying to open the can-o'-worms around block level changes. The
> above code suggests that a 'yield' suspension of execution is local to the
> nearest container { } block, in this case the try { } block

No, as implemented in JS1.7, the suspension is of the innermost frame,
not the innermost lexical block.  (You think that it would pause that
block, and then jump to the statement following it, to execute from
there until the yield...yielded?)

https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Iterators_and_Generators
has more.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Colons and other annotative characters

[Mike Shaver]

I'd expect that

o = { a : b = 5 }

Was legal now, setting both o.a and b to 5.  Not at a shell, is there an
exception in the grammar for assignment expressions in the value position?

{ a = 5 : T } might work, though.

Mike
 On Nov 22, 2010 6:09 PM, "Waldemar Horwat"  wrote:
> On 11/22/10 10:13, Brendan Eich wrote:
>>> { foo : G : 33 }
>>
>> 0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
>>
>> 1. let typedObj = { foo :: G : 33 }; // the guards strawman
>>
>> 2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
>>
>> 3. let typedObj = { foo @ G : 33 }; // funny cartoon chars
>
> Good list. Out of those five, the only one I'd find compelling would be
the first:
>
> { foo : G : 33 }
>
> Alternatives 0, 1, and 3 have the problems that were already well-stated.
2 has strange placement of parentheses.
>
> If we're brainstorming, I'd throw out an alternative for the object
initializer syntax:
>
> {name: value} // What we have now, for compatibility
> {name = value} // Identical behavior to {name: value}
> {name: type = value} // Adding a type annotation
>
> If we're looking at other ASCII characters for type annotations, a few
other characters such as the backtick might be an option:
>
> {name`type: value}
> {name!type: value}
> {name%type: value}
> {name~type: value}
>
> Waldemar
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Errors in syntax for array destructuring?

[Mike Shaver]

On Fri, Oct 15, 2010 at 8:34 AM, Brendan Eich  wrote:
> On Oct 14, 2010, at 11:47 PM, Dominic Cooney wrote:
>
>> On the harmony:destructuring page
>>  it
>> specifies this syntax for patterns:
>>
>> Pattern ::= "{" (Field ("," Field)*)* "}"
>>          | "[" ((Pattern | LValue)? ",")* "]"
>> Field   ::= Identifier (":" (Pattern | LValue))?
>> LValue  ::= 
>>
>> Is it intentional that commas aren't required between fields of an
>> object pattern, for example, {x y}? That seems concise, but odd.
>> SpiderMonkey doesn't support this syntax.
>
> There is a comma (",") in the first EBNF production you cite from the wiki, 
> just after the meta-left-parenthesis:
>
>> Pattern ::= "{" (Field ("," Field)*)* "}"

Maybe I'm misreading it too, but I would expect that since the inner
("," Field)* can match the empty string

"{" (Field )* "}"

and therefore as Dominic says just have "{" Field Field Field "}"

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Syntax for Efficient Traits" is now ready for discussion (was: Classes as Sugar is...)

[Mike Shaver]

On Tue, Sep 14, 2010 at 8:46 AM, Mark S. Miller  wrote:
> Btw, the current proposal does currently repurpose "with" for renamings.
> Even though there's no syntactic conflict, if we use "with" instead of
> "mixin" we should choose a different syntax for renamings. Suggestions?

"as".

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "use strict"; prepended blindly to scripts in the wild

[Mike Shaver]

On Thu, Sep 9, 2010 at 1:09 AM, Dmitry Soshnikov
 wrote:
> Currently, a site may normally concatenate 3rd-party libs with "use strict"
> at the global level. The technique is the same as with forgotten semicolon
> -- just to put an empty statement at the beginning of the end file.
>
> Thus the site's combined file won't be globally strict, however since a lib
> is tested before a production release (at least I hope so ;), then the lib's
> code should pass the strictness, and therefore, a "use strict" may be even
> removed from the lib's file. However, if not to remove, then an empty
> statement is enough.

Unfortunately for this eminently reasonable (IMO) assumption, removing
"use strict" can change the behaviour of a program, even beyond cases
that would have thrown an error.  For example, the type and value of
|this| can be different, for cases where methods are called on
primitives.

I don't know if other languages with optional strictures share this
property, but I suspect that a lot of people are going to stub their
toe on ES5's use of "use strict" as cover for incompatible changes
rather than strictly subsetting legal programs and behaviours. :-/

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap API questions?

[Mike Shaver]

On Fri, Sep 3, 2010 at 8:22 AM, David Herman  wrote:
> Mike momentarily forgot what they mean

Yes, it was a lapse from a casual observer reading the conversations
quickly; please don't let my brain-blip harm the sweet naming.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap API questions?

[Mike Shaver]

On Thu, Sep 2, 2010 at 11:32 AM, Erik Corry  wrote:
> Surely that is the case with WeakMap?  At least unless you lost the
> key and don't have any other references to the value.  In which case
> you can't reach the value any more, so why would you care whether it
> is kept alive?

You're right; I forgot about the fact that the keys were not
necessarily value types.  Sorry for the noise.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WeakMap API questions?

[Mike Shaver]

On Thu, Sep 2, 2010 at 12:46 AM, Erik Corry  wrote:
> And this is as it should be.  As it stands the weak map can be used as
> an object with private members.  The object key acts as a capability
> that controls whether or not you have access to the private member.

If I were to be using an object with private members, I would
certainly expect that those members would keep their values alive.

Wouldn't it be better to just use a regular object, and add private
members via defineProperty to make them non-enumerable?

I'm not in favour of WeakMap enumerability, really, but it seems that
there's an easier way to address this particular use case.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Rationalizing ASI (was: simple shorter function syntax)

[Mike Shaver]

On Sun, Jul 25, 2010 at 8:15 PM, Mark S. Miller  wrote:
>> veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName
>>    (longArgument1, longArgument2, longArgument3, longArgument4,
>> longArgument5);
>
> Yes. Even in the absence of ASI issues, my inclination would be to put the
> open parent at the end of the first line. YMMV.

Many (most? virtually all?) indent-helping editors prefer the LP on
the second line, since otherwise they indent the argument list to
start at the 75th column, or what have you.  Not much point in
splitting the lines in those cases without putting the LP on the
second line.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Structs

[Mike Shaver]

On Wed, Jun 2, 2010 at 7:02 AM, Sam Ruby  wrote:
> On 06/02/2010 03:52 AM, Jason Orendorff wrote:
>>
>>> I'll still maintain that the choice that ECMA 334 takes, namely
>>> that the assignment to b in the example above, makes a mutable
>>> copy is a valid choice.
>>
>> I would expect
>>   a[0].x = 3;
>> to modify a[0], not a temporary copy of a[0]. How do you propose to
>> make that work in ES?
>
> I'll note that that is not the way strings work today:
>
> a = "abc';
> a[0] = 'x';

Strings are immutable, so I'm not sure they're a good guide here.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: modules proposal

[Mike Shaver]

On Mon, May 17, 2010 at 12:37 AM, Kam Kasravi  wrote:
> [kam] An example might be something like SVG.*Filter* where the importer was
> interested in retrieving only filter related features within a SVG module.

For this, I would rather let the exporter define named export lists,
so that there's better future proofing.  I would hate to be the person
adding something to the SVG module knowing that there were a bunch of
regexps floating around the web that might cause me to clobber
something unexpected.

Given Foo.* meaning what it will, I suspect we would see people
writing exactly what you did above, and being surprised that they
didn't get what they wanted: they want globs, not regexps, for that.
("*Filter*" isn't even a legal regexp, so they'd get a compilation
error, but when you have to write SVG..*Filter.*, I think it gets to
be pretty unwieldy.)

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Adoption of the Typed Array Specification

[Mike Shaver]

On Fri, May 14, 2010 at 10:30 AM, Chris Marrin  wrote:
> As Ollie mentioned, ArrayBuffers need to be able to be mapped to hardware 
> storage (either on the CPU or GPU). So anything that might change the 
> underlying storage address (such as resizing the array) would be problematic.

Resizing might invalidate some addresses, yes, but it seems like those
mappings aren't necessarily fixed for the lifetime of the object.  I
can create an ArrayBuffer and then do a bunch of stuff with it before
I ever hand it to WebGL, even today -- why should we make authors
manually create a new AB and copy?

Aren't these buffers allocated and deallocated and copied by C
programs, too?  It might be that extending an ArrayBuffer doesn't give
you the semantics you want, just as realloc might fail if you aren't
careful about updating the hardware mappings.  I presume that people
use malloc (or the VBO/etc. equivalent) to create them, and can
realloc to their heart's content as long as they don't break their
contract with the places they've passed it to.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Adoption of the Typed Array Specification

[Mike Shaver]

On Fri, May 14, 2010 at 2:09 AM, Oliver Hunt  wrote:
> The data is mutable, the length is not -- this is more in line with arrays in 
> other languages, but more importantly the whole point of the typed array spec 
> was to provide a compact typed storage mechanism.  Allowing the length to be 
> changed runs counter to this as it effectively puts us back in the position 
> of supporting sparse arrays.

I don't see why that's the case.  You can define the semantics such
that length-extension zero-fills (or NaN-fills, if you like to hurt
kittens) rather than permitting sparseness, and it would seem to meet
all the requirements of the typedarray spec.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Array.prototype.last()

[Mike Shaver]

On Wed, May 5, 2010 at 8:27 AM, Jordan Osete  wrote:
> I've been wondering for some time if there couldn't be a way to index arrays
> from the last element directly. Currently if you have an array lost in a
> deep objects hierarchy, you have to refer to it twice, once to access the
> array itself, and once again to access its length:

A temporary helps here, as is often the case with deep hierarchies.

> var lastItem =
>
> myObject.anArray[ myObject.anArray.length - 1 ];
>
> myObject.anArray[ myObject.anArray.length - 2 ] = "foo";

a = myObject.anArray; a[a.length - 1];

a[a.length - 2] = "foo";

> As it seems hard to change the core language to be able to access stuff with
> negative indexes, the idea would be just to add a method to ease getting /
> setting of items based on the length of the array:

It would be incompatible, since a[-1] means the same thing for arrays
as for objects: the property named "-1".

You can do it with slice and splice, though, if you don't want to just
use a temporary:

>  //get the last element, same as .last( 0 )
>
> var lastItem = myObject.anArray.last();

myObject.anArray.slice(-1)[0]

> myObject.anArray.last( 1, "foo" );

myObject.anArray.splice(-2, 1, "foo");

With destructuring assignment, the slice usage gets to be a little
more natural, though it still constructs an array unless there is some
analysis done of the call site.

TBH, I don't think that end-based access to arrays other than to
append, a la Array.prototype.push, is common enough to warrant adding
to the language.  You could decorate Array.prototype with your own
|last| method (including the unusual get/set overload) if you wanted,
and use ES5's property-descriptor facilities to keep it from affecting
iteration.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: three small proposals: the bikeshed cometh!

[Mike Shaver]

On Thu, Apr 29, 2010 at 3:25 AM, Alex Russell  wrote:
> 3.) Syntax for bound function de-reference
>
> Many functions, both in the DOM and in the library, accept functions as
> arguments. ES5 provides a bind() method that can ease the use of these
> functions when the passed method comes from an object. This is, however,
> inconvenient. E.g.:
>
>  node.addEventListener("click", obj.method.bind(obj, ...));

node.addEventListener("click", #(e){obj.method(e)});

>  1.) all de-references via bang from an object/function pair return the
> *same* function object (modulo #4).
>  2.) non-function objects de-referenced via bang are not mangled in any way
> (identical to dot-operator de-reference)
>  3.) there's no provision for binding arguments (curry)
>  4.) bang-bound functions are weakly referenced. If GC would otherwise
> remove a function object from memory, having previously bang-bound a
> function should not keep the function object alive

I'm not sure how you make 1 and 4 happen at the same time.  (It also
sounds like you're saying that bang-bound functions weakly reference
their inner function, not that they are themselves weakly referenced.)

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: quasi-literal strawman

[Mike Shaver]

On Mon, Apr 5, 2010 at 6:28 PM, P T Withington  wrote:
> On 2010-04-05, at 17:37, Mike Samuel wrote:
>
>> You can
>> find my slides at
>> file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html
>> .
>
> I'd love to see your presentation, but I can't seem to reach your home dir 
> from my LAN.  Any chance there is a more public copy somewhere?

http://google-caja.googlecode.com/svn/trunk/doc/html/es-macros.html :-)

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strategies for standardizing mistakes

[Mike Shaver]

On Thu, Oct 15, 2009 at 2:29 PM, Maciej Stachowiak  wrote:
> Just as a minor point of technical correction - this will actually alert
> "not IE" in Firefox because the right-hand sign of an assignment is
> considered a detecting access. (Just tested to confirm.)

Thank you!  I see that I wrote the test backwards when I tested here...

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strategies for standardizing mistakes

[Mike Shaver]

On Thu, Oct 15, 2009 at 1:47 PM, Allen Wirfs-Brock
 wrote:
> Is the Mozilla document.all optimization contingent upon the occurrence of 
> the text "document.all"?

No, but it's contingent on the property lookup being the
truthyness-testing-expression.  (I wouldn't call it an optimization;
if anything it adds some cost to certain paths.)

>  What happens for:
>   var docAll = document.all;
>   if (docAll) alert("IE"); else alert("not IE");

"IE"

var doc = document;
if (doc.all) alert("IE"); else alert("not IE");

"not IE"

It was something that was intentionally targetted at the common case
of the simple feature test, which is almost always "document.all".
This is done by the host object implementation, which is given access
to limited context ("is this access one that's being used to detect
the presence of a property, versus fetching the value?").

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strategies for standardizing mistakes

[Mike Shaver]

On Wed, Oct 14, 2009 at 7:40 PM, Jim Blandy  wrote:
> There's one specific kind of contextual information that's being looked at
> askance here: knowledge of the expression surrounding the call that invoked
> you.  Perl lets subroutines check what sort of value their caller is
> expecting; that hasn't aged well.

Our implementation of String.prototype.match checks the context in
which it's called, to see if it need bother with the expense of
constructing the result array (it needn't, if the match call is being
used simply as a test, which isn't unheard of on the web).  That
optimization aged pretty well, and indeed benchmarks often encourage
such context-sensitivity.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Iteration in JSON serialization

[Mike Shaver]

On Wed, Oct 14, 2009 at 7:39 PM, Jeff Walden  wrote:
> On 10/13/2009 10:54 PM, Luke Smith wrote:
>>
>> Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
>> 4, WebKit, IE8, and Chrome 3 work fine for this task.
>
> How precisely are replacer functions not properly applied in Firefox?  I
> remember reporting at least one bug on the replacer-function implementation
> that was fixed for 3.5 or a beta of it, and to the best of my knowledge they
> work fine, outside of a few cases such as for circular data structures (and
> the semantic difference there, if you're not looking for it, probably won't
> matter much anyway).  Have you reported a bug for this at
> bugzilla.mozilla.org?

Yes, he did: https://bugzilla.mozilla.org/show_bug.cgi?id=509184

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property Iteration in JSON serialization

[Mike Shaver]

On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat  wrote:
> No.  As I wrote, there is no de-facto implementation order because the
> implementations do not agree on the order in general, and what you call
> "fringes" such as numbers do matter.  Trying to force, say, insertion order
> would likely break compatibility.

IIRC, Firefox before FF3 used insertion order for arrays as well as
objects, and changed to index order for arrays in FF3.  I don't recall
any compat problems on either side of the transition with respect to
array iteration order.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strategies for standardizing mistakes

[Mike Shaver]

On Tue, Oct 13, 2009 at 7:01 PM, David-Sarah Hopwood
 wrote:
> I agree with Maciej. The implementation-defined operations have clear
> specifications of their parameters. I think that it is highly undesirable
> to adopt an interpretation in which they can have arbitrary additional
> inputs depending on the context in which they are used.

If they didn't depend on the context in which they are used, they
wouldn't need to be host objects, right?  The whole point of the host
object is that it knows things about the host (what mode it was loaded
in, what privileges the context offers, what the user's preferences
are) which aren't within the scope of the language proper.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Another de-facto insecurity we need to fix in ES5

[Mike Shaver]

On Wed, Jun 17, 2009 at 6:34 PM, Mark S. Miller wrote:
> I sincerely applaud this bold stance. If Mozilla proceeds in this manner
> successfully, then the present issue becomes a non-concern; as probably do
> several more we haven't stumbled across yet. Please let us know what we can
> do to help you succeed on this quest. Really. And thanks again!

I suspect that it would be _very_ helpful to have access to data from
Google's shadow copy of the web on where __proto__ appears in web JS.
As Maciej points out, the comp.lang.javascript search doesn't really
help us see how much breakage we would see in the web -- we know there
are certain patterns that would break (that's sort of the point!), but
understanding more about the "live" ones would be a big help.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ToPropertyDescriptor and [[DefineOwnProperty]], regarding Object.defineProperty

[Mike Shaver]

On Mon, Jun 1, 2009 at 3:40 PM, Jeff Walden  wrote:
> I don't see the point in making fields of property descriptors omittable.

At some point we'll need to deal with that, if future standards or
non-standard extensions from implementors add new fields and we wish
for existing scripts to continue to work.

That said, I think it will be extremely confusing to developers if
these ostensibly-boolean fields are really tri-state (true, false,
unspecified), so it seems like they should default to one of the true
or false behaviours?

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Explict Memory Managment

[Mike Shaver]

On Fri, May 22, 2009 at 4:53 PM, David Semeria  wrote:
> Ok. I assume object references are implemnted bi-directionally,
> otherwise the GC would take a lifetime to run.

I don't know of any that are implemented bidirectionally, since it
would be a waste of space; it's certainly not required for any fast GC
I know of.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Catchall invocation for 'null' and 'undefined' (or: how to be a disruptive influence in 3 easy steps)

[Mike Shaver]

On Fri, May 15, 2009 at 10:45 AM, William Edney
 wrote:
> Then, I could do the following (which would have saved me a lot of debugging
> time over the years):
>
> Null.prototype.__noSuchMethod__ = function (id, args)
> {
> alert('you were a bad boy and tried to send ' + id + ' to null');
> }
>
> Undefined.prototype.__noSuchMethod__ = function (id, args)
> {
> alert('you were a bad boy and tried to send ' + id + ' to undefined');
> }

This seems like something that can be addressed by "quality of
implementation" today, at least as far as error messages go.  I think
it's entirely possible for the error paths to give more context, so
I'm wondering if there are other significant use cases for creating
Null and Undefined.

(And would you then want toString and valueOf hooks to be honoured?
Would Undefined and Null be truthy or falsy?  Boolean is enough of a
mess on that score...)

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Case transformations in strings

[Mike Shaver]

On Wed, Mar 4, 2009 at 2:35 PM, Allen Wirfs-Brock
 wrote:
> Any input from our other Unicode experts would be appreciated...
>
> Here's what I found (running on Windows Vista):
> IE, FF, Opera
> "\u00DF".toUpperCase()  returns "\u00DF"

Same on FF3.1b3 on OS X.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline regexps and caching

[Mike Shaver]

2009/1/23 Laurens Holst :
> Hi,
>
> I and a colleague were puzzled by some strange behaviour in Firefox, we
> found that in some browsers literal regular expressions are cached and
> reused. Testcase:
>
> function test(str) {
>   var regexp = /^[^d]*\bd{1,4}\b[^d]*$/g;
>   alert('Expexted: 0/true, result: ' +
>   regexp.lastIndex + '/' +
>   regexp.test(str)
>   );
> }
>
> var xxx = "MM/dd/";
> test(xxx);
> test(xxx);
>
> It turns out that Firefox and Opera return 'false' for the second test
> result, whereas Internet Explorer and Safari return 'true' in both cases.

Firefox and Opera are doing what ES3 requires (s 7.8.5:
http://bclary.com/2004/11/07/#a-7.8.5 ), but I believe that it's being
changed in 3.1 to produce a new one each time the literal expression
is executed.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The JS onerror event and the ECMA Standard

[Mike Shaver]

On Mon, Jan 5, 2009 at 7:42 AM, Michael Ratcliffe
 wrote:
> Are there any plans to make onerror part of the ECMA standard and, if so, is 
> it possible
> for me to suggest adding an additional item that should be accessible from 
> the onerror
> handler? I would suggest that a fourth parameter be passed to the onerror 
> handler, which
> is the error object from the time the error is triggered. This would allow 
> access to the
> call stack from within the handler and would be an invaluable in uncovering 
> complex bugs.

No, window.onerror would be standardized by the W3C or WHATWG, since
it's not itself a language feature but rather a part of one embedding
context -- albeit a very popular one!  Standardizing call stack
representation could be in the scope of this group and the ECMA
process, if needed.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should host objects be able to have [[Class]] "Function", "Array" etc.?

[Mike Shaver]

On Mon, Nov 17, 2008 at 10:32 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Internet Explorer 4 had css filters that predates the SVG filter
> (AFAIK). SVG filter creates a compatibility problem. Maciej says that
> they worked around this by having style.filter return undefined, but
> have that undefined be a special value that is == to "". I think it
> would be a good idea to raise the issue with the SVG WG. If the SVG WG
> wants to act in good faith, they should consider creating an
> alternative property name for browsers, style.svgFilter, for example.

As Maciej said earlier in this thread, "this has been raised many
times with the SVG Working Group and they did not agree".  You're free
to do so again, but that process has nothing to do with ECMA, or
really this list.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should host objects be able to have [[Class]] "Function", "Array" etc.?

[Mike Shaver]

2008/11/14 Maciej Stachowiak <[EMAIL PROTECTED]>:
> Specifically, we expose a "filter" property on CSSStyleDeclaration, in
> support of the SVG filter CSS property. However, many sites test for
> "filter" to detect support for MSIE's proprietary "filter" property, which
> sadly has the same name but completely incompatible syntax. Thus, we return
> this kind of magical undetectable string so if tests don't detect us as IE.
> It works basically the same ways as Mozilla's undetectable document.all,
> which we also support.

Our undetectable document.all works by returning a different value
from the property access depending on whether it's a "detecting" use,
like |if (document.all)| -- we don't use a magic falsy object (which I
think is a violation of E262, but I'd have to dig into the ToBoolean
bits to be sure).

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Hoisting behaviour of 'const' and 'let'

[Mike Shaver]

On Sun, Oct 12, 2008 at 9:29 AM, David-Sarah Hopwood
<[EMAIL PROTECTED]> wrote:
>  - the hoisting behaviour of 'const' should be the same as 'let',
>   because:
>* it doesn't need to hoist for backward compatibility, unlike 'var';

Not for compatibility with the standard, but const as implemented in
at least 2/4 (not sure about JSCore) hoists, I believe.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

[Mike Shaver]

On Fri, Sep 19, 2008 at 12:26 AM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> If a thrown native object did not already have a stack, what is the
> harm in adding one?

What should be done with a sealed object that's thrown?

I'm having trouble reconciling "all thrown objects should have .stack
thrust upon them, so that all thrown objects expose the site of the
error" with "but it's OK if that .stack property is really something
else".

Having |throw "msg"| provide an exception which is not a primitive
string is a straight-out break of the language's semantics; I don't
think it's feasible at all.  (Mozilla code throws naked numbers all
over the place, and I suspect would break quite spectacularly if it
got an Error object instead.)

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Volunteers needed: Function.prototype.bind() in ES3.1 pseudo-code

[Mike Shaver]

On Thu, Sep 18, 2008 at 1:41 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> 2008/9/18 Mark S. Miller <[EMAIL PROTECTED]>:
>> The Redmond mtg is fast approaching. We'd like to put out an official
>> for-Redmond-mtg draft of the ES3.1 spec by then. I had volunteered to write
>> the spec for Function.prototype.bind(). Long term, I think we all agree we'd
>> like to see this spec and many others self-hosted in EcmaScript. However,
>> the discussion of self-hosting issues makes clear that this ain't gonna
>> happen in time for ES3.1.
>>
>> So what we need now is a spec for Function.prototype.bind() in the peculiar
>> pseudo-code style -- combining the worst of COBOL and assembly language --
>
> What pseudo-code style? This:

The pseudo-code style from the existing ES3 spec.  An example:

11.3.1 Postfix Increment Operator

The production PostfixExpression : LeftHandSideExpression [no
LineTerminator here] ++ is evaluated as follows:

1. Evaluate LeftHandSideExpression.

2. Call GetValue(Result(1)).

3. Call ToNumber(Result(2)).

4. Add the value 1 to Result(3), using the same rules as for the +
operator (see 11.6.3).

5. Call PutValue(Result(1), Result(4)).

6. Return Result(3).

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

[Mike Shaver]

On Wed, Sep 17, 2008 at 3:07 AM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Instead, it would be more useful for all thrown objects to get a stack
> property, unless the object already had one.

This has been proposed before in Mozilla, but I and others objected
because we don't believe that throwing an object should mutate it, and
because it would cause primitives to be boxed by the property set (or
have more just-so ad hoc logic that is hard to reason about).

I would be more amenable to have {Syntax,}Error.throwObject(obj)
provide an Error with stack, and the provided obj as .data or some
such.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

[Mike Shaver]

On Mon, Sep 15, 2008 at 4:32 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
> Any magically bound variable breaks TC.  The expression
>
>  callee
>
> should have the same meaning as
>
>  (function() { return callee; })()
>
> ...and it clearly does not.

True, but it doesn't work for "arguments" or "arguments.callee"
either, so I'm not sure it's much of a loss to do something like that
here.

The important thing here seems to be decoupling "called function
capture" from "arguments to this function", since people are meaning
to do the latter and inadvertently doing the former.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Es-discuss - several decimal discussions

[Mike Shaver]

On Sat, Aug 23, 2008 at 10:04 AM, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Decimal implemented as a library would be sufficient for a 3.1
> release.

Would it not be sufficient forever?  It seems like that's the strategy
that Java, Python and C are taking, as far as the Really Important
Languages go.  I'd be more comfortable getting experience based on an
available library implementation before standardizing it, let alone
standardizing a new native numeric type, but I'm not likely to move
the committee needle.

Are people with critical decimal correctness needs using things like
http://code.google.com/p/gwt-math/ today?  Other ports of BigDecimal?
Other libraries that may be more "JS-like" than a straight port of
Java?

> To be sure, I then proceeded to implement such functionality using the
> then current SpiderMonkey (i.e. pre TraceMonkey, meaning I'm facing a
> significant merge -- the joys of DVCS),

I don't think you'll find it a hard merge; the tracer is (by design)
pretty well isolated from the rest of the engine.

Mike
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss