Re: [Dynapi-Dev] Next Generation 9

[<hv...@ya...>]

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

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

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

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

> 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)

> 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!!! ;)

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

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

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

> In closing, I do hope that what I've said will infact sink=20
> in, and not just be flamed ;)
>=20

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

(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,=20
> Bart
>=20
> PS. I apoligize if this mail is doubled, my mail client=20
> 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