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
