please don't!
if you need an additional "flat namespace" for QxBuilder, it is no
problem to define shortcuts in an additional layer.
but i don't think it is a good idea to make an additional API in the
core framework. "there is more than one way to do it" should not be a
solution.
</usc>
Quoting Christian Boulanger <[EMAIL PROTECTED]>:
> 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
>
-------------------------------------------------------------------------
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
