<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 18, 2015 at 12:59 PM,  <span dir="ltr">&lt;<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ryan,<br></div><div><br></div><div>Can you please explain what you do for initialization (especially for large arrays, sets, etc)? Assuming that Newspeak also has something like Smalltalk&#39;s nil, do you fill them at creation time with nil?</div></div></blockquote><div><br></div><div>We eagerly assign nil to all slots. For regular objects, it is important that slots for a given class are always initialized in the same order, otherwise a JS engine like V8 won&#39;t consider all the instances to be of the same Map (hidden class), things will seem more polymorphic than they are, and optimizations won&#39;t happen. For arrays, I don&#39;t know whether this is more harmful to performance because we pollute type data about the array&#39;s elements with UndefinedObject or this is more helpful because we don&#39;t need checks for undefined in #at:. Certainly in terms of implementation effort, eager initialization is much better than sprinkling checks in all the places that access slots.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I was thinking of avoiding that and testing the receiver at every invocation for JavaScript&#39;s undefined instead. Of course, this just moves the pain point, I am not sure which is better. Also, the test for nil can be avoided when the receiver is &quot;this&quot; or &quot;super&quot; or some literal - one can optimize this even in other cases with some static analysis.</div></div></blockquote><div><br></div><div>We do very little static analysis beyond the standard cheats for #ifTrue: and friends. Generally, it makes implementing reflection much more difficult. dart2js is a good example of a compiler with this problem.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I also don&#39;t understand the line:</div><div>&quot;NS2JS and NS2V8 both map Newspeak&#39;s basic types onto JavaScript&#39;s basic types by installing functions on the prototypes of Number, String, etc. We apply strict mode, so these functions do not operate on boxed values.&quot;</div><div><br></div><div>E.g. the following snippet works:</div><div><br></div><div>&quot;use strict&quot;</div><div>Number.prototype.test = function() {return 5};</div><div>var n = 2;</div><div>n.test()</div><div><br></div><div>So what does it mean that &quot;these functions do not operate on boxed values&quot;?</div></div></blockquote><div><br></div><div>When the function test is not in strict mode, every invocation requires the allocation of a number object to use as the receiver. In strict mode, the receiver is the number value directly. (ECMAScript 5.1 10.4.3)</div><div><br></div><div>Ryan</div></div></div></div>