SV: [Dynapi-Dev] Next Generation 9

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

-----Ursprungligt meddelande-----
Fr=E5n: Henrik V=E5glin <hv...@ya...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 30 januari 2001 20:39
=C4mne: Re: [Dynapi-Dev] Next Generation 9



----- Original Message -----=20
From: "Barre Bizon" <ba...@ho...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 5:35 PM
Subject: [Dynapi-Dev] Next Generation 9


>=20
> Hey...
>=20
> I think most of you seem to be missing the point somewhat.=20
> Let me explain:
>=20
> There are certain reasons why languages such as Java and=20
> other OO languages have evolved. Stability,=20
> reusabilty/modularity, ease of use, security etc. Object=20
> Orientation exists because people wanted a way to easier=20
> abstract problems, and represent them in a more human-like=20
> fashion.
> Now what DynLayer tries to do is simulate parts of this=20
> whilst providing funcionality for robust, consistant and=20
> simple dHtml creation.
>=20

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.=20
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=20
> having some fundamentals already in place? Such as a fast,=20
> stable, easy and safe way of creating a class=20
> hierarchy/implementing basic OOP functionality.
> I mean, how long has this "current" release been in a=20
> debugging phase ??! Do you not think that this could have=20
> been avoided, atleast in part, by having a more stable=20
> coding ground to develop with?
>=20

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?  =20



> True, Javascript's prototype based OO provide some=20
> functionality for creating "classes". But this approach is=20
> inherantly slow, memory consuming and error prone, since=20
> some of the most fundamental OOP functionality is not=20
> supported (such as true encapsulation).
> Why go halfway, sort of do OOP, but not really, because=20
> it's too hard ? It's not! In the long run it's much=20
> simpler. Which is the exact point of DynAPI in the first=20
> place. There is a longer learning curve before you can use=20
> it, but when you do, your efforts are greatly simplified=20
> and accellerated.
>=20

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=20
> providing the remaining OOP functionality that Javascript=20
> does not inherantly support, so that you don't have to=20
> recreate the wheel everytime you develop somekind of=20
> application or extension to it.
> Pascals DynObject and Eytans SuperObject, are examples of=20
> what I'm talking about.
> DynObject provides better modularity for DynAPI, and a=20
> SuperObject would provide the tools with which to better=20
> build a more modular DynAPI (there are a couple of more=20
> people that have developed a SuperObject/SuperClass).
>=20

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=20
> bugs, and that you should rely on JavaScript's built-in way=20
> of handling OOP, and that this should be a API for=20
> designers, not for programmers and what have you...
> But this is simply not true.=20
>=20

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.=20

=20

> 1. DynAPI is a programming tool/interface for creating=20
> dHtml.
> Now programming is the key word here. No matter what, you=20
> still have to PROGRAM. If you would want to create a=20
> simpler interface for creating dHtml (a WYSIWYG for=20
> instance), there still has to be someone who creates this=20
> interface, and I guarantee you, it won't be a designer! ;)
>=20

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=20
> functionality, would provide the PROGRAMMER with the tools=20
> nessessary to create DynAPI with a lot more ease=20
> (again,this is the goal of OOP).=20

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=20
> browser basis and make this seamless for the end=20
> programmer. If you would not have fundamental OOP=20
> functionality in place, this would be HARD! =20
>=20

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=20
> completely without bugs for this premise to work.=20
> But this is not impossible. I know, because I'm in the=20
> finishing stages of creating a comprehensive SuperClass=20
> myself (I might even create an opensource forum for it ;D )
> SuperClass is, and should be, inherantly separate from=20
> DynAPI, and you could create whatever class hierarchy you=20
> would want with it, including DynAPI.=20
>=20

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.