Javascript’s prototype-based OO would be so much better if objects could have multiple prototypes. One could then build arbitrary Directed Acyclic Graphs of object delegation, and build pretty much any kind of desired object-oriented semantics, any kind of inheritance scheme or method resolution order in the world ontop of that. Raw Power.
Currently all the approaches to building class-based inheritance in javascript either rely on copying attributes (which rather defeats the point of prototype-based OO semantics in my mind), or are limited to a single superclass (no mixins or multiple superclasses).
I think this is the main weakness in the argument that prototype-based OO is better than class-based. Yes - but only if you can spare me multiple prototypes. In my opinion I think the ECMAScript standards should evolve more in this direction, and less in the direction of hacking class-based inheritance into the language. Just add multiple prototypes and provide class-based inheritance as a library.
Can I just say that, after spending the better part of a day over the last week having to hack around its mysterious and messy guts, ActiveSupport’s dependency auto-class-loading code is officially Too Damn Magical For Its Own Good. Whenever you have non-trivial dependencies between classes and modules in your project, mysterious class loading bugs will often cripple your code in hard-to-track-down ways. Judicious use of ‘require_dependency’ is your friend here, although too much use of it will lead to further problems. Latent cyclic dependencies are often the culprit, and can be fixed or hacked around, but discovering them from the rather opaque exception (’expected foo.rb to define Foo’) and stack trace can be hard.
The following Rails bug: http://dev.rubyonrails.org/ticket/6001 doesn’t exactly help matters - if any of your classes refer to ApplicationController and are themselves referred to (and hence auto-loaded) during the environment loading process (environment.rb etc), this will lead to problems, as Rails does a straight ruby ‘require’ on application.rb after environment.rb has run. As it’s not called application_controller.rb, the auto class loading doesn’t work normally for it, which can cause further problems if ApplicationController gets tied up in any other dynamic dependency chain reloading issues.
Now obviously these issues are necessarily complex - loading classes from files with complex dependencies is a tricky problem when programming with a dynamic language. Although I can’t bring myself to use Squeak, the ‘directly edit the live code image’ approach Smalltalk/Squeak takes seems to avoid this problem of dynamically reloading classes from files during development. It’s something that needs to be thought about at the level of the Ruby language, and while the ActiveSupport hacks are admirable in their cleverness, cleverness that only works cleanly in the simplest cases is a mixed blessing.
One of the wake up calls for the music industry (which arguably is still fumbling sleepily with its alarm clock) was the Apple advertisement ‘Rip. Mix. Burn.’
Not only did the phrase lead to some heavy whinging from record labels - for irresponsibly encouraging piracy - it also spawned a swarm of academic papers and conference speeches right across the copyright reformist movement. More chilling for the industry however, it positioned Apple as a far more emotionally engaged intermediary between the artists and the fan than the labels themselves.
Apple’s press release is here:
http://www.apple.com/pr/library/2001/feb/22imac.html
and the TV ad is here:
http://www.theapplecollection.com/Collection/AppleMovies/mov/concert_144a.html
Yesterday we added our own contribution to remix culture. You can now make a Playlist in the Playlouder website, give it a title, and share it with other members. Just the basics are there right now, but this is a feature we think is very important so we shall be developing it over the coming months.
Let us know what you think.