From: Roger Pack Date: 2009-04-12T03:43:05+09:00 Subject: Re: a few thoughts for ruby... >> 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. 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. >> 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). >> 4) (this one's controversial) remove the extra # for code in strings >> (i.e. "string#{code}") -> "string{code}" less typing. > > -1 > > Definitively a don't as the overhead of typing # isn't too big (plus, it > is more easily spotted) and the potential for damage caused by this is > large. True it's not too hard to type--I just think its absence would be less typing, and that the # is "too" easily spotted, but again, that's just my take on it. Actually you may have a reasonable point (easy to spot is good). The kicker is also that # is ingrained so much in existing ruby code...it would be a pretty dramatic change. >> 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 :) > if test ?d, "some dir" Could you explain that again? Not sure I do understand the idiom. Looks like bash? Much thanks. -=r -- Posted via http://www.ruby-forum.com/.