On 11.04.2009 20:43, Roger Pack wrote:
>>> 1) add an Object#in? method to complement the existing Array#include?
>> -0
>>
>> I don't see the benefit but I'm also not strongly against.  I do see
>> Joel's point about the reversion.  Basically it is strange that every
>> object should be able to answer a question that only the collection can
>> answer.  Plus, you can easily add it yourself if you need it.
> 
> I kind of agree with Joel on this one, too.
> 
> A few other observations:
> 
> re: in?
> Currently with #select you've got one in Kernel [which is IO.select] but 
> Arrays seem to have their own #select.  So it is "conceivably possible" 
> to have a "default #in?" and have it overridden by Clutch#in? or 
> House#in? if desired.

That's not exactly an override situation because the "global" select is 
used without an instance or with a class instance (IO) while 
Enumerable#select is always used with an instance.

> Another option would be included? -- might be more ruby-y :)
> 
>>> 2) add some useful lists of exceptions, ex: IO.SELECT_EXCEPTIONS,
>>> IO.READ_EXCEPTIONS, so that you can rescue the wide gamut of them
>>> appropriately, should you desire to.
>> A good idea.  But I do not know how feasible this is.  Not all OS have
>> the same error reporting mechanisms and the mapping from OS errors to
>> exception types would have to be maintained of all platforms.
> 
> True, mapping exceptions directly from OS to OS would be problematic. 
> And knowing which ones are on each OS is also annoying.
> I am proposing more of a (platform dependent) container of all possible 
> exceptions, regardless of what they may mean.  Or have them all include 
> a common ancestor--same result.

There is SystemCallError already:

ObjectSpace.each_object(Class) do |cl|
   p cl if cl.ancestors.include? SystemCallError
end

>>> 3) provide an easier way to know which platform you're on than
>>> RUBY_PLATFORM =~ /mswin32|dgjpp|mingw/
>> -1
>>
>> This would make a Ruby specific unification of operating systems
>> necessary.  This means that not only maintainers of automake need to
>> keep track of operating systems but also maintainers of Ruby.  Other
>> difficulties are: how much level of detail do you provide?  For one
>> application it may be enough to know it's running on Linux, the other
>> one needs to know the kernel version and a third one does not bother
>> about versions but must know the distro.  I see too much effort for too
>> little benefit.
> 
> True maintaining this is annoying, but I'd also propose that it's 
> useful.  Currently in 1.9 we have:
>>> RUBY_VERSION
> => "1.9.2"
>>> RUBY_PLATFORM
> => "x86_64-linux"
>>> RUBY_ENGINE
> => "ruby"
> 
> Typically "enough" OS information is given in RUBY_PLATFORM to determine 
> the platform--it's just "hard" to use that for such.  My example being 
> that knowing if you're on windows is something like RUBY_PLATFORM =~ 
> /dgjpp|mingw|mswin/
> which seems overly complex for me.  And very hard to get right the first 
> time (ex: RUBY_PLATFORM =~ /win/ doesn't work--that includes darwin).

And how do you want to resolve the issues I have raised in my posting? 
The question really is "what is a platform"?  When using cygwin, are you 
"on Windows" or not? etc.

>>> 5) add a BigDecimal(float) method.
>>>  -> BigDecimal.new("%f" % float)
>> 0
>>
>> Seems reasonable at first sight but the absence might have a reason.
>> For example, by making the conversion to String explicit it is more
>> obvious that float and BigDecimal are not really compatible.
> 
> Yeah I wonder that myself. I was just hoping to make it easier to use 
> BigDecimal, since Floats are so imprecise to use for decimal numbers :)

Which is exactly the reason why conversion to a BigDecimal should not be 
too easy.  String with decimal encoded number as input format for a 
BigDecimal is really the proper type as you can see from the name 
"BigDecimal". :-)

>> if test ?d, "some dir"
> 
> Could you explain that again?  Not sure I do understand the idiom. 
> Looks like bash?

[robert@ora01 ~]$ ruby19 -e 'puts "yeah!" if test ?d, "."'
yeah!
[robert@ora01 ~]$

Happy Easter!

	robert