I'm not keen on the idea of modifying built-in classes - AFAICR one of the
original strategies in Qooxdoo was to deliberately not modify the prototype
of built-in classes because of the potential for hard-to-debug conflicts
with other libraries which may be loaded.
OK, we're unlikely to load (e.g.) Prototype/ExtJS/Dojo as well as Qooxdoo
but it is common for contribs to pull in other libraries with their own
highly developed toolsets like TinyMCE/FCKEditor/etc, which means Qooxdoo's
polyfills could conflict and have compatibility issues.
It's a little bit more work to type qx.lang.Array.someFunction(myArray) but
personally I like the idea of being clear and explicit about where code
comes from, and keeping the methods in a separate class (e.g.
qx.lang.Function.bind for example) also makes it perfectly clear what the
implemention is and where to get documentation for it.
qx.type
I've checked our source and I've never used qx.type at all; it seems that
the Qooxdoo trunk hardly does either, and IMHO with a little refactoring it
could be removed altogether, even if this means some duplication of code
between a class in the testing framework and LocalizedString
John
On 22/07/2012 13:38, "thron7" <[email protected]> wrote:
> What I'd wish for would be a guiding principle that guides the class design.
>
> One such principle could be to keep extensions to built-in data types to
> dedicated classes. I think that was the rational behind qx.lang, so
> developers could use e.g. an instance of qx.lang.Array() in a place they
> would otherwise use the built-in Array() class. But if this rational is
> correct then I don't see the need for qx.type because if qx.type is about
> built-in types, it should go to qx.lang (And if it's not about built-in
> types then there should be more specific name spaces the code should go
> to).
>
> The dedicated qx.lang classes can provide a facade over their built-in
> counterparts, normalize behaviour of standard methods if necessary,
> provide polyfills for methods that are not available in all browsers, and
> offer convenience methods that are useful in application development (like
> String.contains or Array.clone as Derrell pointed out). That would also
> mean that a method like Date.toJSON should go into qx.lang.Date and not
> anywhere else.
>
> qx.lang classes could also have static methods that concern the particular
> data type but cannot be implemented on the instance level. Even if
> patching built-in classes, this code should go into the corresponding
> qx.lang class.
>
> But having dedicated facade classes in qx.lang would also rule out "grab
> bag" classes like qx.lang.Generics and qx.lang.Core. I think it's totally
> unintuitive what these classes are about.
>
> So, what I'm really missing is a compelling "story" behind the class
> design in qx.lang and qx.type. I think they should be merged into one
> namespace, as they both concern built-in types. A conceptual story (what
> is the namespace about, what is each class in the namespace about) would
> not only help in the clean-up process, but would also help any developer
> in using the class library.
>
> T.
>
>
>> Hello,
>> we have planed to clean up the qx.lang and qx.type namespace. With that
> clean up, we intend to move to polyfil as much as possible. That way, we
> rely on standardized APIs offered by the browser. So lets get started
> with
>>
>> qx.lang.Generics [1]
>> I would be surprised if a lot of developers know what this class is
> doing
>> and also use the features. In short, it takes most of the standard
> methods
>> of Array and String, and attaches them as static to the native data
> type.
>> Here is a sample of join for Array.
>>
>> Array.join([1,2,3], "|") // API offered by the class
>>
>> instead of
>>
>> [1,2,3].join("|") // native API
>>
>> We intend to remove the whole class because this is not in the spec as
> far
>> as I can see so we don't need to fake that as well.
>>
>> qx.lang.Core
>> This class already offers some polyfills. We like to rename the class
> and
>> extend it with newer polyfills like Date.toJSON and so on. Additionally,
> we intend to remove the "polyfill" for string.quote because its not in
> the
>> spec.
>>
>> qx.module.Polyfill
>> contains some polyfills needed for q. We like to clean up the content of
> that class as well.
>>
>> qx.lang.Array
>> offers some convenience on top of the native Array methods. But we think
> thats a but too much and we like to reduce the feature set of most of
> the
>> qx.lang classes. In the array class, we would like to remove the
> following
>> methods:
>> toArray: can be replaced with cast
>> fromCollection: we cant reproduce the bug its fixing
>> clone: its a simple concat
>> max: its available in Math
>> min: its available im Math
>> sum: easy to implement it yourself if needed
>>
>> qx.lang.Date
>> We want to remove the whole class because it only offers one method
> which
>> is available on the native Date object as well.
>>
>> qx.lang.Function
>> Here, we move / remove the following functions:
>> bind: will be available on every function as polyfill
>> empty, returnTrue, returnFalse, returnNull, returnThis, returnZero: will
> be removed without replacement
>>
>> qx.lang.Object
>> hasMinLength: is a simple check and getLength
>> getKeys: will be replaced by a polyfill
>> getKeysAsString: is a simple Object.keys + join
>> mergeWith, mergeCarefullyWith: can be replaced by merge
>> select: its a simple map[key] return
>> toUriParameter: Should be moved to URI or serialization
>>
>> qx.lang.String
>> contains: is a simple indexOf
>>
>>
>> Another part of the cleanup is the qx.type namespace, which contains
> four
>> classes. Two of them will be kept the way they are and thats BaseError
> and
>> BaseString. Both are in use for e.g. unit testing or localized strings.
> The other two classes are BaseArray and Array. BaseArray just offers an
> Array including the methods we want to add to the native Array so the
> whole class is kind of useless after that. This means, we want to remove
> the BaseArray. The Array class offers some of the convenience methods of
> qx.lang.Array on the array instance. This is somehow a duplicate of API
> and thats why we plan to remove this class as well.
>>
>>
>> Now its your turn! Do you have any objections on any of the planed
> removals? Any hints of what we should / could add as polyfill?
>>
>> Thanks for your help,
>> Martin
>>
>> P.S. By removing I mean deprecating it for the upcoming release and
> removing it after the release.
>>
>> [1] http://demo.qooxdoo.org/current/apiviewer/#qx.lang.Generics
>>
>>
----------------------------------------------------------------------------->>
-
> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond.
> Discussions
>> will include endpoint security, mobile security and the latest in
> malware
>> threats.
>>
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/____________________
>> ___________________________
> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
