# Fwd: WorkItem Issue #6095 - "IronRuby 1.1.3 Can't count"

**URL:** <https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569>\
**Category:** IronRuby\
**Created:** [May 4, 2011, 11:38pm UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569 "2011-05-04T23:38:18Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [May 4, 2011, 11:38pm UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/1 "2011-05-04T23:38:18Z")

</div>

Hey all,

I thought I’d look at issue #6095 on codeplex  
([http://ironruby.codeplex.com/workitem/6095](http://ironruby.codeplex.com/workitem/6095)) as my first contribution.

Having a dig through the code lead me to ArrayOps which then lead  
me IListOps in the IronRuby.Libraries project.

I noticed IListOps.Length had the [RubyMethod(“count”)] attribute  
method which only returned the arrays count. Have to some digging (and  
unneeded code writing then reverting)  
I looked at the ruby doc and saw Array mixed in Enumerable, looked  
around and found that IListOps was indeed marked to include Enumerable  
and sure enough found the 3 count methods.

One for no parameters, one with, and one with a block that did all  
they were supposed to do.

So the RubyMethod declaration for count in IListOps was  
overriding the method declarations in Enumerable once the ruby class  
was put together at runtime.

I removed the RubyMethod declaration on IListOps compiled and ran  
the IronRuby console, tried out all three versions of count and they  
all worked.

Now, I can see why the count declaration on IListOps was put  
there, because accessing the internal count property on RubyArray is  
much quicker than counting and iterating over the collection, however,  
the ruby methods length and size for quick access to the number of  
elements in the RubyArray.

I see two ways of fixing the bug,

1. removing the [RubyMethod(“count”)] declaration from  
IListOps.Length which would make count inefficent on IList’s.
2. reimplementing the object and block variations of count in IListOps

In my humble opinion, 1 would be best, but since this is my first  
change I’d thought I’d get some input.

Cheers,

–  
Nik Radford

Mobile: 07884 254 866  
Email: removed\_email\_address@domain.invalid

–  
Nik Radford

Mobile: 07884 254 866  
Email: removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 5, 2011, 1:14am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/2 "2011-05-05T01:14:39Z")

</div>

On Wed, May 4, 2011 at 2:02 PM, Nicholas R.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote:

> Hey all,
> 
> I thought I’d look at issue #6095 on codeplex  
> ([http://ironruby.codeplex.com/workitem/6095](http://ironruby.codeplex.com/workitem/6095)) as my first contribution.

> I see two ways of fixing the bug,  
> 1. removing the [RubyMethod(“count”)] declaration from  
> IListOps.Length which would make count inefficent on IList’s.  
> 2. reimplementing the object and block variations of count in IListOps
> 
> In my humble opinion, 1 would be best, but since this is my first  
> change I’d thought I’d get some input.

I’m partial to option 2. As Ruby is already a slow language, we should  
try  
to optimize it wherever possible. In addition, 2 keeps to the trend in  
other  
.NET languages. For example, I believe LINQ takes advantage of existing  
methods on Lists when it can.

Ryan

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 5, 2011, 10:39am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/3 "2011-05-05T10:39:34Z")

</div>

> > I’m partial tooption 2. As Ruby is already a slow language, we should try  
> > to optimize it wherever possible. In addition, 2 keeps to the trend in other  
> > .NET languages. For example, I believe LINQ takes advantage of existing  
> > methods on Lists when it can.
> 
> Likewise. Because arrays are used absolutely everywhere in ruby, making a  
> common method like count slower will have a whole lot of hidden performance  
> penalties… Anything we can do to make these core classes faster is a win  
> for everyone

Alright, I’ll get onto doing option 2 when I get home this evening.

Thanks guys.

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 5, 2011, 5:04am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/4 "2011-05-05T05:04:05Z")

</div>

> > 
> 
> I’m partial to option 2. As Ruby is already a slow language, we should try  
> to optimize it wherever possible. In addition, 2 keeps to the trend in other  
> .NET languages. For example, I believe LINQ takes advantage of existing  
> methods on Lists when it can.

Likewise. Because arrays are used absolutely everywhere in ruby, making  
a  
common method like count slower will have a whole lot of hidden  
performance  
penalties… Anything we can do to make these core classes faster is a  
win  
for everyone

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 7, 2011, 10:39am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/5 "2011-05-07T10:39:05Z")

</div>

> Quick question guys, when pushing this to my repo on github, should I  
> push to a topic branch or push to master?

Well I pushed it to a topic branch, just in case you guys required  
changes 🙂

As the contributing documentation says, would someone mind giving me a  
code review?

Code can be found at

[https://github.com/sekhat/main/tree/bugfix/issue-6095](https://github.com/sekhat/main/tree/bugfix/issue-6095)

Cheers.

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 8, 2011, 3:50am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/6 "2011-05-08T03:50:00Z")

</div>

Yes, this is the right process - fix it in a branch and send a pull  
request.

The change looks great! Merged into main and closed the bug.

Thanks,  
Tomas

---

<div class="post-metadata">

**Author:** ![nickrahn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/dfb087/32.png) [@nickrahn](https://www.ruby-forum.com/u/nickrahn)\
**Post date:** [May 7, 2011, 10:09am UTC](https://www.ruby-forum.com/t/fwd-workitem-issue-6095-ironruby-1-1-3-cant-count/206569/7 "2011-05-07T10:09:28Z")

</div>

On 5 May 2011 09:32, Nicholas R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Alright, I’ll get onto doing option 2 when I get home this evening.
> 
> Thanks guys.

Quick question guys, when pushing this to my repo on github, should I  
push to a topic branch or push to master?

–  
Nik Radford

Mobile: 07884 254 866  
Email: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)
