[vlc-devel] commit: New C++ binding for libvlc. ( R?mi Duraffort )

[Hugo Beauzee-Luyssen]

On Mon, Jan 25, 2010 at 4:50 PM,  <jpd at videolan.org> wrote:
> On Mon, Jan 25, 2010 at 03:59:37PM +0100, Hugo Beauzee-Luyssen wrote:
>>
>> C++ features are meant to improve code readability.
>
> Oh, is that all they do? Cite, please?

You really want me to cite c++ features that improve readability ?

>
>
>> Personnaly, when i'm reading "time" and not "setTime" i think it's a
>> getter. Relying on a c++ feature to decide whether this method is a
>> getter or a setter seems wrong to me.
>
> Ah, personal taste. Sure, valid argument as far as that goes, provided
> you present it as such. I don't agree with your sentiment, though, and I
> seem to not be the only one. Compare
>
>  T &operator[](size_t);
>  const T &operator[](size_t) const;

The behaviour doesn't change here, it just selects the right constness.
(I know one can say that the behaviour changes along with the
constness by i think you get my point)

>
> as used in, for example, various STL containers. If I'm reading
> value = time(); then that's probably fetching something, and if I'm
> reading time(value); then that's probably setting something. But that
> might be me.
>

That may be a getter that stores the value in a reference. It also can
be a getter with a default value.

>
>> The seriously tricky c++ feature you're talking about are just here to
>> avoid calling getInstance every now and then, which (I think), improve
>> code readibility with c++ features, unlike having a getter/setter
>> method.
>
> I think that once you get bitten hard enough you'll happily forego the
> ``now and then'' advantage to save a couple nights tearing hair out.
> You could venture and google around for GOTM and C++faq lite and so on,
> there are some interesting tidbits to be read about that.
>
>
>> As far as I'm concerned, a c++ feature used to avoid typing "get" and
>> making the code less obvious at the same time is a wrongly used c++
>> feature.
>
> Could say the exact same thing about casting operators and avoiding to
> type something eerily similar, in fewer places.
>

I agree if the cast operator is used in a bad way. If it requires you
to explicitely cast your value to have the required behaviour then it
has to be trashed. However, in some cases, it can really improve the
code (when using smartpointer, for instance)

> I have used casting operators too, mind, but sometimes it's much easier
> not to use them, especially in classes that are ment to underpin others
> and not ment to export private data to all and sundry.
>
>

To get back on topic, I don't see any reason to remove the set prefix,
and i didn't see any arguments that might help me think that's a good
idea.

-- 
Hugo Beauzée-Luyssen