I’d say it definitely depends on the situation. There are some cases when extending and just taking use of certain parts is more efficient and better for performance as well, while there are others where inheritance is the better way to go.

The other problem I see is the fact the shared method is put into a random objext (the first on the list). Inheritance would create a logical place to put shared code. Here, you just have to know which of the objects has the shared method.

Well, you could check for the existence, and if not’s there, just create an empty container with curly braces (i.e. {}).

In your code example, though, you create closures that doesn’t return anything. If you want to extend objects from other functions/files, you need to make them globally available.

So say I have, XNamespace.js which is like:


( function ( ) {

};
}) ( );


And then in another JS file, say YNamespace.js, I have got something like:


( function ( ) {

};
}) ( );


How do I ensure that X is available for Y? So far, the solution that I have come up with is:


if(typeof X === 'undefined') {
document.write('');

}


Which i Think is funky, Any better solutions ? I am pretty new to this kinda stuff, so I cant think of any better ones out there … Basically I wanna do something like dojo.require(‘X.Y.Z’) and get the namespace.

Suggestions?
Regards
Vyas, Anirudh

Thanks for the link!

Thank you!

Oh, absolutely, if you need to build on it, you would probably have some more generic object. It’s just to exemplify reusage possibilities.

With this implementation, now we can’t change the behaviour of Chris’ getCapacity method without breaking the functionality for Meg (suppose Chris developed low self esteem too?). One option might be to create a generic getCapacity method (perhaps on Griffins) which could be used (and augmented as needed) by each family member.

I do appreciate your feedback; hell, it’s one of the reasons I allow comments, I don’t want this web site to be just a one-way communication.

I want to understand different views and takes, and how people value different criteria. I don’t have to agree with all input, but just respect that there’s usually more than one way to do something.

Also, in the end I think it comes down a lot to personal experience: which kind of projects have one worked, with what kind of developers does one deliver code etc. So, it’s all relative.

So, at times namespacing and inheritance complement each other just fine, but in other cases I really do think that namespacing alone can be sufficient.

Putting it that way I’m almost tempted to agree with it. On the other hand I can’t say I fully disagree either. In my experience I only find a use for pure namespacing when prototyping something new. After refactoring I always end up with inheritance chains. Considering we use largely different approaches, ending up with other solutions is no surprise.

Mind you, Robert, I do find your views very refreshing. Shooting holes in them is just a way to come to a better understanding. Untill the next shootout

Thanks!

Stefan,

To begin with, no matter how you choose to work with inheritance, I’d say that namespacing is always a good idea and a great complement to other code!

What I was also arguing for here is that OOP pricinples aren’t always the best solution, especially for certain web scenarios. When it comes to extensive reusage of code, inheritance can naturally be a good thing, but from what I often see, it is way overused and complicaced in cases where it doesn’t have to be.

So, at times namespacing and inheritance complement each other just fine, but in ohter cases I really do think that namespacing alone can be sufficient.