[PATCH] Make tooling::Range more convenient.

[Manuel Klimek]

On Fri, Jul 19, 2013 at 12:27 AM, Guillaume Papin <
guillaume.papin at epitech.eu> wrote:

>
>   Sorry to "re-up" the subject but I was wondering if adding
> `getBegin()/getEnd()` is really a no-no?
>
>   You said:
>   > offset + length is easy to write; if we think we need end more often
> then length, we should add end and remove length
>
>   But it's actually a bit longer to write:
>
>     Foo.getOffset() + Foo.getLength()


>   I'm writing some functions that checks if two ranges overlaps, are
> contained one within another, are in contact, ...And either the conditional
> looks a bit ugly or I end up creating a lot of 'range-end' variables like:


>     unsigned RHSEnd = RHS.getOffset() + RHS.getLength();
>     if (LHS.getOffset() > RHSEnd)
>        ...
>
>   IMHO `getEnd()`, and the `getBegin()` counterpart, wouldn't hurt
> readability.
>

This is obviously subjective, but I think the increased length here is not
important enough to merit introducing more code in a more commonly read
location.


>
>   I don't see why it would be necessary to remove the offset/length if
> begin/end are introduced though.
>

Simplicity.

Obviously those design decisions are subjective and debatable. I strongly
believe in the "one way to do something" in interfaces (as well as in
programming languages ;) (also note that I use the term "interface" pretty
loosely here to refer to the API of a class).

I think a class (especially a common value class like "Range" in a
refactoring interface) should have the most commonly useful functions to
expose its values, and then
a) code will be a little longer if that's not the "exact" fit
b) if there are enough places where it's not the exact fit, create
functions to convert the values
I think changing the interface to allow access to redundant information is
almost never the right answer.

To go a little deeper into this:
I expect the Range class to be read much more often than, for example,
functions that determine whether ranges overlap.
I also believe that having more functions on an interface leads to
developers taking longer to understand that interface, thus being slower
developing code against it.
Thus, I try to push complexity as far up as possible, to the point just
before there would be "too much" duplication introduced.

On a different note, I think that checking whether ranges overlap would be
a nice fit either for the Range class itself (as it exposes new useful
information, and I think there are enough cases where I want to check
whether they overlap), or as freestanding functions.

Hope I made some sense ;)

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130719/8e61315d/attachment.html>