Masaki S. wrote:
In message “Re: Enumerable and WIN32OLE”
on 06/09/30, Dave B. [email protected] 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.
In Win32OLE, WIN32OLE does not include Enumerable.
If you want to use Enumerable’s method,
you add the following code at your own risk.
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