How to call this method

Ruby
#1

Hi list

the recent thread about all_indicies has somehow made me think that I
need a more general inject.
Here is my first shot on it:
http://pastie.org/597659
But how to call that beast, #inject_with is somehow not really what I
like.
Actually I think #inject would be a nice name, but it is already taken.

Cheers
Robert

#2

2009/8/28 Robert D. [email protected]:

the recent thread about all_indicies has somehow made me think that I
need a more general inject.
Here is my first shot on it:
http://pastie.org/597659

I didn’t know StopIteration yet. That’s nice.

Your use case is a bit unclear to me. Also, I do not see why you need
to pass variables via the block. Somehow that looks suspiciously more
complex to me than it could be. A few ideas

class String
def indices rgx, idx = 0
r = []
idx = index rgx, idx

while idx
  r << idx
  idx = index rgx, idx.succ
end

r

end

def indices2 rgx, idx = 0
idx = index rgx, idx

while idx
  yield idx
  idx = index rgx, idx.succ
end

self

end

def indices3 rgx, idx = 0
scan rgx do
i = $`.length
yield i if i >= idx
end
end

def indices4 rgx, idx = 0
to_enum(:scan, rgx).inject [] do |r,|
i = $~.offset(0).first
yield i if i >= idx
end
end
end

irb(main):154:0* “abcabc”.indices(“a”,1)
=> [3]
irb(main):155:0> “abcabc”.indices2(“a”,1) {|i| p i}
“a3
bcabc”.indices3(“a”,1) {|i| p i}
=> “abcabc”
irb(main):156:0> “abcabc”.indices3(“a”,1) {|i| p i}
“abcabc”.indices4(“a”,1) {|i| p i}
3
=> “abcabc”
irb(main):157:0> “abcabc”.indices4(“a”,1) {|i| p i}
3
=> 3
irb(main):158:0>

Ok, I admit, I got carried away. :slight_smile:

But how to call that beast, #inject_with is somehow not really what I like.
Actually I think #inject would be a nice name, but it is already taken.

Only few come to mind: roll, rotate, circulate

Kind regards

robert

#3

On Fri, Aug 28, 2009 at 3:17 PM, Robert
Klemme[email protected] wrote:

Ok, I admit, I got carried away. :slight_smile:
Yup, but I guess we all like to read your code. Well I do not care
about indicies, it was just the trigger for: “I want a thing that
passes its results into itself”.

Maybe this usecase is more appealing?

http://pastie.org/597712

and of course a logical extension into Enumerable would be

http://pastie.org/597718

R.

#4

On Fri, Aug 28, 2009 at 11:22 AM, Bertram
Scharpf[email protected] wrote:

Am Freitag, 28. Aug 2009, 22:17:21 +0900 schrieb Robert K.:

2009/8/28 Robert D. [email protected]:

http://pastie.org/597659

I didn’t know StopIteration yet. That’s nice.

I didn’t know it either.

Neither did I. It’s a Ruby 1.9 thing, backported to 1.8.7 some of the
other stuff in that snippet like the block arg syntax is Ruby 1.9
only.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

#5

Hi,

I have a string literal in this form:

taxonomy = %q{
+AttributeControl
NMAttributeControl.*
+NetworkControl
NMNetworkControl*.*
+TimelineControl
NMTimelineControl*.*
+CurveControl
NMCurveControl*.*
.
}

Is it possible to somehow specify it such that there are (automatically)
newline characters at the end of each line?

Cheers,
James

#6

Hi,

Am Freitag, 28. Aug 2009, 22:17:21 +0900 schrieb Robert K.:

2009/8/28 Robert D. [email protected]:

http://pastie.org/597659

I didn’t know StopIteration yet. That’s nice.

I didn’t know it either. Is there anything that `break’ cannot
do better?

Bertram

#7

On 28.08.2009 17:22, Bertram S. wrote:

Am Freitag, 28. Aug 2009, 22:17:21 +0900 schrieb Robert K.:

2009/8/28 Robert D. [email protected]:

http://pastie.org/597659
I didn’t know StopIteration yet. That’s nice.

I didn’t know it either. Is there anything that `break’ cannot
do better?

Multilevel exit like you can also do with catch throw (see Find.find).

Kind regards

robert

#8

Boy do I feel stupid. taxonomy.include?(’\n’) was returning false. Wrong
quoting… Cheers for the nudge.

#9

On Fri, Aug 28, 2009 at 6:55 PM, Robert
Klemme[email protected] wrote:

do better?

Multilevel exit like you can also do with catch throw (see Find.find).
Yep, by using “raise StopIteration” I make my intent a little bit
clearer and it is less fragile
in case I am getting embedded into other blox. But that is not the
case here, I agree.

I think it might also having been built for Enumerator#next

loop do
…
an_enum.next # might raise StopIteration
…
end

HTH
R.

#10

James F. schrieb:

  NMTimelineControl*.*

Hi,

there ARE already Newlines in your string:

puts taxonomy.scan(/\n/).size #=> 10

What’s your problem?

Marvin

#11

Hi,

Am Samstag, 29. Aug 2009, 01:55:26 +0900 schrieb Robert K.:

Multilevel exit
No, it exits just one level:

loop { puts “x” ; loop { puts “y” ; raise StopIteration } }

Bertram

#12

On Fri, Aug 28, 2009 at 7:43 PM, Bertram
Scharpf[email protected] wrote:

loop { puts “x” ; loop { puts “y” ; raise StopIteration } }
Wait a second, break exits a block,
raise gets to the next,exception handler, in your case the one in the
inner loop; thus you need to do the following

loop do
puts “x”
lambda{ puts “y”; raise StopIteration}[]
end

to see what is going on

In other words you did

begin
while true
puts “x”
begin
while true
puts “y”
raise SI
end
rescue SI
end
end
rescue SI
end

R.

#13

Sorry for re-phrasing my question, but it just came back to me, from
where I had this idea:
Clojure’s iterate

Do you think iterate is a good name for this?

Cheers
Robert

#14

On Sat, Aug 29, 2009 at 11:20 AM, Robert
Klemmeremoved[email protected] wrote:

On 28.08.2009 19:43, Bertram S. wrote:

Your point demonstrates though that catch throw might be superior because
you explicitly declare the point of return.
I just think they are two different tools for two different tasks.

raise SI: end an iteration / loop
throw/catch raise * : Whatever seems appropriate, non local exit
being a possibility

It depends heavily on the *.

I therefore reconsider my confirmation that SI is for non local exit
in general, Betram’s examples have made that quite clear.

Cheers
R.

#15

On 28.08.2009 19:43, Bertram S. wrote:

Multilevel exit

No, it exits just one level:

loop { puts “x” ; loop { puts “y” ; raise StopIteration } }

Well, we’re both right: it won’t exit multiple loop levels but it will
exit multiple stack frames, i.e. method and block calls (not
containing loops of course). That’s what I had in mind.

Your point demonstrates though that catch throw might be superior
because you explicitly declare the point of return.

Kind regards

robert