-----Ursprungligt meddelande-----
Från: Henrik Våglin <[EMAIL PROTECTED]>
Till: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Datum: den 30 januari 2001 20:39
Ämne: Re: [Dynapi-Dev] Next Generation 9
----- 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.
---------------------------------------------------------------------------
True. Don't get me wrong. I love scripting in Javascript, loose typing and all that
jazz.
But this is not my point. I'm talking about implementing consepts that are not hard to
use, but eliminate a lot of potentially "bad" code.
Scripting languages are easy to work with, yes, but when projects evolve into the
level of complexity that DynAPI has, it actually becomes a drawback in certain cases.
I'm sure you have spent more than one occasion wasting hours on end trying to find
that little but oh so annoying bug ;) Now I'm not saying this will happen
automagically just because you stick to Javascript's own inheritance scheme. You might
be a superprogrammer that never makes any errors :) But since not all of us are, it is
vital to have a good foundation for programming with.
And as great as JS is, I believe it can be improved upon.
> 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.
----------------------------------------------------------------
Yes, but this is not the foundation I'm talking about. Granted that DynAPI is great,
and has a lot of functionality that greatly simplifies and adds to dHtml creation. But
the more you add to it, the more complex (and often slower) it gets. This, however,
would be minimized if the stomping ground would be stable. Yes, proper OOP gives you
heavier shoes to wear, but the shoes are there for a reason; to protect you from the
cold, right? You wouldn't climb a mountain (read:.DynAPI) , without proper shoes
(read:OOP), now would you?
> 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.
------------------------------------------------------------------------------
I'm not saying that Javascript is not object oriented. It's just that it's lacking.
> 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...
-------------------------------------------------------------------
Correct, this is not the only way to go. I believe that it is a very sound way to go.
But this is only my opinion obviously.
> 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)
------------------------------------------------------------------------------
Yes this is obviously my opinion. If I still am sane enough to know that I'm only one
person ( I don't think I'm schizofrenic yet...... ) ;)
But your'e missing my point and getting hung up on semantics.
> 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!!! ;)
----------------------------------------------
Challenge me on what, have you not programmed when doing DynBuilder?
Are you a designer, not a programmer? What are you saying?
I'm using the term programmer and designer strictly. But obviously a designer can be a
programmer and vice versa.
The concepts I'm proposing wouldn't change the end programmers utilization of the API.
At all.
It would even simplify, second level developers (i.e. people not developing the actual
core, but doing widgets and that sort of thing)
> 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.
----------------------------------------------
Right, I'm not saying this functionality should be inherent in DynAPI. It should be
external and you should be able to use it for creating whatever you would want... I
foresee that DynAPI will probably be split up sooner or later. There probably are a
lot of you already modifying it for own purposes.
> 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.
--------------------------------------------------------------------------
Yes it is... so we should focus on it :)
I believe that dividing up he code per browser basis is the best solution.
More browsers will come ( a beta of IE6 has already surfaced), and it would simplify
things a lot if you could add code for another browser without touching the current
code. Otherwise you're stuck with making a fix for one browser, and then checking if
it has broken in any other browser, and repeat. This will be implausible as the
browser list grows (depending on how backwards compatible you want to be).
> 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.
---------------------------------------------------------------------------------------------------------------
Yes, the DynAPI is amazing, Nodoubt about it. But I, as most, want to make it even
better.
What I'm getting more and more, is that it probably has to be split up. Which is not a
bad thing nesseccarily. It could be a joint venture, preserving DynAPI's current
object model and developing it further, and having another opensource forum with
people trying to rebuild it, structuring it up in a more, strict, OOP way.
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
