dynapi-dev

[Dynapi-Dev] Next Generation 9

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

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

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

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 someone 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 could create whatever class hierarchy you 
would want with it, including DynAPI. 

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

Alea Jacta Est, 
Bart

PS. I apoligize if this mail is doubled, my mail client 
seems to have flaked out on me DS

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