Create Localizer factory method for LocaleMac
Created attachment 163288 [details] Patch
Comment on attachment 163288 [details] Patch ok
Comment on attachment 163288 [details] Patch Clearing flags on attachment: 163288 Committed r128156: <http://trac.webkit.org/changeset/128156>
All reviewed patches have been landed. Closing bug.
There is something wrong with the design here. How can a "Locale" class inherit from a "Localizer" class? How can LocaleMac::create return a pointer of a different type?
(In reply to comment #5) > There is something wrong with the design here. How can a "Locale" class inherit from a "Localizer" class? How can LocaleMac::create return a pointer of a different type? I will rename LocaleMac, LocaleWin, and LocaleICU to LocalizerMac, LocalizerWin, LocalizerICU in the future. LocaleMac, LocaleWin, and LocaleICU all inherited NumberLocalizer before I started working on this. And I renamed NumberLocalizer to Localizer. The grand plan is to collect all the localizer functions, not just number, into Localizer. Localizer::create will be used instead of LocaleMac::create to get the right instance for each platform.
I'm not sure if I'm in support of this direction. Class names should be nouns, and disguising a verb for a noun is rarely a sign of a good design. A class is a collection of data and methods, and it should be easy to tell from class name what the data is. On the other hand, a class with a name like "manager" or "localizer" doesn't really tell what its object oriented essence is.
(In reply to comment #7) > I'm not sure if I'm in support of this direction. > > Class names should be nouns, and disguising a verb for a noun is rarely a sign of a good design. A class is a collection of data and methods, and it should be easy to tell from class name what the data is. On the other hand, a class with a name like "manager" or "localizer" doesn't really tell what its object oriented essence is. How about LocalizedFormat, LocalizedFormatMac, LocalizedFormatWin, LocalizedFormatICU?