On Thu, Sep 14, 2006 at 09:59:01AM +0200, Lars Gullik Bjønnes wrote:
> 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.
FWIW I agree with Lars here. I think that we should follow the motto
"don't fix it if it ain't broken".
--
Enrico
