Editing Topic: RCR259 Project: RCR | RCRchive home

RCR 259: add begin= and end= to Range

submitted by tobi on Tue Jun 08 2004 08:23:01 AM -0700

Status: pending

Abstract

In addition to the begin and end methods of class Range, I could use begin= and end=

Problem

I need to change the begin and end of ranges, eg change a Range from 2..3 to 4..7 (the same object).

Proposal

Since I really do need and want this functionality, I implemented my own Range-like class, works like a charm (a bit too long to post though). But I thought that perhaps others might find begin= and end= useful too, that's why I propose to add them to the built-in Range class.

Analysis

[see above]

----
You say that you need this, but could you explain why?
I'm not against this rcr, but I want to understand if you see a general use/need for it apart from your specifric problem
--Gabriele Renzi

----
Whenever someone wants to change the begin or end of a range, then the methods begin= respectively end= are very useful. People ask arrays, strings, etc to modify themselves; changing the begin and end of a range object is a basic modification. In my scenario for example the range-like object (it would be a subclass of range if it had begin= and end=) is a line address of an editor; whenever the user enters a command to change the address, it adjusts it's begin and end. 
----
I don't accept the "people ask arrays, strings, etc. to modify themselves" argument.  I could equally say, "Fixnums are immutable, so why not Ranges?"  There's no obvious analogy in either case.

I think of ranges as almost like assertions: 0...10 is like a compact way of expressing the concept of "being >= 0 and <= 10".  I know there's more to it than that, but I feel like there's something illogical about a range changing.  How can "being >=0" change to "being >= 5"?  In that sense, the boundaries of a range define the range in a way that goes beyond how the elements of an array define the array.

I don't think creating a new range is a very expensive operation.  I'd rather see it kept the way it is.

-- David Black
----

> I don't accept the "people ask arrays, strings, etc. to modify themselves" argument.

Well, they do indeed.

> I could equally say, "Fixnums are immutable, so why not Ranges?"

I need a range which can set its begin and end, so I implemented a class which offers this. Since I believe that this is a generally useful functionality, I proposed this RCR. If people don't need begin= and end= then that's cool with me.

> There's no obvious analogy in either case.

But sure there is:

A Range is very similiar to an Array from a certain POV, and used like an array in certain scenarios.

Although Strings can be split into Arrays, strings aren't really Range-like, and I didn't say they would be. People ask Strings to modify themselves, and I need to be able to ask Ranges to modify themselves. Simple :)

As for the rest or your arguments: If you need ranges which are immutable assertions in your scenario then you simply wouldn't use begion= or end=, or freeze the objects, or undef the setters. Just as you would do when you need immutable arrays, strings, etc. I don't see any real problem with adding begin= or end= to Range, not significantly more potential trouble than with Array#[]= etc.

But again, if there's more demand then Matz will probably add those methods, and if there's not enough demand then he probably won't; I'm happy with my Range-like class/objects anyways.

-- Tobi

----
>> I don't accept the "people ask arrays, strings, etc. to modify themselves" argument.

> Well, they do indeed.

Of course they do; my point was there was no connection between this and the question of whether ranges should be able to modify themselves.  That's a separate question.

> A Range is very similiar to an Array from a certain POV, and used like an array in certain scenarios.

When you use to_a, you are getting an array, not a range.  You can use to_a on a Matchdata object, but you cannot therefore say, "Arrays have .concat, so why shouldn't Matchdata objects?"

So that was all -- I just meant that the raising of points about arrays and strings doesn't add up to an argument one way or the other about ranges.

-- David Black

----

> When you use to_a, you are getting an array, not a range.

yes, sure

I think the main problem is that you seem to have heard me say "Ranges should/must be mutable" although I didn't. Instead I said:

"In addition to the begin and end methods of class Range, I could use begin= and end="

"I need to change the begin and end of ranges, eg change a Range from 2..3 to 4..7 (the same object)."

"Since I really do need and want this functionality, I implemented my own Range-like class, [...]. But I thought that perhaps others might find begin= and end= useful too, that's why I propose to add them to the built-in Range class."

Just if others find this useful too (in which case it doesn't matter much if it "should" be modifyable or not).

"Whenever someone wants to change the begin or end of a range, then the methods begin= respectively end= are very useful."

I didn't say "Ranges should be mutable", but that I do need mutable Ranges (or Range-like objects), and that perhaps others might too.

If you did read too much into "People ask arrays, strings, etc to modify themselves; changing the begin and end of a range object is a basic modification." then know that there's nothing implied in this sentence; it just states that basic self-modifying methods are quite common ("etc" means all classes including those which aren't even remotely Range-like). Feel free to delete the sentence from you memory if it confuses you :) the RCR stands without it.

I think that adding begin= and and= to Range wouldn't hurt, but if people think it would and if they find Range-like objects with setters useful, then perhaps a new class would make sense.

Tobi

----
Add comments here:

Back to RCRchive.

RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog