On Sun, Nov 8, 2009 at 12:32 PM, Tony A. [email protected] wrote:
I cannot begin to answer this question because Ruby is doing strange and
unexpected things here, at least from my perspective…
Never mind, bar= was still defined because I was reopening the class.
So to answer your question:
array_example.length++
…would attempt to rebind through #length=, and fail if it weren’t
defined.
On Sun, Nov 8, 2009 at 1:15 PM, Walton H. [email protected]
wrote:
Incorrect. In fact the very first message in this thread provided an
example of redifining Fixnum in such a way that it was mutable.
No it didn’t, that post created a new class called “FixNum”
And again, that’s beside the point, which is to allow the expected “++”
semantics for immutable Numerics while also allowing in-place
incrementation
for other classes which may store a mutable value, such as counters
(whose
backing store may be a database, memcache, etc)
That would provide a truly Ruby-like ++ experience, aside from the fact
you
can’t redefine #++ for a Numeric, which probably isn’t a good idea
anyway.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tony
No it didn’t, that post created a new class called “FixNum”
I apologize, you are correct that post defined a new class, due to a
capitalization error, which was corrected a few posts down.
The point is, yes indeed, numerics can be mutable. I could if I were
so inclined write a String backed subclass of Numeric which represtend
integers as Roman Numerals and was mutable, (or Fixnum backed if we’re
feeling boring).
And again, that’s beside the point, which is to allow the expected “++”
semantics for immutable Numerics while also allowing in-place
incrementation
for other classes which may store a mutable value, such as counters
(whosebacking store may be a database, memcache, etc)
But your missing the point that ++ is NOT expected. Not in Ruby. Ruby
simply doesn’t work that way. You talked about “operator rebinding”,
but you ignored the fact that ++ is nothing like those examples.
a+= expands to a=a+. It’s a simple syntaxtic
sugar. a++ expands to… what? Nothing. There is no way you could
expand puts foo(a++,b) and get the desired behavior.
This discussion has gone on and on, and it’s really quite pointless.
There is no good reason to include ++ in Ruby, and every reason not to.
No one can even agree on what they would expect a ++ operator to do when
used “The Ruby Way”, with C programmers expecting it to work like C, and
the Rubyists expecting it to follow the Ruby way, with every operator
being a method call on that object (NOT variable).
So why introduce this operator into the language that would cause all
this confusion, when all it will do is save a few C programmers a SINGLE
line of code. 95% of the time it won’t even do that, if they would
learn and do things the Ruby way, rather than trying to write C code in
Ruby.
Florian Aßmann wrote:
Gaah, close this thread!
I don’t think there’s a mechanism for doing that, since this is an
unmoderated list. You don’t have to follow it if you don’t want to. 
Cheers
FlorianAm 08.11.2009 um 21:26 schrieb Tony A.:
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sun, Nov 8, 2009 at 2:30 PM, Florian Aßmann
[email protected]wrote:
Gaah, close this thread!
I suppose the whole discussion is moot as Ruby will likely never see a
++
operator.
I was just trying to make clear the limitation wasn’t a technical one,
and
further show how a ++ operator could be “Ruby-like” while still
retaining
C/C++/Java-like semantics.
Gaah, close this thread! 
Cheers
Florian
Am 08.11.2009 um 21:26 schrieb Tony A.:
Tony A. wrote:
On Sun, Nov 8, 2009 at 2:30 PM, Florian Aßmann
[email protected]wrote:Gaah, close this thread!
I suppose the whole discussion is moot as Ruby will likely never see a
++
operator.I was just trying to make clear the limitation wasn’t a technical one,
and
further show how a ++ operator could be “Ruby-like” while still
retaining
C/C++/Java-like semantics.
And as others have made clear, you are incorrect.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sun, Nov 8, 2009 at 3:49 PM, Marnen Laibow-Koser
[email protected]wrote:
And as others have made clear, you are incorrect.
What exactly is it you think I’m “incorrect” about?
On Nov 8, 2009, at 3:01 PM, Tony A. wrote:
On Sun, Nov 8, 2009 at 3:49 PM, Marnen Laibow-Koser [email protected]wrote:
And as others have made clear, you are incorrect.
What exactly is it you think I’m “incorrect” about?
I apologize, but I feel the need to interject:
…that is all.
Tony A. wrote:
On Sun, Nov 8, 2009 at 3:49 PM, Marnen Laibow-Koser
[email protected]wrote:And as others have made clear, you are incorrect.
What exactly is it you think I’m “incorrect” about?
The last assertion you made about the ++ operator. Read the recent
posts from Seebs and others. Make sure you understand them.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sun, Nov 8, 2009 at 4:51 PM, Joshua B. [email protected]
wrote:
I apologize, but I feel the need to interject:
I still find this most appropriate:
On Sun, Nov 8, 2009 at 5:02 PM, Marnen Laibow-Koser
[email protected]wrote:
The last assertion you made about the ++ operator. Read the recent
posts from Seebs and others. Make sure you understand them.
I read and responded to them. Was there something about my responses
you
didn’t like, aside from my initial confusion with a dangling method from
a
previously defined class?
On Nov 9, 9:44 am, Tony A. [email protected] wrote:
I suppose the whole discussion is moot as Ruby will likely never see a ++
operator.I was just trying to make clear the limitation wasn’t a technical one, and
further show how a ++ operator could be “Ruby-like” while still retaining
C/C++/Java-like semantics.
If implementing ++ requires changes to the parser, that seems like a
pretty technical limitation to me!
Matter of interpretation?
BTW in all your posts on the topic, you don’t seem to address pre-
increment vs post-incrememt. (Forgive me if I’m wrong.) If Ruby
implemented ++ and didn’t address that, it wouldn’t be C or C++
semantics at all.
On Sun, Nov 8, 2009 at 8:40 PM, Phrogz [email protected] wrote:
Dude, you just about gave me a heart attack. Phewsh - sanity is
restored.
My bad, it will serve as a reminder to double check my work before
posting
On Nov 8, 12:37 pm, Tony A. [email protected] wrote:
On Sun, Nov 8, 2009 at 12:32 PM, Tony A. [email protected] wrote:
I cannot begin to answer this question because Ruby is doing strange and
unexpected things here, at least from my perspective…Never mind, bar= was still defined because I was reopening the class.
Dude, you just about gave me a heart attack. Phewsh - sanity is
restored.
On Sun, Nov 8, 2009 at 8:50 PM, Gavin S. [email protected]
wrote:
If implementing ++ requires changes to the parser, that seems like a
pretty technical limitation to me!
Assuredly it would require changes to the parser, as “++” presently
lexes/parses as “plus (unary+ value)”, and that’s not to mention how it
parses in method definitions. The resulting operation is equivalent to
binary +, unless you’re using something like
Methodphitaminehttp://jicksta.com/posts/the-methodphitamine
BTW in all your posts on the topic, you don’t seem to address pre-
increment vs post-incrememt. (Forgive me if I’m wrong.) If Ruby
implemented ++ and didn’t address that, it wouldn’t be C or C++
semantics at all.
That’s a can of worms I’ve been trying to avoid, as there are
lexing/parsing
ambiguities surrounding the combination of both. How do you parse a+++b
vs
a++++b vs a+++++b?
Tony A. wrote:
BTW in all your posts on the topic, you don’t seem to address pre-
increment vs post-incrememt. (Forgive me if I’m wrong.) If Ruby
implemented ++ and didn’t address that, it wouldn’t be C or C++
semantics at all.That’s a can of worms I’ve been trying to avoid, as there are lexing/parsing
ambiguities surrounding the combination of both. How do you parse a+++b vs
a++++b vs a+++++b?
The only sane answer is to do what C does, as far as parsing. But the
deeper problem in ruby is what do pre- and post- really mean? In C there
are expressions and there are other constructs, so we can define natural
boundaries for pre and post in terms of expressions. In ruby we have
mostly expressions. So the hard questions are “before what?” and “after
what?”
Does
foo {x++}
yield the incremented x to foo, or the original x? What if foo yields
several times? Increment once, or once per iteration?
What about
x = 0
y = case; when true; x++; end
Is y 0 or 1?
It’s kind of an ink-blot test for what you think “expression” means, but
of course everything is an expression in ruby.
It’s not an answer to say
‘x++’ should have the same effect as ‘x+=1’
because that’s not even true in C.
On Sun, Nov 8, 2009 at 9:54 PM, Joel VanderWerf
[email protected]wrote:
The only sane answer is to do what C does, as far as parsing.
You will find the answer to these edge cases varies. Fortunately they
are
edge cases…
But the deeper problem in ruby is what do pre- and post- really mean?
Really?
In C there are expressions and there are other constructs,
As someone intimately familiar with the expression/statement barrier, I
really don’t see the issue…
so we can define natural boundaries for pre and post in terms of
expressions. In ruby we have mostly expressions.
Ruby is a pure expression-based language (and I see you acknowledge that
later in this message). There are no statements which don’t return a
value.
So the hard questions are “before what?” and “after what?”
Does
foo {x++}
yield the incremented x to foo, or the original x?
Well, to be pedantic, foo is yielding. The return value of the block in
this case is original x.
What if foo yields several times? Increment once, or once per iteration?
Once per iteration.
What about
x = 0
y = case; when true; x++; endIs y 0 or 1?
0
It’s kind of an ink-blot test for what you think “expression” means, but of
course everything is an expression in ruby.
Funny, earlier you implied there were things that aren’t expressions in
Ruby
It’s not an answer to say
‘x++’ should have the same effect as ‘x+=1’
because that’s not even true in C.
Correct, it’s ++x that would have the same effect as x += 1, not that I
find
the preincrementation vs postincrementation distinction particularly
useful
in Ruby, which is why I’ve advocated picking the canonical one and going
with that, even though preincrementation has semantics which would make
more
sense in Ruby.
I’m trying to be pragmatic… and yet being dismissed out of hand.
Because
it is not Ruby-like! According to certain people’s definitions of
“Ruby-like”…
Never mind, bar= was still defined because I was reopening the class.
Noob question: What does that mean?
On Sun, Nov 8, 2009 at 11:39 PM, Ralph S. [email protected]
wrote:
Never mind, bar= was still defined because I was reopening the class.
Noob question: What does that mean?
Before defining either of the classes I described, I did this:
class Foo
attr_accessor :bar
…
end
This meant Foo#bar= was defined already. I forgot I did that, and thus
my
results were, well, unexpected…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs