On 06.06.2008 17:01, Eric Mahurin wrote:
> On Fri, Jun 6, 2008 at 7:29 AM, Robert Klemme
> <shortcutter / googlemail.com> wrote:
>> 2008/6/6 Eric Mahurin <eric.mahurin / gmail.com>:
>>> In ruby, I sometimes miss the ability to easily reference and
>>> dereference lvalues.  There is always another way, but having lvalue
>>> references/pointers would sometimes be more elegant.
>> Can you give an example?  I'm curios because I never missed this and
>> I'd like to know what I am overlooking.  It may be that my mindset is
>> so Java / Ruby already that I simply do not think in ways that would
>> make references useful - or I deal with a different class of problems
>> which can be more easily solved without.
> 
> A general category would be data structures of a linked set of nodes -
> trees (i.e. AVL, red-black, splay, B), linked lists (single, double),
> graph, etc.  Each node can be easily represented in Ruby with an
> object that has one or more instance variables for the "links" where
> each link holds another node or nil.  Many operations may equally
> apply to the head/root of the data structure or somewhere in the
> middle (a sub head/root).  Not a problem for Ruby as long as this
> operation doesn't want to modify the link at that point.  In other
> languages we might pass a reference/pointer of the variable with the
> link so that it could be modified.  In Ruby, you'll have come up with
> another solution: a) pass the node containing the link you want to
> operate along with something saying which link in the node (you'll
> probably also need a dummy node at the root/head), b) have a separate
> object for the link so you can pass it around (i.e. simply an Array of
> one element), c) pass a lambda that can modify the link.  None of
> these are as elegant as an lvalue reference IMHO.  In my early ruby
> days a few years ago I put some code in the rubyforge "reference"
> project.  I still think having something like this readily available
> would be useful.

The usual solution in Ruby would probably be a) which I find perfectly 
ok.  Since the manipulation is typically encapsulated inside a 
LinkedList class it does not bother me too much if there are two 
additional elements (for head and tail). :-)  But I can see how this 
might be a bit more elegant with references (although not as much to 
create an urgent need for references in Ruby). :-)

> External iterators are also like lvalue references and is something
> ruby is missing (IMHO). 

Is it?

irb(main):027:0> require 'generator'
=> true
irb(main):028:0> arr = %w{foo bar baz}
=> ["foo", "bar", "baz"]
irb(main):029:0> it = Generator.new arr
=> #<Generator:0x1002ffe8 @cont_endp=nil, @index=0, 
@block=#<Proc:0x1001bbc4@/usr/lib/ruby/1.8/generator.rb:71>, 
@cont_yield=#<Continuation:0x1002f5fc>, @cont_next=nil, @queue=["foo"]>
irb(main):030:0> until it.end?; puts it.current; it.next; end
foo
bar
baz
=> nil

> An external iterator could be thought of as a
> superset of the reference/pointer concept (external iterator looks
> like a pointer in C++).

Which is nicely done (in C++'s STL, I mean).  But with blocks I don't 
really miss external iterators.  I rarely have to iterate through 
multiple collections in lock step and if I had #zip served me well.

Maybe I'm just not doing enough development that involves sophisticated 
algorithms. :-)

Thanks for your explanation!

Kind regards

	robert