You are asking that everyone contribute to the documentation and many have jumped in head first and are doing a great job at it. But if you keep changing the API, the documentation they are creating will be for not. A quick example would be the borders. My application was working fine and if I had written a bunch of docs on how to create and use borders, my docs would have been rendered useless a couple of days ago when the borders API was changed. All of a sudden, I had a flat app with no borders. I had to look through code to figure out what changed and then go into my code and make all the changes just to get back to where I was. I didn't see any real reason for the change.
So making API changes effects not only developers but all the people you have writing docs for you. When we get to a release point for .6, there will be no way to know if the docs are correct if you keep changing the API along the way. Even a tiny change will cause programs to stop working and already written documentation to erroneous.
Just my $.02
Thanks,
Jim
On 8/16/06, Christian Boulanger <[EMAIL PROTECTED]> wrote:
Hi, I would support Derrell.
I have already said that the "moving target" nature of qooxdoo creates
many problems for developers to build applications along with the
development. Yes, I know it is not 1.0 and yes, I recognize the need for
optimization etc. etc. and lastly, I do recognize that the main developers
need to work efficiently and cannot discuss everything... but I would be
extremely careful about API changes that break other people's existing
application (If that is the case, I don't know).
It would be less of a problem if you keep the API by internal shortcuts -
you could add a function that marks the API call as deprecated while still
maintaining funtionality. This could be cleaned up later.
But most importantly, I support Derrels point to keep function names as
short as possible and not get too enthousiastic about the namespace model.
_javascript_ is not Java. If you provide shortcuts from the qx root or at
most from qx.foo, I'd be more convinced...
Christian
> [EMAIL PROTECTED] writes:
>
>> - qx.core.Init.defineMain(function() {
>> + qx.core.Init.getInstance().defineMain(function() {
>
> Sebastian, I've been looking at your numerous recent singleton changes
> which
> affect every application and developer of qooxdoo. You are adding levels
> of
> indirection that are entirely superfluous, for the sole purpose, it seems,
> of
> making it more difficult for the developer to use qooxdoo. We should be
> providing ways to REDUCE the number of internal class references needed to
> be
> known by the user, not INCREASE them as you're doing.
>
> Instead of changing from
> qx.core.Init.defineMain()
> to
> qx.core.Init.getIntance().defineMain()
>
> if we're going to make a change at all, it should be something more
> towards
> qx.defineMain()
> not the other way around as you've done.
>
> Similarly for all (hundreds?) of the other classes that you changed to add
> a
> requirement for a getInstance() call.
>
> I don't believe that there was anything wrong with the previous method of
> creating singletons, and it was much easier for the user to work with than
> having to call getInstance() each time. In fact, there's no reason for
> the
> user to even have to know, in many (most?) cases, that he's working with a
> singleton.
>
> PLEASE, PLEASE, PLEASE "discuss" before "doing". Big changes like this
> should
> not be a one-person decision, particularly when it effects each and every
> qooxdoo application and developer like this does.
>
> Developers, please chime in here. If you all think that these changes are
> "good", "useful" and/or "necessary", say so. If you think that this is
> going
> in the wrong direction, we need to hear that too. Maybe I'm not speaking
> for
> the community, so let's hear from y'all.
>
> Cheers,
>
> Derrell
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
