The ProgressBar contribution uses a class of the qx.util.range name 
space, but not Range but IntegerRange (which is non-existent in 0.8). 
Anybody porting the ProgressBar to 0.8 will have to re-invent a range 
type if it is not provided by the framework.

The main point for me is that it seems to be a sensible thing to have a 
general range data type anyway. The ProgressBar and the Slider classes 
should make it obvious that a range type is a necessary thing to have in 
a comprehensive framework.

It is a special kind of iterator, where the objects you iterate over 
have a natural order. Iterators are such a common data types that many 
programming languages provide them per default, at least in the form of 
interfaces (e.g. Python).

So I would second keeping the qx.util.range.Range anyway. If you have 
such a class you should have it in the most generic way (which rules out 
qx.ui.form).

More specific classes should use the generic range class. I think it is 
a case of lack of proper abstraction that there is a range 
implementation in the qx.ui.form name space. qx.util is obviously much 
more general than qx.ui.form!

That said, the current implementation in qx.util.range seems to be 
rather deficient. You cannot specify a step width, nor does it have a 
next() method to iterate over the range. So it seems the only thing you 
can do with such ranges are inclusion tests, but not even for that is 
there a suitable method. For reasons I don't know, this range data type 
has been reduced to near uselessness.

So I suggest improving it to be a proper range type, and not 
re-implement similar functionality in special-purpose name spaces (like 
qx.ui.form).

T.

Martin Wittemann wrote:
> Oh, I forgot to mention that we have another Range interface in  
> qx.ui.form.IRange which could replace the util range interface. So  
> removing the interface is just a try to reduce the redundancy in the  
> framework.
> The Range class were used in the 0.7 line of qooxdoo for the spinner  
> and the progress bar. The 0.8 spinner uses its own, internal range  
> implementation now. So the only thing using this Range is the progress  
> bar in the contrib section.
>
> Martin
>
>
> Am 26.06.2009 um 10:51 schrieb Martin Wittemann:
>
>   
>> Hello,
>> we added a bug some time ago discussing whether we still need the
>> class and interface in the qx.util.range namespace.
>> (http://bugzilla.qooxdoo.org/show_bug.cgi?id=2476)
>> The namespace contains one interface and one class implementing that
>> interface.
>>
>> - qx
>>   - util
>>     - range
>>       - IRange.js
>>       - Range.js
>>
>> Perhaps someone in the community can give us a hint why we should not
>> deprecate the class and interface. Do you use this interface / class?
>> Regards,
>> Martin
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>>     
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>   

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to