<div dir="ltr">On Fri, Jul 19, 2013 at 12:27 AM, Guillaume Papin <span dir="ltr"><<a href="mailto:guillaume.papin@epitech.eu" target="_blank">guillaume.papin@epitech.eu</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Sorry to "re-up" the subject but I was wondering if adding `getBegin()/getEnd()` is really a no-no?<br>
<div class="im"><br>
  You said:<br>
  > offset + length is easy to write; if we think we need end more often then length, we should add end and remove length<br>
<br>
</div>  But it's actually a bit longer to write:<br>
<br>
    Foo.getOffset() + Foo.getLength() </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  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: </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    unsigned RHSEnd = RHS.getOffset() + RHS.getLength();<br>
    if (LHS.getOffset() > RHSEnd)<br>
       ...<br>
<br>
  IMHO `getEnd()`, and the `getBegin()` counterpart, wouldn't hurt readability.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  I don't see why it would be necessary to remove the offset/length if begin/end are introduced though.<br></blockquote><div><br></div><div>Simplicity.</div><div><br></div><div>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).</div>
<div><br></div><div>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</div><div>a) code will be a little longer if that's not the "exact" fit</div>
<div>b) if there are enough places where it's not the exact fit, create functions to convert the values</div><div>I think changing the interface to allow access to redundant information is almost never the right answer.</div>
<div><br></div><div>To go a little deeper into this:</div><div>I expect the Range class to be read much more often than, for example, functions that determine whether ranges overlap.</div><div>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.</div>
<div>Thus, I try to push complexity as far up as possible, to the point just before there would be "too much" duplication introduced.</div><div><br></div><div>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.</div>
<div><br></div><div>Hope I made some sense ;)</div><div><br></div><div>Cheers,</div><div>/Manuel</div><div><br></div></div></div></div>