Re: RE: [Dynapi-Dev] Next Generation part II

[Barre B. <ba...@ho...>]

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