I've found that, for the most part, encapsulation is a solution in search of a problem. Once you stop taking for granted that it's a Good Thing because everyone knows that it is, you notice that the collisions that are supposed to be such a problem for the most part aren't, and when they do pop up it's not hard to find workarounds. What's far more common, at least in encapsulation-driven environments, is to be thwarted because you can't get at something you need. (Of course, "encapsulation" means a lot of different things. I'm not talking about, say, separation of concerns in design. I'm talking about the whole public/private/protected way of locking things away from external use.)

The value of encapsulation is in defining an interface. I mean a contract along the line of "These two blobs of code should be able to talk with each other using i, j, k, and l; if they really aren't, let's do more thinking." This is a good thing, it suggests you to think in terms of independent modules instead of spaghetti code.

However, when it comes to encapsulation by enforcing information hiding it sounds awfully lot like trying to protect random dumbfools from themselves. It certainly ought to be sufficient to define the public interface in the documentation or headers, and expect people to adhere to that.

A smart programmer really can find his way through into what was in the first place encapsulated if he really, really has to. Conversely, in the case where a dumbfool would ignore the documentation and poke around with private code he would simply do equally stupid but alternative things if he was prevented from touching any private parts (Hehe). That is, if one can't do the job he can't do the job no matter how severely his options are limited.

It depends entirely on the type of software you are creating. Encapsulation in system code (libraries, APIs, frameworks, etc.) is probably a good thing. We've seen the nightmare that comes when people exploit the full range of behavior of systems without regard to whether it's part of the official spec or the public API. You create a compatibility nightmare that forces you to do crazy things like release bug-compatible updates for the foreseeable future, and to make excessively sharp breaks between API generations.

you're absolutely right, and you present quite a compelling argument against object oriented programming itself. we're still paying the price for a prank a bunch of consultants played in the early 90s.

Sadly it's just a dream to create something in the DOM and make it private, if we ever get there, we will go to mashup heaven.

The ability to limit the scope of a script tag would be desired too. Something like:

<script> var notsoglobalobject = {}; </script> <script global-object="notsoglobalobject" src="yourevilscript.js"></script>

But stuff like these are both hard to design and hard to make real standards.

I am making it happen in WebKit.

Make sure to ask this guy: http://crockford.com/

I think he would have some great suggestions. :)

IE 5.5 had a lot of this with behaviors. IE 6 built on it further. Firefox push a lot of similar concepts with XUL. These ideas aren't especially new. There are a lot of subtlties that make this stuf really tricky.

For details on behaviors see http://msdn.microsoft.com/en-us/library/ms531079(v=vs.85).as....

Yup. This is heavily inspired by DHTML behaviors, like most of the componenty stuff today on the Web.

IE team did some great trailblazing work back in the day! :)

Performance improvements in modern browsers (V8 and webkit) along with more memory and faster processors are the game changers here.

Keep in mind that at the time it was all based on the Trident rendering engine introduced in IE4. The system requirements at the time were Win95 and 16MB of RAM. You write different code for that vs. a modern desktop today.

Totally agree. I had so much fun playing with that stuff way back when. Sad it never (or took so long to?) caught on.

This sounds very much like Mozilla's XBL ("XML Binding Language"), currently being standardized by the W3C: http://www.w3.org/TR/xbl/

Yes indeed! In fact, the public-webapps discussion is around its latest draft (also mentioned in the blog post): http://dev.w3.org/2006/xbl2/

The ability to hide stuff sort of takes the "script" out of Javascript.

What do you mean by that? A closure like

    function foo() {
      var x = 0;
      return function () { return x++; }
    }

and the equivalent in Python/Ruby/any language with closures hides x even better than a private member in Java would.

Did you people downvoting this comment actually read the entire article? "Teens seem to like it" (referring to "Team Edward" in his pseudo code) was without a doubt one of the most hilarious things I've read in a tech article. Lighten up... geez.

It was a very funny line in the article and I didn't down vote you, but I suspect people did because your comment added nothing to the discussion not out of maliciousness. Even: "If you are on the fence, reading this article for the one liner on teens is worth it." Or "This article contains a one-liner that is the funniest thing I've read in a tech article in a while." I've found I can make controversial statements without getting down voted (perhaps I'm lucky) but glib me-toos are ruthlessly suppressed. I think it makes the place nicer though.