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

[Hugo Beauzee-Luyssen]

On Mon, Jan 25, 2010 at 7:11 PM,  <jpd at videolan.org> wrote:
> 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.
>

No, i mean getter, like in "int value( int defaultValue );"
>
>> 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.
>

It's one thing to attack my lack of arguments, though I've expose
some, and my point stay the same : you have not.

> 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

There's too many case where a getter can take an argument for any
reason, as explained before. I don't really have much, but it's enough
to me, and judging by the other replies, not just for me.

> 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.
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>

Regards,

-- 
Hugo Beauzée-Luyssen