sure, maybe its difficult for you to see redesign just yet,
but you'll have to do so in any case. the use of such
misdesign will just get you further down the well...
Is the "right" design pure by-value? You seem to be pushing in that
direction.
Florian Gross wrote:
Andreas Semt wrote:
You can change the Objects that you're methods gets in case they are value Objects [...]
A nice discussion.
Florian should write a book!Thanks, but I just spotted myself using "you're" instead of "your". Everything's going downhill for sure.
It's a change for the worse.
Can we all pretend that it didn't happen?
Yes, we can! But it wouldn't help! 
Greetings,
Andreas
David: evil-ruby looks like a great efford, thank you for pointing that out.
Actually I've never had the need for this hack, I just wanted to share
my opinion. That said, I think many people gets way too defensive
(offensive?) when this kind of issues arise. Lots of virtual ink is
wasted explaining why it won't work in the current model insted of
taking a look at the benefits it could bring.
So far, the cons are two:
1. The current model doesn't support it.
2. The performance would be poor:
My opinion is that the programmer should be able to chose the
perfomance level he/she wants. About the ruby model, I'm happy with
the current implementation but maybe that statement ("ruby doesn't
work that way") is enough to stop any further improvement.
···
On Thu, 20 Jan 2005 02:06:04 +0900, Florian Gross <flgr@ccan.de> wrote:
you should have a look at the Object#become that evil-ruby implements.
(See evil.rubyforge.org)
Mark Hubbart wrote:
do_something if ref # always done
x = ref || y # x is always refAh, I hadn't thought of that. I guess if you would need to
de-reference in conditionals:
do_something if ref.__value__
Yup, #to_bool is really missing here.
Some of Ruby's C methods want their arguments to be instances of a
particular class. They won't even call the usual #to_x methods.
str.scan(ref) is one example of that.I didn't know of that one. So String.scan doesn't use duck typing?
Lots of C methods don't even try to convert their arguments which is quite sad. There's no #to_re or #to_regexp. Because of that I have to use a huge work-around in Regexp::English that involves sub classing Regexp and recalling the Regexp#initialize method whenever the value changes...
Object.instance_method(:inspect).bind(ref).call calls the #inspect
method of the ref, not of the Object it refers to.I would consider that a feature
at a later time, a method could be
added, __ref__, would would allow you to call normal ruby methods on
the reference object; get its id, inspect it, etc.
I agree, I'm even using the above when I don't trust the methods the Object provides. (Sandboxes, DRb)
But it's still a case where the caller needs to be aware of refs and possibly dereference them manually.
yes
i've coded in c++ also in which pass by ref is possible
and abhor it
pass by ref is just plain evil
pass by ref in which the *caller* states that
its a ref, (as in c via a ref and a de-ref of ptrs),
is okay in my books, but implicit anything sucks
Alex
···
On Jan 19, 2005, at 5:01 PM, trans. wrote:
> sure, maybe its difficult for you to see redesign just yet,
> but you'll have to do so in any case. the use of such
> misdesign will just get you further down the well...Is the "right" design pure by-value? You seem to be pushing in that
direction.
David? I mean Florian!
···
On Wed, 19 Jan 2005 16:06:26 -0300, Michel Martens <blaumag@gmail.com> wrote:
On Thu, 20 Jan 2005 02:06:04 +0900, Florian Gross <flgr@ccan.de> wrote:
> you should have a look at the Object#become that evil-ruby implements.
> (See evil.rubyforge.org)David: evil-ruby looks like a great efford, thank you for pointing that out.
Michel Martens wrote:
Actually I've never had the need for this hack, I just wanted to share
my opinion. That said, I think many people gets way too defensive
(offensive?) when this kind of issues arise. Lots of virtual ink is
wasted explaining why it won't work in the current model insted of
taking a look at the benefits it could bring.So far, the cons are two:
1. The current model doesn't support it. 2. The performance would be poor:
[...] but maybe that statement ("ruby doesn't
work that way") is enough to stop any further improvement.
I disagree. I think there are some core principles of Ruby that make it Ruby. These should not change, especially not if there are no good sample situations that would require the change to work correctly.
I'm not a conservative, but Ruby can not be everything for everyone, part of its attractiveness is that it is simple and consistent. If we keep adding everything that is requested that will not be true any more.
I don't have anything against trying out this kind of ideas, hell, I've even done so repeatedly by myself, but there's a huge difference between requesting a change (or asking why it is not like that) and toying around with the idea.
Toying around with ideas is IMHO a nice thing as it provides a way of testing new ideas without risking a complexity explosion in the main language. If the feature turns out to be worthwhile or important it can after all still be added.
matz has one of the hardest jobs I can possibly imagine. If he does add something to Ruby that later turns out to be a bad idea he will have to slowly deprecate it and find a way around it. At that time it might also be too late however. I can certainly understand him being so careful about adding new things whose implications can not be seen up front. It's hard to do the right thing when adding new features is so easy and removing them is so hard. Maintaining overall simplicity however requires refactoring and removing stuff and breaking compatibility is frequently not an option.
evil-ruby looks like a great efford, thank you for
pointing that out.
Also check out:
http://developer.berlios.de/projects/suby/
Wizard Peter Vanbroekhoven has also written a #become patch for Ruby.
T.
Alexander Kellett wrote:
yes
i've coded in c++ also in which pass by ref is possible
and abhor it
pass by ref is just plain evil
pass by ref in which the *caller* states that
its a ref, (as in c via a ref and a de-ref of ptrs),
is okay in my books, but implicit anything sucks
Actually, I absolutely agree with you. I do beleive in functional
design. the idea that the effect are coming out on the left side and
the input is gogin in on the right. Very good. Unfortunately Ruby isn't
pure by-val. I don't know why exactly, maybe there are good reasons
--probably performace related. But since it isn't by-val I don't think
it does a whole lot of good to a have a partial barrier. The fact is,
one must be aware the parameters going in to a method, might be altered
in route. Giving the odus of duck-typing, i.e. we may not know what
type of object is being fed our methods necessarily, this might or
might not happen dependent soley on the type of object.
A quick example just to make myself clear:
class A
def mud(x) ; x + 1 ; end
end
class B
def mud(x) ; @x += 1 ; end
end
def quasi_mud(x)
x.mud
end
a = A.new
b = B.new
quasi_mud(a) # a remains just as it was
quasi_mud(b) # b is no longer the same
T.
Disagreement here as well. I've needed Object#become quite a bit in my
travels and I think Ruby could support it without incurring cost. It's
as simple as a memcpy of an RStruct.
I think Ruby lacks this feature either because it's a scary change that
could be misunderstood or because it's difficult to distill into a
technique that fits within the current Ruby.
I only have one use case: I'm building a complex Ruby object, when I find
a point of recursion or transformation which requires me to retrace my
steps and replace a node farther back in the tree.
What I'm looking for is closer to a SymbolTable#sub!. Where I pass it
two object IDs and every instance of the former becomes the latter.
Better yet, a third object ID parameter would cause substitution only
within the tree starting at that VALUE.
It would be fine if this mechanism checked for ! BUILTIN_TYPE(obj) in
the first call described above, but allowed builtin type subs within a
tree.
_why
···
Florian Gross (flgr@ccan.de) wrote:
>
>So far, the cons are two:
>
>1. The current model doesn't support it.
>2. The performance would be poor:
>
>[...] but maybe that statement ("ruby doesn't
>work that way") is enough to stop any further improvement.I disagree. I think there are some core principles of Ruby that make it
Ruby. These should not change, especially not if there are no good
sample situations that would require the change to work correctly.
why the lucky stiff wrote:
So far, the cons are two:
1. The current model doesn't support it. 2. The performance would be poor:
[...] but maybe that statement ("ruby doesn't
work that way") is enough to stop any further improvement.I disagree. I think there are some core principles of Ruby that make it Ruby. These should not change, especially not if there are no good sample situations that would require the change to work correctly.
Disagreement here as well. I've needed Object#become quite a bit in my
travels and I think Ruby could support it without incurring cost. It's
as simple as a memcpy of an RStruct.
Actually, it isn't. Have a look at the evil-ruby project. There is a lot of cases that can lead to segfaults and endless loops with such a naive implementation.
It's especially important that the RStructs are compatible meaning you can not use it generally anyway.
I don't quite see how the two things (introducing variable-by-ref semantics) and Object#become are related. Plus I was sort of arguing against the stuff I quoted, e.g. not wanting to implement a feature in the general case.
I only have one use case: I'm building a complex Ruby object, when I find
a point of recursion or transformation which requires me to retrace my steps and replace a node farther back in the tree.
If it's a tree then there will usually only be one place that refers to your Object. It ought to be possible to replace it even without #become.
As said: Note that I'm not against toying around with ideas or implementing well tested ideas that match up with the languages core philosophy without introducing too much new complexity.
···
Florian Gross (flgr@ccan.de) wrote: