Hi there,
I would like to propose the following:
In addition to the global qx object, a second global object "qxl" (for
qx-links) is added which has a flat list of properties which link to the
longer, namespaced version. Then users can use the simple link
"qxl.defineMain(...)" or "new qxl.Button()"
and trust that this will never change. When developers change the API,
they also update the link. So, developers who want to use the internals
of qooxdoo can do so with the full namespaced syntax, while users who
want nothing more than "get things going" and avoid breakage, can use
the simplified syntax.
This would also have the following advantages:
- nicer, shorter code
- probably a slight speed increase (because lookup of namespaced path is
shortened)
- API consistency
- Ideal for QxBuilder developers who can base the tag name syntax on the
shortcuts.
What do you think?
Christian
Sebastian Werner schrieb:
> [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
>
-------------------------------------------------------------------------
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
