From: ES Date: 2005-06-05T05:21:35+09:00 Subject: Re: internal iterators in ruby Le 4/6/2005, "Charles Hixson" a �crit: >Geert Fannes wrote: > >>So, if I understand well, the problem with iterating over different >>enumerables synchronously has to do with the absence of a #rewind and >>#next method for enumerables. The Generator class solves this using the >>slow #callcc method and allows one to step through the Enumerable#each >>method, element by element. Wouldn't it be better if the enumerable >>required a #rewind and #next method and constructs the #each method out >>of these instead of doing the reverse using #callcc? >>Greetings, >>Geert Fannes. >> >> >>You code works only for arrays, but it's quite efficient. >> >>This works for all Enumerable types, is less efficient - and it's part >>of >>the std lib: >> >>http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/SyncEnumera >>tor.html >> >>Know your standard libs... :-) >> >>Kind regards >> >> robert >> >> >This is one of the reasons that I feel that mixins should be >inheritable. What you really want to do is define a descendant of >Enumerable that implements those methods. You can always #include the module in your module. Or, if you want to get fancy and it happens to suit your purposes, you can have your module #extend another module. >I suppose that what one could do is define a new mixin, say >"TwoWayEnumerable" that implements the standard ops of a doubly linked >list (getting most of them by requiring Enumerable) and use that. Since >it would include the definition of Enumerable, it could be used whenever >Enumerable was needed, but it could also be used in other instances, >such as the one that you are proposing. > >But I still feel that inheriting from SuperModules would be nicer >syntactically. E -- template void quack(duck& d) { d.quack(); }