The three of us whom write javascript has a silent agreement to avoid it, I think. There are times when it is tempting to do it just because you can, but one use to find a more straightforward way to solve the problem during the coffee break.

Thanks for sharing! I was hoping someone would express their love for a class-based approach.

It depends on a few factors, as you say: in very, very large projects it might become useful, but my estimate is, like you say, that memory usage will increase (and while not dramatically, every byte counts for me).

In terms of private and protected properties and methods, the Yahoo Module Pattern offers you just that: one part which can be private and another with protected or public methods.

Regarding your JavaScript framework, if it ever becomes official, please let me know!

However, I feel that in some cases it can be real usefull to mimic class based languages in some respects. Again it’s utterly dependent on user case and personal style, but for larger codebases, I prefer such an approach. However, this has issues as u describe.

What is needed for the class based emulation approach is something that gives us the goodies from other languages, without sacrificing native js syntax and behaviour. I do know a solution, but it’s in-house developed (I own it, but I agreed not to make it public yet). Forgive me to bring it up here, but I need it to illustrate my views.

To cut short, it’s possible to merge the two approaches gracefully. At home I can make class-like structures that I can use the native way, without any further calls to Class.extend() or something similiar. All magic is done by putting a few calls into the constructor and after that u can instantiate the classical way (IE with ‘new’).

Since I constructed this little lib, my productivity has increased dramatically. I now can have private, protected and static methods/properties. I have access control to classes and methods. When debugging I now get meaningfull errors, my objects can be introspected without writing endless for-in loops, etc. The trade-off is an increased memory usage, but that only shows when one creates something silly like 100.000 classes, and even then we’re not talking megabytes here.

While I agree that such things are overkill for ordinary websites, for larger projects I feel classical js falls short. At some point it pays off to start using a framework, if only to make the codebase easier to maintain. The way I use MF - Mystery Framework - I have the best of both worlds. I have all the benefits of js prototypical nature AND the ease of constraints like we know from Java. Lovely when the codebase surpasses the 1000 lines or so.

Forgive me this elaborate post again, but it has been a while and I don’t seem to be able to post anything short anyway

Cheers to all that made it this far!!!

But is that the framework pushing you into using it, or just that it would’ve been needed when you had it, no matter which JavaScript library you were using?

Interesting, thanks for the tip!

Anders,

Glad you liked it! The metaprogramming chapter is my favorite chapter in a JavaScript ever (or at least for a long long time)!

Kudos for using dLite!

By the way, would you say that by using Prototype at work for inheritance, that you might overuse inheritance inadvertedly or not?

Andrea,

Thanks! I haven’t fully read your document, but it looks quite good!

The only thing is: why people completely ignore my document?

Since I’m bound to Prototype in my current project at work, I stick to their class-like inheritence during office-time. On my own though (no libraries here except DLite), I will start to use the module pattern since it make sense to me.

If you’ve missed it (which I’d be surprised) the Open Web Podcast episode 2 has a bit of a discussion of the inheritance issue, which is kind of interesting.

http://openwebpodcast.com/