Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
| >> I am tempted to convert everything even when a std::string would
| >> suffice. For example getFormatFromContents(), should that be:
| >>
| >> lyx::docstring const getFormatFromContents(lyx::docstring const & name);
| >>
| >> or
| >>
| >> std::string const getFormatFromContents(lyx::docstring const & name);
| >>
| >> I guess the format name could stay with std::string but this would
| >> not bring a big performance advantage. The first solution
| >> (docstring has the advantage that it looks nicer and we won't need
| >> to convert that to docstring if we need to display that format name
| >> somewhere.
| >>
| >> What do you think?
| > I am pro docstring everywhere execpt on the outer rim (i.e. GUI/IO).
| > Too much hassle to keep track of correct usage otherwise.
|
| You have a (strong) point here and I am close to think the same. Georg
| idea is to encapsulate strings which are really meant for display
| consumption in a class. I suggest that even those would use docstring
| instead of std::string. This is the compromise I can think of: clear
| compilation-time distinction and easy manipulation with other
| docstring if needed.
|
| class KeyString
| {
| public:
| typedef lyx::docstring name_type;
| };
|
| In the format case, this would mean:
|
| class Format: public KeyString {};
|
| For the menu backend and the dialogs this could be
|
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
We are not in such a hurry.
| Please speak-up if you don't agree with that.
I am not sure that I agree with Andre (or you) that we have to use
docstring all over internally.
Neither am I sure it is wise to introduce a myriad of "new" string
types.
--
Lgb
