<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: More SpiderMonkey changes: ancient, esoteric, very rarely used syntax for creating getters and setters is being removed</title>
	<atom:link href="http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/feed/" rel="self" type="application/rss+xml" />
	<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/</link>
	<description>Mozilla, politics, economics, law, backpacking, cycling, and other random desiderata</description>
	<lastBuildDate>Fri, 27 Apr 2012 03:03:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Jeff</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-155898</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Thu, 08 Dec 2011 18:31:44 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-155898</guid>
		<description>Fair enough, updated.</description>
		<content:encoded><![CDATA[<p>Fair enough, updated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared Wein</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-155796</link>
		<dc:creator>Jared Wein</dc:creator>
		<pubDate>Wed, 30 Nov 2011 16:48:28 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-155796</guid>
		<description>In your example:

&lt;pre class=&quot;code&quot; data-language=&quot;javascript&quot;&gt;
var o1 =
  {
    get property() { print(&quot;gotten!&quot;); return &quot;get&quot;; },
    set property(v) { print(&quot;sotten!  &quot; + v); }
  };
var v1 = o1.property; // prints &quot;gotten!&quot;, v1 === &quot;get&quot;
o1.property = &quot;new&quot;; // prints &quot;sotten!&quot;
&lt;/pre&gt;

…and programmatic:

&lt;pre class=&quot;code&quot; data-language=&quot;javascript&quot;&gt;
var o2 = {};
o2.__defineGetter__(&quot;property&quot;, function() { print(&quot;gotten!&quot;); return &quot;get&quot;; });
o2.__defineSetter__(&quot;property&quot;, function() { print(&quot;sotten!&quot;); });
var v2 = o2.property; // prints &quot;gotten!&quot;, v2 === &quot;get&quot;
o2.property = &quot;new&quot;; // prints &quot;sotten!&quot;
&lt;/pre&gt;

The two examples are slightly different. The first example should have printed &quot;sotten! new&quot; and the second example will only print &quot;sotten!&quot;. I&#039;m sure this was just a casual oversight, but it might be good to update it for future readers.</description>
		<content:encoded><![CDATA[<p>In your example:</p>
<pre class="code" data-language="javascript">
var o1 =
  {
    get property() { print("gotten!"); return "get"; },
    set property(v) { print("sotten!  " + v); }
  };
var v1 = o1.property; // prints "gotten!", v1 === "get"
o1.property = "new"; // prints "sotten!"
</pre>
<p>…and programmatic:</p>
<pre class="code" data-language="javascript">
var o2 = {};
o2.__defineGetter__("property", function() { print("gotten!"); return "get"; });
o2.__defineSetter__("property", function() { print("sotten!"); });
var v2 = o2.property; // prints "gotten!", v2 === "get"
o2.property = "new"; // prints "sotten!"
</pre>
<p>The two examples are slightly different. The first example should have printed &#8220;sotten! new&#8221; and the second example will only print &#8220;sotten!&#8221;. I&#8217;m sure this was just a casual oversight, but it might be good to update it for future readers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Where&#39;s Walden? &#187; Incompatible ES5 change: literal getter and setter functions must now have exactly zero or one arguments</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-148787</link>
		<dc:creator>Where&#39;s Walden? &#187; Incompatible ES5 change: literal getter and setter functions must now have exactly zero or one arguments</dc:creator>
		<pubDate>Sun, 22 Aug 2010 16:49:08 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-148787</guid>
		<description>[...] accessors), both programmatically and syntactically. The syntaxes for accessors were once legion, but SpiderMonkey has pared them back almost to the syntax recently codified in ES5 (and added new [...]</description>
		<content:encoded><![CDATA[<p>[...] accessors), both programmatically and syntactically. The syntaxes for accessors were once legion, but SpiderMonkey has pared them back almost to the syntax recently codified in ES5 (and added new [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-142452</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Tue, 27 Apr 2010 16:28:23 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-142452</guid>
		<description>Sure, it&#039;s impossible.  Use &lt;code&gt;Object.defineProperty&lt;/code&gt; or &lt;code&gt;Object.defineProperties&lt;/code&gt; if you want a named function as accessor (or the legacy &lt;code&gt;__defineGetter__&lt;/code&gt; alternative); it&#039;s not that much more work, and it&#039;s significantly more explicit and less bizarre (and more intentional, as well).  The language doesn&#039;t have to support every possible desire in its syntax.

And for what it&#039;s worth, stack traces include line numbers, so it&#039;s not like you&#039;re totally hosed if functions don&#039;t have names, nor is it the case that names are essential to debugging.</description>
		<content:encoded><![CDATA[<p>Sure, it&#8217;s impossible.  Use <code>Object.defineProperty</code> or <code>Object.defineProperties</code> if you want a named function as accessor (or the legacy <code>__defineGetter__</code> alternative); it&#8217;s not that much more work, and it&#8217;s significantly more explicit and less bizarre (and more intentional, as well).  The language doesn&#8217;t have to support every possible desire in its syntax.</p>
<p>And for what it&#8217;s worth, stack traces include line numbers, so it&#8217;s not like you&#8217;re totally hosed if functions don&#8217;t have names, nor is it the case that names are essential to debugging.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-142331</link>
		<dc:creator>Max</dc:creator>
		<pubDate>Tue, 27 Apr 2010 10:38:13 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-142331</guid>
		<description>So, as far as I got it, now it&#039;s impossible to assign a &lt;b&gt;named&lt;/b&gt; function to a property in an object literal. Right? I wish you to come over a long call stack trace with unnamed functions. Which is practically the only truly helpful mean for debugging an extension code.</description>
		<content:encoded><![CDATA[<p>So, as far as I got it, now it&#8217;s impossible to assign a <b>named</b> function to a property in an object literal. Right? I wish you to come over a long call stack trace with unnamed functions. Which is practically the only truly helpful mean for debugging an extension code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-141513</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Sun, 25 Apr 2010 08:32:42 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-141513</guid>
		<description>The bug to actually remove support for &lt;code&gt;{ get x y() { } }&lt;/code&gt; has now been fixed in the TraceMonkey repository and has been merged to mozilla-central, so it should no longer be in nightlies starting tomorrow.</description>
		<content:encoded><![CDATA[<p>The bug to actually remove support for <code>{ get x y() { } }</code> has now been fixed in the TraceMonkey repository and has been merged to mozilla-central, so it should no longer be in nightlies starting tomorrow.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mook</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-141125</link>
		<dc:creator>Mook</dc:creator>
		<pubDate>Wed, 21 Apr 2010 05:16:47 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-141125</guid>
		<description>Before, so that people can try to come up with reasons to not remove those features (which you can then reject if appropriate, but at least in that case they&#039;ve been heard).  I was thinking more about m.d.t.js-engine anyway, where it&#039;s actually a discussion group and not an announcement group.  This is before anything is checked in, anywhere (i.e. in the bug filing stage), so we can avoid messes like the recent tabbrowser extension regressions or the removal of XPCOM plugins.  Yeah, those are completely different areas, but they&#039;re the same in spirit - making backwards-incompatible changes to exposed APIs (in your case, language syntax).

I&#039;ve not actually tested the accessor-literal syntax, either, just heard so over IRC, so... maybe.

Forcing getters and setters to have the right number arguments sounds sane to me, since you can&#039;t sensibly access them except via the expression/assignment syntax, so there shouldn&#039;t have been much sense in allowing things that would have been unusable.  (I&#039;m also specifically ignoring the possibility of looking them up then calling them with the wrong number of arguments, of course, since that&#039;s obtuse enough that you might as well have an inner function in that case.)</description>
		<content:encoded><![CDATA[<p>Before, so that people can try to come up with reasons to not remove those features (which you can then reject if appropriate, but at least in that case they&#8217;ve been heard).  I was thinking more about m.d.t.js-engine anyway, where it&#8217;s actually a discussion group and not an announcement group.  This is before anything is checked in, anywhere (i.e. in the bug filing stage), so we can avoid messes like the recent tabbrowser extension regressions or the removal of XPCOM plugins.  Yeah, those are completely different areas, but they&#8217;re the same in spirit &#8211; making backwards-incompatible changes to exposed APIs (in your case, language syntax).</p>
<p>I&#8217;ve not actually tested the accessor-literal syntax, either, just heard so over IRC, so&#8230; maybe.</p>
<p>Forcing getters and setters to have the right number arguments sounds sane to me, since you can&#8217;t sensibly access them except via the expression/assignment syntax, so there shouldn&#8217;t have been much sense in allowing things that would have been unusable.  (I&#8217;m also specifically ignoring the possibility of looking them up then calling them with the wrong number of arguments, of course, since that&#8217;s obtuse enough that you might as well have an inner function in that case.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-141035</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Sat, 17 Apr 2010 10:34:40 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-141035</guid>
		<description>This is certainly feasible.  At a certain point, however, the approximation becomes sufficiently different from the actual algorithm that the developer can&#039;t simply reuse his knowledge of what the standardized method does.  There&#039;s either a fine line or a very wide and blurry line here.  Whichever the case may be, I think I prefer clear, bright lines that don&#039;t present room for error; not exposing enumerability or configurability toggles until they actually work means no developer can accidentally misuse those toggles.</description>
		<content:encoded><![CDATA[<p>This is certainly feasible.  At a certain point, however, the approximation becomes sufficiently different from the actual algorithm that the developer can&#8217;t simply reuse his knowledge of what the standardized method does.  There&#8217;s either a fine line or a very wide and blurry line here.  Whichever the case may be, I think I prefer clear, bright lines that don&#8217;t present room for error; not exposing enumerability or configurability toggles until they actually work means no developer can accidentally misuse those toggles.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Hogan</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-141034</link>
		<dc:creator>Sean Hogan</dc:creator>
		<pubDate>Sat, 17 Apr 2010 10:21:17 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-141034</guid>
		<description>Hi Jeff, thanks for the feedback. What about a JS implementation of Object.defineProperty that performs strict descriptor checking. First draft:

&lt;pre class=&quot;code&quot; data-language=&quot;javascript&quot;&gt;
Object.defineProperty = function(object, name, desc) {
 if (!desc.enumerable) throw &quot;Non-enumerable properties not supported&quot;;
 if (!desc.configurable) throw &quot;Non-configurable properties not supported&quot;;
 if (typeof desc.value !== &quot;undefined&quot;) {
  if (desc.get &#124;&#124; desc.set) throw &quot;Descriptor value not compatible with getter/setter&quot;;
  object[name] = value;
 }
 else {
  if (!(desc.get &#124;&#124; desc.set)) throw &quot;Descriptor must have value, getter or setter&quot;;
  if (desc.get) object.__defineGetter__(name, desc.get);
  if (desc.set) object.__defineSetter__(name, desc.set);
 }
 return object;
}
&lt;/pre&gt;</description>
		<content:encoded><![CDATA[<p>Hi Jeff, thanks for the feedback. What about a JS implementation of Object.defineProperty that performs strict descriptor checking. First draft:</p>
<pre class="code" data-language="javascript">
Object.defineProperty = function(object, name, desc) {
 if (!desc.enumerable) throw "Non-enumerable properties not supported";
 if (!desc.configurable) throw "Non-configurable properties not supported";
 if (typeof desc.value !== "undefined") {
  if (desc.get || desc.set) throw "Descriptor value not compatible with getter/setter";
  object[name] = value;
 }
 else {
  if (!(desc.get || desc.set)) throw "Descriptor must have value, getter or setter";
  if (desc.get) object.__defineGetter__(name, desc.get);
  if (desc.set) object.__defineSetter__(name, desc.set);
 }
 return object;
}
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff</title>
		<link>http://whereswalden.com/2010/04/16/more-spidermonkey-changes-ancient-esoteric-very-rarely-used-syntax-for-creating-getters-and-setters-is-being-removed/comment-page-1/#comment-141033</link>
		<dc:creator>Jeff</dc:creator>
		<pubDate>Sat, 17 Apr 2010 09:30:13 +0000</pubDate>
		<guid isPermaLink="false">http://whereswalden.com/?p=1643#comment-141033</guid>
		<description>Oops, this seems to have regressed in the dozen-odd rebases I had to do of the patch.  (The parser&#039;s been &lt;em&gt;very&lt;/em&gt; changeable lately, and the particular bit of code that parses this bit has changed a lot -- not that specifically, but various whole-parser idiom changes meant nearly every line&#039;s been touched.  Each such change then required a manual merge of changes, one of which I seem to have screwed up.)  Thanks for pointing it out, I&#039;ll file and fix.  (Now filed as &lt;a href=&quot;https://bugzilla.mozilla.org/show_bug.cgi?id=560018&quot; rel=&quot;nofollow&quot;&gt;bug 560018&lt;/a&gt;, CC&#039;d you while I was at it.)</description>
		<content:encoded><![CDATA[<p>Oops, this seems to have regressed in the dozen-odd rebases I had to do of the patch.  (The parser&#8217;s been <em>very</em> changeable lately, and the particular bit of code that parses this bit has changed a lot &#8212; not that specifically, but various whole-parser idiom changes meant nearly every line&#8217;s been touched.  Each such change then required a manual merge of changes, one of which I seem to have screwed up.)  Thanks for pointing it out, I&#8217;ll file and fix.  (Now filed as <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=560018" rel="nofollow">bug 560018</a>, CC&#8217;d you while I was at it.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

