--BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First . . . I think your description of the object model and how you think of it is excellent, and it very closely approaches the way I think about it, though I think some of the points you make come off a bit more subtly than they would if I tried to explain it. Of course, I'm also having a difficult time figuring out how to articulate my thoughts on that clearly, which is why I haven't contributed an explanation of my own sense of Ruby's object model to this thread. That having been said, I'll respond directly to some stuff you said now. On Wed, May 25, 2011 at 12:12:44PM +0900, David Masover wrote: > On Friday, May 20, 2011 12:58:26 PM Michael Sokol wrote: > > > > My case for that (even if I tend not to believe so) would be that > > someone might be tempted to think that during an object instanciation, all > > the instance variables AND methods gets duplicated for this particular > > instance, which isn't the case - yet, that's what the abstraction pushes us > > to believe. > > If you don't know JavaScript well, I would strongly suggest picking it up. > Read pretty much anything Douglas Crockford has to say about it, and playith > different OO patterns. I'm going to use this as an analogy here, so I'll try > to include enough background that it's understandable if you don't know any > JavaScript, or if you still think JavaScript is "Java Lite". > > JavaScript objects behave like hashes, and the two can be used almost > interchangeably. Methods are just functions (generally anonymous) which have > been stored in the hash, and a syntax for calling them which sets 'this' -- > but you can apply almost any function to almost any object. Many > implementations allow you to get a method's source easily -- playing around > with this, it seems that when you attempt to coerce a method into a string, > you get the source back. I would actually suggest that, in large part because of the compromises made in JavaScript's implementation in the ECMA standardization process, there is a lot of clutter in the language's design that obscures these characteristics of JavaScript's object model in some unfortunate ways. As an alternative to JavaScript, if the goal is solely to gain an understanding of this prototype-based object model philosophy, one might be better served to learn Io. I think that in the end JavaScript is a much more *useful* language, and there are in fact some implementation details of Io that I find a bit perversely cumbersome, but as a way to rapidly pick up the feel and implications of a prototype-based object model nothing comes to mind that comes anywhere near the efficacy of Io as an example language. > > Your choices for inheritance are either to use JavaScript's own prototypal > inheritance, or to write your own inheritance -- and your only choice for > multiple inheritance is to roll your own. With prototypal inheritance, any > time you try to access a property (either an instance variable or a method) of > a given object, it checks that object first, then its prototype object, then > the prototype's prototype, and so on, arbitrarily deep. > > Rolling your own is much more flexible -- you just create a new, empty object > (as easy as {}) and start adding methods to it. Basic inheritance would just > mean calling some "constructor" method which returns an object, then modifying > it in the child "constructor" method. Here is one case where I think Io serves better than JavaScript. A lot of what goes on in JavaScript -- especially where "best practices" and common cultural idioms are concerned -- is pretty heavily polluted by more "traditional" C++ish and Java-like object models' concepts of class hierarchies and the like than Io's approach. Ultimately, I find that it is much more obvious how to do protype-based OOP "correctly" in Io than in JavaScript as a result of that, and of other factors as well. So, to summarize . . . I think that Io is a better choice for the limited purpose of learning about these things. I think JavaScript is a better choice for learning a useful language, though. Some Io programmer may well take exception to my statements, and if so, I invite explanations why I'm mistaken. I'd really like to find out why (if it is true) Io is as useful a language as JavaScript for "real world" problem solving when it seems to me like it kinda isn't (and not just because of lacking libraries, tools, et cetera, but also because of some characteristics of its design). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3cmCQACgkQ9mn/Pj01uKXVUgCg68lHtPLSuXHIru8WmH5HL/J2 9ugAoJG+aDjDLkrUUiFBqZYjhQO4T684 b -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--