Comments on Sept Meeting Notes

Rick Waldron waldron.rick at gmail.com
Thu Sep 26 15:30:52 PDT 2013


On Thu, Sep 26, 2013 at 6:20 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Sep 26, 2013, at 3:03 PM, Rick Waldron wrote:
>
>
>
>
> On Thu, Sep 26, 2013 at 5:43 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>
>> ...
>>
>> A negative is that it was decided that concise methods definitions create
>> enumerable properties and I don't think we really want these showing up in
>> for-in enumerations. Maybe we would want to revisit that decisions or at
>> least make an exception for concise methods (or accessors) defined using
>> explicit string literal names.
>>
>
> The whole point of making them enumerable was to undo a decision to that
> made an exception for concise methods—that applies to properties that were
> defined with string literal names (
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-09/sept-18.md#concise-method-definition-revisited
> )
>
> var o = {
>   "method": function() {}
> };
>
> Should behave exactly the same as
>
> var o = {
>   "method"() {}
> };
>
>
> Maybe the exception could be enumerability exception could be concise
> methods with string literal property names that do not parse as
> IdentifierName.
>

I'm trying to understand if there is something I'm missing about "string
literal property names that do not parse as IdentifierName" that is somehow
different from what exists today. What happens here:

var o = {
  "@concise"() {}
};

o["@method"] = function() {};

jQuery.extend(Some.prototype, o);

Some.prototype["@concise"] = "MINE";


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/7eda827c/attachment.html>


More information about the es-discuss mailing list