7377
I had expected 7777 here.
Description of [](retranslated from german pickaxe):
"recalls aValueObject, which is stored for aKeyObject"
I don’t find further explanation. Reference, Value, Const?
I think the result is because 3 is an Integer and 3 = 7 don’t work.
Further:
···
#--------------------
h[9] = C.new ; c = h[9]
c = C.new ; c.v = 7
print c.v,h[9].v
-------- produces —
70
I see some sort of rule there, but I dont think this
is “POLS”. Is there a rule somewhere? (chapter of pickaxe?)
I could look into the source code, but this is no explanation for the
reason why its done this way.
Thursday, February 20, 2003, 3:58:17 PM, you wrote:
h[5] = 3; e = h[5]; e = 7
h[8] = C.new ; c = h[8] ; c.v = 7
these lines are very different. vars in ruby holds
pointers to objects. array elements and class members
also holds pointers. “=” operaion sets variable
to point to object evaluated on the right
“c=h[8]” sets c and h[8] to point to the same object.
“c.v=7” modifies this object
“e=h[5]” sets e and h[5] to point to the same object.
but “e=7” changes e to point to another object
so after all above you will have 3 objects pointed by 4 variables/array elements
(h[5],e,h[8],c)
these lines are very different. vars in ruby holds
pointers to objects. array elements and class members
also holds pointers. “=” operaion sets variable
to point to object evaluated on the right
O.K., I didn’t expect such a simple solution.
I had an association (Thinking C++) to operator= done on the var.
So, “h[5]=3” would assign a reference to an instance of Integer with the
value 3, “e = h[5]” would assign this reference to e and finally,
in “e=7” e.operator=(7) would assign 7 to this reference.
(Maybe this is not completely consistent.)
Instead, “=” is just an assignment.
No, you are partly right, because xxx= and = are methods when applied to
an object.
h[5]=3 is shorthand for h.send("=",5,3)
c.v=7 is shorthand for c.send("v=",7)
Both those are method calls (to objects referred to by local varables h and
c). But
e=7
is an assignment to a local variable, because there is no explicit object
receiver given. Local variable 'e' then contains an objectref for the Fixnum
which represents the number 7.
Regards,
Brian.
···
On Fri, Feb 21, 2003 at 04:39:45AM +0900, Michael Bruschkewitz wrote:
I had an association (Thinking C++) to operator= done on the var.
So, "h[5]=3" would assign a reference to an instance of Integer with the
value 3, "e = h[5]" would assign this reference to e and finally,
in "e=7" e.operator=(7) would assign 7 to this reference.
(Maybe this is not completely consistent.)
Instead, "=" is just an assignment.
h[5]=3 is shorthand for h.send(“=”,5,3)
c.v=7 is shorthand for c.send(“v=”,7)
Both those are method calls (to objects referred to by local varables h and
c). But
e=7
is an assignment to a local variable, because there is no explicit object
receiver given. Local variable ‘e’ then contains an objectref for the Fixnum
which represents the number 7.
So, when there is a function:
def fu h, key, o
e = h[key]
e.val = f1(o)
e.val2 = f2(o)
end
… these will (under most preconditions) change the content of the
hash, and including “h[key]=e” at the end will be unnecessary - because
the existence of “val=” and “val2=” grants there is an object receiver.
Right?
Sun, 23 Feb 2003 21:46:56 +0900, Michael Bruschkewitz brusch2@gmx.net pisze:
So, when there is a function:
def fu h, key, o
e = h[key]
e.val = f1(o)
e.val2 = f2(o)
end
… these will (under most preconditions) change the content of the
hash, and including “h[key]=e” at the end will be unnecessary - because
the existence of “val=” and “val2=” grants there is an object receiver.
Right?
Yes. e was at key in h at the beginning, and it’s still there at the end.
It doesn’t matter that the contents of e changed - it’s the same e all
the time.
Almost all languages work that way, I’m surprised that people have
problems with this. Only C, C++, Pascal and in part Perl are different
(they have mutable objects passed by value).
Sun, 23 Feb 2003 21:46:56 +0900, Michael Bruschkewitz brusch2@gmx.net pisze:
def fu h, key, o
e = h[key]
e.val = f1(o)
e.val2 = f2(o)
end
Almost all languages work that way, I’m surprised that people have
problems with this. Only C, C++, Pascal and in part Perl are different
(they have mutable objects passed by value).
The problem is the following (not mine):
If the above function (which was an example of the core problem) is
taken generic, if modifications are done by a proc passed as forth
parameter, you’ll need an extra line h[key] = e at the end to make this
“algorithm” work for Integers too. So, as this example shows, it would
be useful for generic programming, when all types are handled the same
way.
I don’t want to argue about that and I don’t have the time now to dig
deeper into this domain, so let alone the current behavior. It is, at
least, too late to change such basic issues.
Thursday, February 27, 2003, 11:38:42 AM, you wrote:
def fu h, key, o
e = h[key]
e.val = f1(o)
e.val2 = f2(o)
end
The problem is the following (not mine):
If the above function (which was an example of the core problem) is
taken generic, if modifications are done by a proc passed as forth
parameter, you’ll need an extra line h[key] = e at the end to make this
“algorithm” work for Integers too. So, as this example shows, it would
be useful for generic programming, when all types are handled the same
way.
ALL TYPES ARE HANDLED SAME WAY. code above contains one assignment
and two function calls, it is equal to:
e = h[key]
e.send("val=", f1(o))
e.send("val2=", f2(o))
ALL TYPES ARE HANDLED SAME WAY.
This is completely clear. Question (NOT TO BE DISCUSSED NOW) is,
which;), why;), couldn’t it be done better;), … ?
To make the problem clearer:
def fu, h, key, &b, o
e = h[key]
b.call(e,o) # should modify e
end
If e is of type Integer (for example), h[key] will not be modified),
if e is of type Object, h[key] will be modified.
I think, this is an disadvantage.
But Integer is also an Object (it's a subclass). There is no inconsistency.
Whatever function 'b' does, it is unable to change e. It can make method
calls to the object referenced by e, though, which may in turn change its
state if it contains instance variables.
Integers do not contain instance variables, and therefore there is no state
to change.
Regards,
Brian.
···
On Thu, Feb 27, 2003 at 09:59:38PM +0900, Michael Bruschkewitz wrote:
In article <48509684717.20030227115407@integ.ru>, bulatz@integ.ru
says...
> ALL TYPES ARE HANDLED SAME WAY.
This is completely clear. Question (NOT TO BE DISCUSSED NOW) is,
which;), why;), couldn't it be done better;), ... ?
To make the problem clearer:
def fu, h, key, &b, o
e = h[key]
b.call(e,o) # should modify e
end
If e is of type Integer (for example), h[key] will not be modified),
if e is of type Object, h[key] will be modified.
Thursday, February 27, 2003, 4:06:41 PM, you wrote:
ALL TYPES ARE HANDLED SAME WAY.
This is completely clear. Question (NOT TO BE DISCUSSED NOW) is,
which;), why;), couldn’t it be done better;), … ?
To make the problem clearer:
def fu, h, key, &b, o
e = h[key]
b.call(e,o) # should modify e
end
If e is of type Integer (for example), h[key] will not be modified),
if e is of type Object, h[key] will be modified.
But Integer is also an Object (it’s a subclass). There is no inconsistency.
Whatever function ‘b’ does, it is unable to change e. It can make method
calls to the object referenced by e, though, which may in turn change its
state if it contains instance variables.
Integers do not contain instance variables, and therefore there is no state
to change.
i can add that, to be exact, some types has methods which change internal
object state (whose names ends with “=” or “!”, typically) and some types
don’t have such methods. someone can create unmodifable types, it’s easy:
class Persistent
end
class Persistent2
attr_reader :x,:y
def initialize(a,b)
x=a
y=b
end
end