Hey...
I think most of you seem to be missing the point somewhat.
Let me explain:
There are certain reasons why languages such as Java and
other OO languages have evolved. Such as stability,
reusabilty/modularity, ease of use, security etc. Object
Orientation exists because people wanted have a way to do
easier abstraction of problems, and representing them in a
more human-like fashion.
Now what DynLayer tries to do is simulate parts of this
whilst providing funcionality for robust, consistant and
simple dHtml creation.
But how can you create a complex API such as DynAPI without
having some fundamentals already in place? Such as a fast,
stable, easy and safe way of creating a class
hierarchy/implementing basic OOP functionality.
I mean, how long has this "current" release been in a
debugging phase ??! Do you not think that this could have
been avoided, atleast in part, by having a more stable
coding ground to develop with?
True, Javascript's prototype based OO provide some
functionality for creating "classes". But this approach is
inherantly slow, memory consuming and error prone, since
some of the most fundamental OOP functionality is not
supported (such as encapsulation).
Why go halfway, sort of do OOP, but not really, because
it's too hard ? It's not! In the long run it's much
simpler. Which is the exact point of DynAPI in the first
place. There is a longer learning curve before you can use
it, but when you do, your efforts are greatly simplified
and accellerated.
What you would want, is somekind of Object providing the
remaining OOP functionality that Javascript does not
inherantly support, so that you don't have to recreate the
wheel everytime you develop somekind of JS application or
extension to it.
Pascals DynObject and Eytans SuperObject, are examples of
what I'm talking about.
DynObject provides better modularity for DynAPI, and a
SuperObject would provide the tools with which to better
build a more modular DynAPI (there are infact a couple of
more people that have developed a SuperObject/SuperClass).
Yes, you could argue that this would only lead to more
bugs, and that you should rely on JavaScript's built-in way
of handling OOP, and that this should be a API for
designers, not for programmers and what have you...
But this is simply not true.
1. DynAPI is a programming tool/interface for creating
dHtml.
Now programming is the key word here. No matter what, you
still have to PROGRAM. If you would want to create a
simpler interface for creating dHtml (a WYSIWYG for
instance), there still has to be somone who creates this
interface, and I guarantee you, it won't be a designer! ;)
2. Having a SuperClass that provides basic OOP
functionality, would provide the PROGRAMMER with the tools
nessessary to create DynAPI with a lot more ease
(again,this is the goal of OOP).
For example, say that you would want to split up DynAPI per
browser basis and make this seamless for the end
programmer. If you would not have fundamental OOP
functionality in place, this would be HARD!
True, the SuperClass would have to be flawless and
completely without bugs for this premise to work.
But this is not impossible. I know, because I'm in the
finishing stages of creating a comprehensive SuperClass
myself (I might even create an opensource forum for it ;D )
SuperClass is, and should be, inherantly separate from
DynAPI, and you should be able to create whatever class
hierarchy you would want, including DynAPI.
So in closing, I hope that the coin will finally drop, and
what I've said to sing in ( i.e not just be flamed) ;)
Alea Jacta Est,
Bart
|
