----- Original Message -----
From: "Barre Bizon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 30, 2001 5:35 PM
Subject: [Dynapi-Dev] Next Generation 9
>
> 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.
>
There's reason why SCRIPTING languages like Javascript have evolved too - ease of use
and implementation! From another point of view - for example a designers - it is as
much or more valuble.
> 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?
>
The fundamentals was built on dan steinman's DynAPI 1 build - that's probably what
kept the development of DynAPI 2 together through its establishing phase. There are
fundamentals in the DynAPI 2 as it is, even if they're everchanging and more losely
bound in the collaborated understanding of the developers interacting on its
development.
> 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.
>
You're comparing apples with oranges. Prototyping is just another flavor of a OO-based
technique - reread your OO system analysis book and you will see it fits, no matter
what you're programming gurus tell you.
> 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).
>
They are great ideas and soloutions for sure (I actually admire those who can realise
these), but is it the only way to go? Is it the only thing desirable? is it waht
everyone desires? You're of course free to convience anyone, but don't think you know
the one and only best soloution - cause there are none that works for everyone...
> 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.
>
>From a oneway developer view maybe (no offence meant)
> 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! ;)
>
I challenge you there, cause I've already begun to build a DynBuilder for WYSIWYG
DynAPI development. Andd it's not wheter to do programming or not I'm discussing -
it's the level of advanced programming that I simple think something called an API is
meant to avoid (its in the name for christs sake!!! ;)
> 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).
Sure, but then agaian I'm not voting against this development - I just propose to not
move the current DynAPI in that direction, but rather to split up the builds of Next
Gen and the current DynAPI, which - again to be clear - is an API. API means
Application Programming Interface - not Advanced Programming Interpretor.
> 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!
>
I have no comment on this but that its a matter of focus.
> 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.
>
See, this technique too has its flaws - its not all fortune and glory to restructure a
project, it has to move slowly in a focused direction. In DynAPI's case I figure it's
a anarchy of different minds dragging in different direction - hence it's as flexibel
as it is. Actually I think the mix of control VS anarchy combined with at least a few
determmand mind is what's in its sucess to gotten as far as it has.
> In closing, I do hope that what I've said will infact sink
> in, and not just be flamed ;)
>
Sink in as convinece - no - but I respect your oppossed point of view. I think though
that way too many reason like you, and that's why projects go down, because people
always figure new beginnings are the one method to improve (I've got a lot of
experience of this in totally different kinds of projects). DynAPI is well established
with a lot of developers as is, not to mention the user-base. A total remake will turn
all that on end an there's nothing that can make certain how that will turn out.
(BTW if you flame me, I give my self the right to return the same, but I will keep
within the line as long as you too keep it down to issue.)
> Alea Jacta Est,
> Bart
>
> PS. I apoligize if this mail is doubled, my mail client
> seems to have flaked out on me DS
>
Luckily it came through only once ;) - nah, I'm only teasing you, it was pretty well
reasoned at least...
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
