Re: Ruby's implementation of Fixnum-assignment

< ^ > P N |<>|^_>< --- | ~ ...Help
On Dec 22, 11:46 阬磹 秠瞂覶 咘樇翴 潟鴄覶裷纁悅營瀅賚樇摋鴟蜧篿 蘹濻摨
> 2009/12/22 RichardOnRails <RichardDummyMailbox58... / uscomputergurus.com>:
>
> > On Dec 22, 9:40 阬磹 秠瞂覶 咘樇翴 潟鴄覶裷纁悅營瀅賚樇摋鴟蜧篿 蘹濻摨
> >> 2009/12/22 Rick DeNatale <rick.denat... / gmail.com>
>
> >> > On Tue, Dec 22, 2009 at 3:24 AM, Robert Klemme
> >> > <shortcut... / googlemail.com> wrote:
> >> > > 2009/12/21 RichardOnRails <RichardDummyMailbox58... / uscomputergurus.com>:
> > Thanks for honoring me with responses to what you guys must view as
> > drivel.  阬鍱 摦蜲贄 鐓摷鵴覶濈鐓敳 秝禊 蠈蜧賧澬殢 Ｓ蔣摷 搿
> > assignment statement rather than an invoking a apparently mythical "="
> > operator.
>
> On syntax level it's an operator as many others but underneath it is
> quite different.  阬╓鐓濎摵瀦濊 緮臩翴隮 鐓澞 澞 鐓瀁檛
> operation which can change an object's state for all non built in
> classes.
>
> >>> Actually, I believe all this reasoning about Fixnums being immediate
> >>> values is totally overdone.  阬襘秝禊 貗檭蠌臇殣更 謥覷謥蜑瀄濊
> >>> is completely irrelevant (if you put performance aside for the
> >>> moment). [snip]
> >> Agreed.
>
> > I see your point.  阬蘟 玊欈 趠Ｔ蘪羻麧薋 濎醲擤樍鏷摐 鶋鳵懤恥
>
> That must hurt...
>
> > Both Robert and Matz responded a few weeks ago on a question I raised
> > about implementing a Fixnum ++ operator in Ruby functionally
> > equivalent to C's prefix_++ operator.  阬抑 闀斀瞁╞鍡 緮黼蜼 > > change; I merely suggested that it's possible.  阬鳺 蠈鶇瀁鵴 欒黼蜼
> > an operator would be functionally equivalent to "turning 1 into 2."
>
> > But I see the following:
> > a = 1 # ID = 3
> > a = 2 # ID = 5
> > b = 1 # ID = 1
> > b++ # implemented as b.++() which increments b's object's ID by 2
> > and checks for edge cases;
>
> Please forget your idea of object ids being modified.  阬檺耪蜑 毈 澞
> just a derived bit of data.  阬鍱碠鰿 檺耪蜑 毈軋氀殣蜼搿谾
> because the identity of an object does not change.
>
> > I don't see such an implementation as
> > disturbing any other object, at least none on my machine's hardware
> > and software state.
>
> You are probably overlooking effects on consistency of the whole
> language.  阬鴇懤 濊 艬纍瞂 醲蜼鍣蝁擤儌摵懤 鐐 濎鐍檷礯垂 濎鐐
> the language the consequences are undesirable.
>
> 1. prefix ++ operator would change the state of an instance if you
> wanted to roughly retain C++ semantics.
>
> 2. This means, that for other (non Fixnum) classes this will happen:
>
> a = anything_but_Fixnum()
> b = a
> ++a
> b == a # => true
> b.equal? a # => true, identity does not change
>
> But, if what you wrote were followed (no other object is affected):
>
> a = any_Fixnum()
> b = a
> ++a
> b == a # => false
> b.equal? a # => false, identity has changed
>
> 3. Also, if Fixnums should behave like other classes, suddenly a
> Fixnum becomes mutable, which cannot be since Fixnums are immediate
> and do not have a place to store state that can change.
>
> 4. The only salvation is to make "++a" syntactic sugar for "a += 1" or
> rather "a = a + 1" (or maybe even "a = a.succ"), i.e. an expression
> which contains an assignment.  阬鳺Ｔ 蝸 屣 羻麧皎 摵濼艬纍> return "false" as well and everything is consistent again (assuming
> standard implementations of + which do not change the instance but
> return a new one).
>
> I believe Matz decided against because a) there is a pretty short
> idiom which does this already ("a += 1") and b) that existing idiom
> has an equals sign in there thus making the assignment obvious; "++a"
> on the contrary does not have an equals sign anywhere and thus would
> obscure the fact that under the hood an assignment is taking place.
> This would make the code harder to read while not bringing any
> benefits to the language.
>
> >> "a=1" is an assignment meaning, it
> >> takes whatever object reference the evaluation of the expression on
> >> the right side yields and puts it into the storage location denoted by
> >> "a".  阬鳺蠈 澞 闀 翴鐓檷 濎獿錼銢 蜲覶摋鍎闀 翴鐓檷 瀁 Ｓ玁殫> >> as I said - is no object but just a place in storage.
>
> > But aside from copying (in this case) 1's ID, Ruby must first look up
>
> Not "1's ID" is copied but the "reference to 1". 1" is only special
> in that the reference does not point to an actual object.
>
> > a's
> > presence in the current scope's portion of the symbol table and if not
> > present, insert it, or otherwise deal with the existing ID for the "a"
> > entry: (i) if the ID is an actual address of data in some pool,
> > decrement its reference count if positive; or (ii) do nothing for
> > Fixnums, true, false and nil).
>
> AFAIK Ruby has a mark and sweep garbage collector which does not
> employ reference counting.http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
>
> > I wouldn't even have posted my ++ question if I could follow my way
> > through Ruby's C or C++ implementation.  阬蘟 濎 摵瀦薋 憼黀 麧蝁麧
> > before retirement, I was the debugger/enhancer of several
> > organization's apps,  阬鋋濷 魟羻鏻鍡 鐓儓隮 鐓襘纊簿禱蜧麧
> > is, especially an app as big as Ruby.  阬蘟 氄 ╓豵濎醲翴 鐐 秝禊更
> > Finite State Machine (there's GOT to be one), I'd ...
>
> I find that hard as well...
>
> Cheers
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/

Thanks for your additional response.

> > I see your point.  But I've got a "burr under my intellectual saddle."
>
> That must hurt...

Nah :-)  It's just that sometimes, to use a different metaphor,  I'm a
dog gnawing at a technology bone.  But I've got to suspend this issue
for about 10 days while I concentrate on my brother's family (coming
in from Europe) and my son's (coming in from the deep South).

But, as a Schwarzenegger character once promised,  I'll be back :-).

Best wishes for the holidays,
Richard