Re: SV: [Dynapi-Dev] Next Generation 9

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

OK, this is not to hide somehting from the debate, but
I'm going to cut a few things out of this response. I
f anybody hasn't read these, please go back in the
thread if you're confused of anything re-discussed and
not in this post.

BTW this isn't just to flame or anything, I think we
are coming along good to understand eachothers POV.


 --- Bart Bizon <ba...@ho...> skrev: > 
> -----Ursprungligt meddelande-----
> Från: Henrik Våglin <hv...@ya...>
> Till: dyn...@li...
> <dyn...@li...>
> Datum: den 30 januari 2001 20:39
> Ämne: Re: [Dynapi-Dev] Next Generation 9
> 
> 
> 
> ----- Original Message ----- 
> From: "Barre Bizon" <ba...@ho...>
> To: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 5:35 PM
> Subject: [Dynapi-Dev] Next Generation 9
> 
> 
I earlier wrote:
>[...] 
> There's reason why SCRIPTING languages like
> Javascript have evolved too 
[...]
>
---------------------------------------------------------------------------
> 

Bart replied:

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

My response:

Javascript prototyping is experimental coding. Does
this mean it's less valuble for developing? I vote:
not.


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

hehe, no I'm definatly not a superprogrammer, rather
the opposite. My point is rather on that it's not the
code that defines what you can do it, it's in the
programmers head. If the DynAPI developers in general
are more comfortable with the reform of code symantics
they should consider it. But AS IS the Next Gen
haven't showed off how this will be implemented. Work
out a model, some more working code and foremost -
document it extremely well. THEN the developers can
decide wheter or not it suits them and their purpose -
cause that's what's mostly driving this project. 

Might seem a long way to go, but as I've stated, these
things of evolvement should take time and establish
themselves before they make for the radical change.
DynAPI2 have taken 1 year to move this far from Dan
Steinman's original DynAPI 1. We should expect Next
Gen to consume at least the same time. In the mean
time I propose we stick to developing DynAPI2 in the
current direction. I can adapt Next Gen when its
established and if it prove to be as ease of use and
extensability (widget-building). Don't take me wrong,
I will help in any way I can to see how Next Gen come
off ground - as a side development. When it's fairly
ready for implementation, we can evalute it and
everybody can take stand on wheter to move their
development efforts there. I think the same goes for
any other new subprojet including my DynBuilder build.


> 
> The fundamentals was built on  dan steinman's DynAPI
> 1 build [...] 
> 
>
----------------------------------------------------------------
> 
> Yes, but this is not the foundation I'm talking
> about. [...]
> 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?   
> 

I'm of viking-blood, I can take a little cold of the
feet if it means I don't sink as soon as I get out on
deep waters, if you catch my drift ;) But really, the
metamorfos is like my point; just cause something
seems like the way to go, doesn't mean that it's the
best in every occation.
 
>[...] 
> I'm not saying that Javascript is not object
> oriented. It's just that it's lacking.
> 

In the words of Pascal: "where, why, and what?"
Provide an examplification please...

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

So why should we take this way. Work out the grounds
first, then step onto it if it really is more stable
 
>[...]
> 
> 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...... ) ;)

nah, you seem sane enough :)

> But your'e missing my point and getting hung up on
> semantics. 
> 

Then prove me wrong, just don't tell me I'm wrong,
cause I won't buy that - and neither should anyone
else in my opinion. I think this is what the
developers in control are waiting for - or as in
Pascal's case; doing.
  
> 
> > 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.

Yes, a designer is also a programmer in most cases. UI
development is more than just slick and neat graphics
- it involves user-interaction programming. Keep the
terms separated cause strictly said scripting is also
a form of programming even if simplified (and what's
so wrong about that?).

And I'm challanging you to have something to present,
something that evalutes how it works and how the code
behind is to be written. That's all...

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

Yeah, but what about the level of in-depth insight to
how it works. A project needs to be extremely
well-documented to not have that. I can't believe
something will work so well that I don't need to be
able to at least figuring out why it works if i'm to
build extensions. I'm a strong believer that the same
goes for the code behind as for the inteface in an
open source project, it should be "readible" even if
not down to it's core details. Once again (in risk of
being boring repeating) exemplify and show how it
works, before you propse the step to be taken. I know
the frustration in getting something done for sure,
but you can't keep crying for this kind of great
reformation unless you have the full grounds for
replacing the previous version (for example no one
actually officially joined in for the DynBuilder
project, though many talk big about its potentials -
no single out one meant)

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

Will split up? It's already fractioned, but somehow it
slowly binds together - and that's what's good about
it. That stated, there's no reason for contributors to
lean back, just that maybe it's sound to realise that
the volume of this project is in that state now and
that is how it works. I admire Robert for keeping it
all together as well as he does.

I wrote:
> 
> I have no comment on this but that its a matter of
> focus.
> 
>
--------------------------------------------------------------------------

Bart respondeed:
> 
> 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).
> 

Is it really better to have it diveded per browser?
This also means a lot of redundant code - which is
actually is moving away from OOM and the DynAPI
fundamental of cross-browser. See why I propose to
move casually on taking this step too hastily...?

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

Then develop it side by side till Next Gen is a
working model - ie established - then we'll see if
this or someone elses will be the way to move forward.
Are we finally on same grounds maybe? [open for
anybody to respond here]

Henrik Våglin [hv...@ya... ]

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/