Re: Automatic using ::rtl::OUString etc.

On Friday 13 of April 2012, Stephan Bergmann wrote:
> On 04/12/2012 03:59 PM, Lubos Lunak wrote:
> >   would somebody see a problem with this?
> >
> > sal/inc/rtl/ustring.hxx :
> > +#ifdef RTL_AUTOMATIC_USING
> > +using ::rtl::OUString;
> > +using ::rtl::OStringToOUString;
> > +using ::rtl::OUStringToOString;
> > +#endif
>
> I am not too excited about this.
>
> For one, we need to ensure that none of the URE published interface
> implicitly relies on -DRTL_AUTOMATIC_USING.  (And it is not clear to me
> that compiling the sal library with -URTL_AUTOMATIC_USING could even
> catch all problems in sal headers.)

 I think you are right about -URTL_AUTOMATIC_USING for sal not being a very 
good idea, it'd be better to just have one check .cxx that'd include 
everything in sal (and another one for URE, and whenever else needed), 
without having the #define in effect. That'd make sure no problem slips 
through if the file was automatically made to include inc/*.hxx , and a 
failure only in the one .cxx would make it more obvious why it fails.

> For another, it increases accidental complexity (an ifdef block; yet
> another -D always passed in) for IMO little gain.

 No, you see it backwards :). It reduces code annoyances for IMO very little 
price.

> And for a third, it introduces a magic special case (certain names from
> the rtl namespace can be used without qualification;

 Strings already kind of are a magic special case. They are the one 
non-builtin type that is by far the most used one, close to the builtin ones 
(which is part of the reason why many programming languages do have strings 
as a builtin type). So I see nothing wrong with trying to get them as 
conveniently usable as possible, as ::any::little::annoynance::there 
AddsUpNumerousTimesL BECAUSE_THE_THING_IS_USED_SO_OFTEN.

 I understand that this argument probably doesn't work that well with people 
who have already gotten used to all kind of quirks of a codebase that has 
managed to get even int and bool types complicated, since we simply have to 
get the work done somehow (and I said 'we', because I can already watch 
myself getting used to things I'd prefer not to), but that doesn't mean 
everybody has to suck it up until the end of time.

 As the strings are already namespaced by the name itself, I'd be open to 
alternate solutions such as moving them out of the namespace, but that'd 
break binary compatibility and the (probably only hypothetical) case of some 
other code using the name for something else.

-- 
 Lubos Lunak
 l.lunak@suse.cz