<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Objects, Classes, and JRuby Internals</title>
	<link>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/</link>
	<description>Ruby and otherwise by Patrick Farley</description>
	<pubDate>Wed, 08 Sep 2010 20:32:09 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: pfarley</title>
		<link>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-95</link>
		<dc:creator>pfarley</dc:creator>
		<pubDate>Fri, 12 Oct 2007 22:22:36 +0000</pubDate>
		<guid>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-95</guid>
		<description>Hi John,

This gets a bit tricky.

Suppose you add instance specific behavior to the pirate object.  There now exists a Singelton class 'pirate.  A legitimate question is, "What is the class of 'pirate?"  If the world were sane the answer would be ''pirate, or Singleton class of the Singleton class of pirate. We know that 'pirate's super pointer points to Pirate, and, since ''pirate is a Metaclass (the class of the 'pirate class), it's super pointer should point to the Metaclass of 'pirate's super class.  That would be 'Pirate or Metaclass of Pirate.  Another way to say this is, " 'pirate subclasses Pirate so ''pirate subclass 'Pirate".  The __attached__ hack comes in because Ruby takes a shortcut.  When it creates 'pirate instead of setting it's &lt;b&gt;metaClass&lt;/b&gt; (or &lt;b&gt;klass&lt;/b&gt; in MRI) to ''pirate, it sets it directly to 'Pirate.  This way method dispatch continues to work normally, and messages sent directly to 'pirate (class methods) are matched against methods found in 'Pirate. If you  decide to define instance specific behavior on 'pirate, the interpreter will grab the class of 'pirate and find a Singleton class there, 'Pirate, that is not attached to 'pirate (it's attached to the Pirate class), so the interpreter knows to create a new Metaclass, ''pirate, on the fly whose super pointer is 'Pirate, and all is well in the world.  The madness pretty much stops there.  Ruby goes circular at that point, with the class of ''pirate being ''pirate.  This happens in some code I elided from the makeMetaClass source in my post.  It's all pretty interesting, but so fringe that I don't think it's really worth people cooking their noodles over.

//RubyObject:217
if (this instanceof RubyClass &#038;&#038; isSingleton()) { // could be pulled down to RubyClass in future
    klass.setMetaClass(klass);
    klass.setSuperClass(((RubyClass)this).getSuperClass().getRealClass().getMetaClass());
} else {
    klass.setMetaClass(superClass.getRealClass().getMetaClass());
}

Hi Lopex,

Will definitely spend some time looking about in trunk.  Thanks for reading the blog and all your JRuby work.  Can you tell me under what circumstances __attached__  is null?</description>
		<content:encoded><![CDATA[<p>Hi John,</p>
<p>This gets a bit tricky.</p>
<p>Suppose you add instance specific behavior to the pirate object.  There now exists a Singelton class &#8216;pirate.  A legitimate question is, &#8220;What is the class of &#8216;pirate?&#8221;  If the world were sane the answer would be &#8221;pirate, or Singleton class of the Singleton class of pirate. We know that &#8216;pirate&#8217;s super pointer points to Pirate, and, since &#8221;pirate is a Metaclass (the class of the &#8216;pirate class), it&#8217;s super pointer should point to the Metaclass of &#8216;pirate&#8217;s super class.  That would be &#8216;Pirate or Metaclass of Pirate.  Another way to say this is, &#8221; &#8216;pirate subclasses Pirate so &#8221;pirate subclass &#8216;Pirate&#8221;.  The __attached__ hack comes in because Ruby takes a shortcut.  When it creates &#8216;pirate instead of setting it&#8217;s <b>metaClass</b> (or <b>klass</b> in MRI) to &#8221;pirate, it sets it directly to &#8216;Pirate.  This way method dispatch continues to work normally, and messages sent directly to &#8216;pirate (class methods) are matched against methods found in &#8216;Pirate. If you  decide to define instance specific behavior on &#8216;pirate, the interpreter will grab the class of &#8216;pirate and find a Singleton class there, &#8216;Pirate, that is not attached to &#8216;pirate (it&#8217;s attached to the Pirate class), so the interpreter knows to create a new Metaclass, &#8221;pirate, on the fly whose super pointer is &#8216;Pirate, and all is well in the world.  The madness pretty much stops there.  Ruby goes circular at that point, with the class of &#8221;pirate being &#8221;pirate.  This happens in some code I elided from the makeMetaClass source in my post.  It&#8217;s all pretty interesting, but so fringe that I don&#8217;t think it&#8217;s really worth people cooking their noodles over.</p>
<p>//RubyObject:217<br />
if (this instanceof RubyClass &#038;&#038; isSingleton()) { // could be pulled down to RubyClass in future<br />
    klass.setMetaClass(klass);<br />
    klass.setSuperClass(((RubyClass)this).getSuperClass().getRealClass().getMetaClass());<br />
} else {<br />
    klass.setMetaClass(superClass.getRealClass().getMetaClass());<br />
}</p>
<p>Hi Lopex,</p>
<p>Will definitely spend some time looking about in trunk.  Thanks for reading the blog and all your JRuby work.  Can you tell me under what circumstances __attached__  is null?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lopex</title>
		<link>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-94</link>
		<dc:creator>lopex</dc:creator>
		<pubDate>Fri, 12 Oct 2007 22:04:22 +0000</pubDate>
		<guid>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-94</guid>
		<description>Hi, we've been performing some major refactorings in JRuby code base lately. The trunk doesn't use non-lookupable instance variables for  __attached__, __classpath__ and __classid__ anymore, this allowed us to lazily create instance variable containers. The __attached__ is now a plain java field. Class construction path has also been heavily refactored for performance and no new Class class allocator instances are created now per new user class.

John Hume: the __attached__ thing might be also a null, in general it acts as a back pointer in singleton class chain.</description>
		<content:encoded><![CDATA[<p>Hi, we&#8217;ve been performing some major refactorings in JRuby code base lately. The trunk doesn&#8217;t use non-lookupable instance variables for  __attached__, __classpath__ and __classid__ anymore, this allowed us to lazily create instance variable containers. The __attached__ is now a plain java field. Class construction path has also been heavily refactored for performance and no new Class class allocator instances are created now per new user class.</p>
<p>John Hume: the __attached__ thing might be also a null, in general it acts as a back pointer in singleton class chain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hume</title>
		<link>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-93</link>
		<dc:creator>John Hume</dc:creator>
		<pubDate>Fri, 12 Oct 2007 20:00:42 +0000</pubDate>
		<guid>http://www.klankboomklang.com/2007/10/12/objects-classes-and-jruby-internals/#comment-93</guid>
		<description>In getSingletonClass, why does a RubyObject have to check the "metaClass's" __attached__ instance variable to see if it's attached to itself?  What else could it be attached to?</description>
		<content:encoded><![CDATA[<p>In getSingletonClass, why does a RubyObject have to check the &#8220;metaClass&#8217;s&#8221; __attached__ instance variable to see if it&#8217;s attached to itself?  What else could it be attached to?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
