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

[jpd at videolan.org]

On Mon, Jan 25, 2010 at 05:08:19PM +0100, Hugo Beauzee-Luyssen wrote:
> 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 ?

That is neither what you claimed nor what I asked you to about. I think
you'll find that if you look at how C++ came into being, "improving
readability" was far from its sole design goal.


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

And how would that be different from a getter/setter pair not also being
an operator?


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

ITYM `setter' there. You could do the exact same thing in the
example above. In fact, that also happens. It all hinges on semantic
expectations and they aren't that different accross the two examples.
Thus, if you accept one, then why don't you accept the other?
Explain please.


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

Yes, it could be, which is why it is possible. But these wrapper objects
aren't ment to be smart pointers. Quite the opposite, in fact.


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

Very well played, sir. A good substitute for lack of arguments of your own.

Symmetry, readability, conciseness. Yes, I know ``readability'' was
your argument against, but you didn't quite manage to back it up
convincingly. Conciseness because I dislike stating the obvious solely
for redundancy's sake. If you want that, there's always libvlc which
works just fine as is from C++, thank you. And it doesn't use those
pesky "C++ features", that are either there to improve readability
or to not be used, according to you, depending on what time it is.
The semantic argument against I also think moot, and if there's any
question of possible confusion it can easily be cleared up with the
docu-comments; a good reason to not only jot down some for the sake
of ticking a box, but write them well.