RE: API change proposal - deprecate ucol_openVersion

[Vladimir W. <we...@jt...>]

Yves, Wladislav & William,

Thank you for reading and thinking through our proposal. We have tried very hard to allow for a more dynamic or run time support for different versions. However, it turned out that all the other approaches would either dramatically increase the footprint of the library or decrease performance or be very error prone, as it would involve manual branching of the code - we felt that it would not work properly. 

Therefore, instead of doing nothing, we decided to allow for renaming of the library functions. This is a relatively simple solution which can be carried on automatically and safely.

Let me briefly try to answer the questions/suggestions:
- Can we live without urename.h? Yes, it is included only once, in utypes.h - remove that line, and you'll have old ICU library names unless you want to use some of the deprecated functions.
- How to use it? See icu/source/samples/legacy for a sample project that uses two versions of ICU simultaneously.
- The run time solution is much better and we cannot use this hack! The sample above shows that you actually can do it. It does require more work on the part of the developer.
- ucol_openVersion worked simply and smoothly. Why do you want to remove it? The fact is, it worked too simply - please examine it's implementation in ICU 1.8.1. At one point in time, we thought that it was a great idea and that is why we included a place holder function. We were wrong.

This is not to say that run time versioning support is forever banned from the ICU. If you desire, please develop a good framework and we will be very happy to review it and include it in the future releases of ICU.

Thanks,
V.

-- 
Vladimir Weinstein, IBM GCoC-Unicode/ICU  Cupertino, CA,  we...@jt...

Yves Arrouye writes:
 > Yves,
 > 
 > > What we decided to do is to allow for using different 
 > > versions of ICU on compilation module basis. A generated 
 > > renaming header file was introduced 
 > > (common/unicode/urename.h), which ensures that different 
 > > versions of ICU have different entry names. 
 > 
 > I see. Just checked out the urename.h. Good old #define hacks.
 > 
 > I still think, though, that it would be a great feature for collation to be
 > able to work with many different versions at the same time. Because this is
 > very likely to happen, as I said: store collation keys w/ version info, do
 > it again later, do it one more time, and you may have many different
 > versions of collation that you need to use.
 > 
 > > From ICU2 on you'll be able to easily use all the newer 
 > > versions of ICU together with one older version. Using more 
 > > than one older version would require some user side work.
 > 
 > I am not even sure how that works: say I use ICU 2.0 and want to manipulate
 > collation keys from 1.9 or whatever. What can I do? Am I supposed to link
 > with two different libicuuc, one that would have ucol_open_1_9 and another
 > would have ucol_open_2_0? Does that mean that these libraries may have to be
 > renamed and/or symlinked so that the linker won't be confused? What about
 > the sonames? I am sure you thought through all of that and it will work, and
 > will it also work for Unix distributions that include IUC as a system
 > service?
 > 
 > I was very excited about seeing support for using different versions of
 > collation in ICU, and was ready to have our system change to store collation
 > keys directly. But I do not think that this new scheme is going to allow me
 > to do that (and recollating is not an option on hundred of millions on
 > rows), it does not look to offer the flexibility one will need to freely
 > manipulate archived collation data.
 > 
 > Are you open to reconsidering this? Is anybody on the list willing to help
 > making this (direct support for many versions of collation) happen? (You
 > know, open source, contributing code... I am a bit ashamed of asking knowing
 > I won't be able to do that this time, but I am sure we have many ICU users
 > and potential developers here).
 > 
 > YA
 > _______________________________________________
 > icu mailing list
 > ic...@os...
 > http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
 >