Project

General

Profile

Bug #1705

backward compatiblity of locale()

Added by Boris Nagaev over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Start date:
02/16/2013
Due date:
% Done:

0%

Estimated time:

Description

Hello!

In Wt 3.3.0 new class WLocale was added. It supports construction from string. Please, add convertion to string to class WLocale.

I want this old code working:

std::string locale = wApp->locale();
...
wApp->setLocale(locale);

Otherwise no code compatible with both Wt 3.3.0 and 3.2.3 can be written (without preprocessor magic).

ЗЫ Backward incompatibility is evil.

#1

Updated by Koen Deforche over 7 years ago

  • Status changed from New to Feedback

Hey,

I'm reluctant to add this to WLocale --- you can work around it using #ifdef's and I would be surprised that you have many places where you are checking the locale yourself ?

It's a trade-off (backwards compatibility versus API detoriation) and trade-offs are open for debate.

Regards,

koen

#2

Updated by Boris Nagaev over 7 years ago

Hello!

Conversion to string does not seem to create a problem in future.

There are some apps, where user can change locale and locale is saved in database or in cookies. When the app is opened again, selected language is used instead of one reported by browser. To implement this, I need string value of locale.

In case conversion to string would not be added, I will be to add WLocale class detection in cmake (which would be correct, but unwanted), or ugly and buggish checks based on Wt version right in source sode (for non-cmake projects).

#3

Updated by Boris Nagaev over 7 years ago

3.3.0, RC2 was released. Please, include string operator for WLocale in 3.3.0 final.

#4

Updated by Boris Nagaev over 7 years ago

bump

#5

Updated by Koen Deforche over 7 years ago

  • Status changed from Feedback to InProgress
  • Assignee set to Koen Deforche
  • Target version set to 3.3.0

Hey Starius,

I'm willing to add this operator as a deprecated (backwards compatible) feature. It's too error prone moving forward and thus we will be eliminating it out some time in the future. I'm not too sure what's buggish about an #if WT_VERSION < 0x030300 ?

Regards,

koen

#6

Updated by Boris Nagaev over 7 years ago

Hello,

thank you. Deprecated operator is fine too.

By the way, true way of adding WLocale class was to add methods, setting and getting WLocale object and call them from locale() and setLocale(). In that case API would be clean and backward compatibility (even binary backward compatibility) would be kept.

Version checking is generally less flexible, than feature checking. For example, if you add deprecated string operator to WLocale, it would not affect version checking, but would affect feature checking. Feature checking here is compilation test of std::string locale = wApp->locale();

#7

Updated by Koen Deforche over 7 years ago

  • Status changed from InProgress to Resolved
#8

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF