[EMAIL PROTECTED] schrieb:
> [EMAIL PROTECTED] writes:
>
>> - qx.core.Init.defineMain(function() {
>> + qx.core.Init.getInstance().defineMain(function() {
Hi Derrell,
>
> 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.
I just repeat what Izaak had written before: >> Of course every sane
developer agrees that "new development should not be to make things
harder". <<
It's not our wish to make things more complicated. But sometimes it's OK
to increase the complexity to make the usage of the library more
intuitive and logical.
The singletons before were stored onto the class itself (the instance of
qx.core.Init was saved directly in qx.core.Init, overwriting the old
qx.core.Init constructor). The class was afterwards not easy accessible
anymore. This is not a good idea for several reasons, but the major one
is, that it doesn't allow you to easily extend such a singleton class
anymore.
Our themes (colors, icons, ...) for example are singletons, too. With
the previous solution it was not easily possible to inherit from an
existing color theme to just overwrite 2 of the dozen colors. Now this
should be possible.
>
> 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.
qx.defineMain() would break our current idea to store all functions
inside Classes. One thing we could do however, is, to move qx.core.Init
one namespace up e.g. qx.Init.getInstance().defineMain()
>
> Similarly for all (hundreds?) of the other classes that you changed to add a
> requirement for a getInstance() call.
The singletons were changed and the examples were modified. Nothing
more. Just 25 classes of our ~250.
>
> 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.
Yes, there is no reason for the user to know. And this is maybe really a
negative point. But it's more logical that, in the case of a singleton,
the class itself could also be found under it's classname.
getInstance() is also a known paradigm from Java and other high-level
languages. So this is no new invention of us.
>
> 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.
I think we have already mentioned this before, but I like to repeat it
again. Large decisions like this are no one-man show. We have discussed
this before and brainstormed about a good solution. The current version
is a result of the discussion of Andreas, Til and me. I'm sorry, but I
think we have a bit stress currently. In the future we will try to point
our ideas to the mailing list before changing major stuff like these.
This however doesn't mean a longly discussion of each change, but is
meant to give the developer a chance to be warned before updating the
repository. We care about you.
We have also discussed if it's maybe a good idea to create a mailing
list "qooxdoo-changes" or a separate blog like with RSS support to
announce changes to the users.
>
> 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.
I convinced that these changes were good changes. But I also understand
the users of the previous SVN versions. Yes, sometimes it's complicated
to bring your application up-to-date with the development branch. We
hear the same tones in our own projects. But I think the most time the
changes are an improvement. And I think it's better to change stuff like
this now, than doing it in a minor release sometimes later.
The trunk is currently under development and there isn't already a
version 0.6 out. Many people already use the trunk as development
platform, especially for new projects. And this is maybe a good idea.
But as in previous versions one of our highest priorities is to keep the
API of the following minor releases compatible. But this also means we
must do these changes as early as possible before releasing the major
version. So please forgive us the changes. We just couldn't wait until
0.7 with this.
Cheers,
Sebastian
>
> 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
