Dave Burt
9/30/2006 3:07:00 PM
Masaki Suketa wrote:
> In message "Re: Enumerable and WIN32OLE"
> on 06/09/30, Dave Burt <dave@burt.id.au> writes:
>
>> What about something like this, though? For these methods, a block is
>> always provided. For a COM method call, a block is never provided. Why
>> not dispatch depending on block_given?
>
> Some Enumerable's methods does not need a block, for example, Enumerable#max.
> So, I hesitate to implement your idea.
> (I am not sure that there are OLE methods whose name is "max".)
I had an earlier version of the code I posted that went through
Enumerable.instance_methods but skipped specific methods that don't need
blocks (min, max, to_a, entries, grep, sort, zip, /enum_.*/, /.*\?$/).
You can probably dismiss this option as well as what I wrote, just for
being so inconsistent. I don't prefer this option, but I think it does
strike a valuable balance between POLS and compatibility.
> I prefer this approach.
> In Win32OLE, WIN32OLE includes Enumerable.
> If you want to call original method(range.select),
> you should use range.Select.
> (And Win32OLE does not provide the compatibility.
> I have no idea to provide the compatibility.)
I don't think this is a bad idea, but the incompatibility issue needs
considering. I think it's worth it.
> Or,
> In Win32OLE, WIN32OLE does not include Enumerable.
> If you want to use Enumerable's method,
> you add the following code at your own risk.
> class WIN32OLE
> include Enumerable
> end
This (what we currently have) is deficient in the principle of least
surprise and utility. You should not have to explicitly include or
extend Enumerable on a WIN32OLE IEnum object.
Looking at where String's going in Ruby (apparently becoming
non-Enumerable in 1.9) another option could be to leave Enumerable out
of WIN32OLE itself, but provide an enum method to return an enumerator
object:
class WIN32OLE
def enum
Enumerable::Enumerator.new(self)
end
end
Cheers,
Dave