Re: a few thoughts for ruby...

On Sat, Apr 11, 2009 at 1:35 PM, Colin Bartlett <colinb2r@xxxxxxxxxxxxxx> wrote:
Roger Pack

Thought I'd pass these thoughts by the readers here before sending them
to core.  They're my current wish list :)

1) add an Object#in? method to complement the existing Array#include?

Joel VanderWerf

It's not really symmetrical. Array has an #include? method because it is
a collection. Object has #in? because it is--what? A potential member of
a collection?

Robert Klemme

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.

Sometimes the best (or better) usage depends on the context.
For example, on some occasions we use:  Integer === object
and on other occasions we use:          object.kind_of?( Integer )
So I'm not against this on principle, and for me the question is
what is the balance between not adding things unless we need to
and does this make things easier in a significant number of cases.
I don't know the answer!


Roger Pack
4) (this one's controversial) remove the extra # for code in strings
(i.e. "string#{code}") -> "string{code}" less typing.

I'm not in favour, for Robert Klemme's reasons.


Roger Pack

5) add a BigDecimal(float) method.
 -> BigDecimal.new("%f" % float)

Robert Klemme

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.

Roger Pack

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 :)

Then probably best to start with BigDecimal and keep using it?
We can always use  BD = BigDecimal ; BD.new( "123.456" )
and I seem to recall that there's a way to assign a method to a variable
which could reduce this to BD( "123.456" ). I think it's important
to normally use strings to get BigDecimal values to avoid precision errors.

True, so I'd agree that encouraging Float -> BigDecimal conversions
isn't a great idea. OTOH, what I would like to see is BigDecimal (and
maybe even Rational) literal syntax in Ruby in the future, e.g.

1.23 # Float
1.23d # BigDecimal
a =1 # Fixnum
a/2 # => 0
b = 1r # Rational
b/2 # == Rational("1/2")

Essentially, provide a way to make working with exact numbers
convenient without necessarily adopting all the behavioral changes of
the mathn library (which you may want to avoid in order not to break
older code.)

.

Relevant Pages

  • Re: inconsistent behavior of >FLOAT
    ... he has to implement the checker by himself; ... checks the syntax exactly (and without blanks or empty strings). ... The intent of>FLOAT is to do its best to convert anything even remotely convertible. ...
    (comp.lang.forth)
  • Re: CComboBox-Droplist: float values?
    ... Store the float in the ... a trick, however: you can't cast a float to an LPARAM without causing ... Why not just use atof() on the strings and compare the results? ...
    (microsoft.public.vc.mfc)
  • Re: CComboBox-Droplist: float values?
    ... Store the float in the ... a trick, however: you can't cast a float to an LPARAM without causing it ... Why not just use atof() on the strings and compare the results? ...
    (microsoft.public.vc.mfc)
  • Re: Why doesnt Float() work the same as Integer()?
    ... Michael W. Ryder wrote: ... ran into a problem with converting Strings. ... later converting the Float to an Integer. ...
    (comp.lang.ruby)
  • Re: Console.WriteLine(s) Is Missing Line Terminator?
    ... Let me step in and support Mattias here. ... as a string concatenation operator only for historical ... If I don't know if those are strings or numerics, ... reasons", to me it's like saying "Say Hasta La Vista to ...
    (microsoft.public.dotnet.general)