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

[jpd at videolan.org]

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?


> 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;

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.


> 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 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.