Well as I was reading the archives and Jim Weirich's guidlines I saw an
accepted RCR for Integer#odd? Integer#even?
I always define Integer#pred for myself it seems so trivial that I did not
bother the list *on purpose*
I filed the RCR right away.
Sorry for breaking the rule it seemed appropriate.
But I was considering a second RCR and this one does by no means allow not
to consult the community.
I would also like to have
Integer#pred! and Integer#succ! doing the "obvious" of course.
x = 41
x.succ! => 42
x => 42
What do you think ?
Cheers
Robert
路路路
--
"The best way to predict the future is to invent it."
- Alan Kay
Well as I was reading the archives and Jim Weirich's guidlines I saw an
accepted RCR for Integer#odd? Integer#even?
I always define Integer#pred for myself it seems so trivial that I did not
bother the list *on purpose*
I filed the RCR right away.
Sorry for breaking the rule it seemed appropriate.
But I was considering a second RCR and this one does by no means allow not
to consult the community.
I would also like to have
Integer#pred! and Integer#succ! doing the "obvious" of course.
x = 41
x.succ! => 42
x => 42
What do you think ?
I don't consider that obvious at all. Integers are immutable, and
variables aren't objects -- so it doesn't fit the model.
That's also why Matz has never put x++ in the language.
Gregory Brown wrote:
>
> > x = 41
> > x.succ! => 42
> > x => 42
>
> This is probably in the same vein as ++.
>
> I don't like it because since integers are immediate values in ruby,
> that looks messy.
How about....x++ ?
I know, I know - it's pretty radical, but it's 2007. I think we're
ready.
Maybe x++. I'm pretty sure it can't be a method.
consider x.method(:succ!), letting x fall out of scope and then
invoking #call on that method. Ruby would have to realize it would need
to make a closure (unless we just had no unboxed values).
路路路
On Sat, Jan 13, 2007 at 03:25:06AM +0900, Daniel Berger wrote:
> On 1/12/07, Robert Dober <robert.dober@gmail.com> wrote:
Regards,
Dan
PS - Evan Phoenix did this for Sydney, so it's possible. Evan, got a
parse.y patch for us?
x++ in languages that implement it (PHP I'm sure of, Java and C++ I'm less sure of) increment x after running the statement. So:
# All of the ++s are how it would be in PHP/Java/C++
def printNum x
聽聽聽puts x.to_s
end
x = 42
printNum(x++) #=> 42
printNum(x) #=> 43
x = 42
printNum(x.succ!) #=> 43
printNum(x) #=> 43
++x increments before passing the variable:
printNum(++x) #=> 44
printNum(x) #=> 44
So even if this was implemented, I think x++ would be a bad syntax to x.succ! as other languages have something which looks exactly the same and yet does something different.
To be fair, that's a perfectly reasonable argument if ++ were to be a
method call. If it's to be programmer convenience for x += 1 (syntax
sugar for x=x+1) however, it could also be implemented as syntax sugar.
I'm personally perfectly happy without ++, but there are certainly ways
that it *could* be added to Ruby without violating the immutable
objects.
路路路
dbl...@wobblini.net wrote:
Even when it's 2007++ integers will still be immutable, immediate
values I much prefer having people have to learn that that's how
Ruby integers are.
Even when it's 2007++ integers will still be immutable, immediate
values I much prefer having people have to learn that that's how
Ruby integers are.
To be fair, that's a perfectly reasonable argument if ++ were to be a
method call. If it's to be programmer convenience for x += 1 (syntax
sugar for x=x+1) however, it could also be implemented as syntax sugar.
I'm personally perfectly happy without ++, but there are certainly ways
that it *could* be added to Ruby without violating the immutable
objects.
I don't think that's ever been in doubt (that the parser could be
trained to turn x++ into x += 1). But the reason Matz has always
given for not considering it appropriate is that in languages where
it's used it customarily indicates incrementation, rather than
reassignment to a variable. So using it for assignment would
potentially be misleading.
I was not aware how that RCR has to be interpreted, I meant something else.
David (and Gevin in a private mail I did not understand very well, apologies
Gevin) was very right when saying it is not obvious)?
x=42
x.object_id => 85
x.succ!
x.object_id => 87
and that would be a great mess I guess, Integer#succ! would need to know the
binding as someone put it,
would violate at least one paradigm of OO design (a method changin the scope
of the caller) etc. etc.
Funny how innocent it looked.
Sorry for having wasted your time.
But the good news is I do not feel like RCR anymore
Cheers
Robert
路路路
--
"The best way to predict the future is to invent it."
- Alan Kay
I much prefer having people have to learn that that's how