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. Stability,
reusabilty/modularity, ease of use, security etc. Object
Orientation exists because people wanted a way to easier
abstract problems, and represent 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 true 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 to have 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
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 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 someone 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 could create whatever class hierarchy you
would want with it, including DynAPI.
In closing, I do hope that what I've said will infact sink
in, and not just be flamed ;)
Alea Jacta Est,
Bart
PS. I apoligize if this mail is doubled, my mail client
seems to have flaked out on me DS
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
