Complete Ramblings

Nothing is perfect. Nothing. I am not; you are not. Ruby is not and Rails is not (though it seems better than anything I’ve used/evaluated so far, regardless of language).

Zed is definitely not perfect. I’m not sure he’d say the same about himself, but you’d have to ask him. Lord knows that after reading his “rants” I’m not going to ask since, frankly, he scares me. Sure, he makes valid points and raises some concerns that even I might share. The question is, were he applying to work with/for me and I came across his blog, would I want him on my team? That question I already know the answer to.

I want to point out that this “rant” is in no way meant to discredit his work, especially on Mongrel. My coworkers and I are currently using it and it has served us well. I really just think the guy needs… medication? therapy? I think people may take his thoughts more to heart if he’d just tone it down a few notches.

As a final note, I’ve always thought about trying to learn guitar. I thought it’d be fun. If this is what learning to play guitar does to you, however, count me out.

All comments are welcome, even yours Zed.

If you’ve done much in flex, you may have used the “…” notation in a method signature to indicate that the function takes a dynamic number of arguments, such as:

private function doIt( ...args ):void

… then called the method:

doIt( 1 )
doIt( 1, 2 )
doIt( "some", "other", "stuff" )

The question is this: from within that method, how do you send those same arguments on to another method that accepts a dynamic argument array? You can’t just pass the “args” array, as the method called will only see 1 argument; the array you passed it. Instead, you need to “explode” the array into its’ original parts. Here’s the most simple way I’ve found to forward that array on to the next method:

public function doIt( ...args ):void
{
   var someObject:SomeType = new SomeType()
   someObject.someMethod.apply( someObject, args );
}

The “apply” method of Function does exactly what we need. Now “someMethod” will have it’s own argument array, and be able to access them the same way you were able to from within “doIt”.

This all came about when we began writing a wrapper of sorts for WebServices. We created our own RPC class, with a “call” method that accepts the parameters, and we needed to forward them on to Operation’s “send” method. Below is a much simplified example:

import mx.rpc.soap.Operation;
public class RPC
{
  public static function call( operation, ...params ):void
  {
    //...code to initialize WebService "svc"
    var op:Operation = Operation( svc.getOperation(operation) );
    //...more code (unimportant)
    var token:AsyncToken = op.send.apply( op, params  );
    //...code to hook up handlers
  }
}

Math in programming just generally sucks. I come from a mainly Java background, and recently I’ve been using Ruby. But in both cases, the statement holds true. I know this isn’t really a new problem, but for god’s sake, it’s 2007; why is it still a problem?

Using Ruby, let’s suppose we have a simple math problem… and we want to check equality:

1.2 + 1.0 == 2.2 (returns true)

Yay, it’s correct! But that’s not really much to ask of a language is it now. Let’s switch it up just a little bit:

1.2 - 1.0 == 0.2 (returns false)

Uhh… Ruby? You OK? I really don’t understand how this is acceptable. I know the argument that we generally work and think in a base10 system, while computers generally store numbers in binary, and there’s no exact way to store many numbers. But shouldn’t that be fixed (and by fixed, I mean an easy way provided for us to perform exact base10 math), assuming once again, we generally work in base10? i.e. when I subtract 1 from 1.2, shouldn’t I get exactly 0.2?
Anyway, if you do a little research, you’ll find that BigDecimal is supposedly much more accurate when performing calculations, so let’s try that:

require 'bigdecimal'
BigDecimal.new('1.2') - BigDecimal.new('1') ==
   BigDecimal.new('0.2') (returns true)

Yay, it worked! …but who wants to type ‘BigDecimal.new’ a thousand times? Dig a little further and you’ll find a BigDecimal utility, which adds functionality to other Ruby Numeric classes to convert them to BigDecimals:

require 'bigdecimal'
require 'bigdecimal/util'
1.2.to_d - 1.0.to_d == 0.2.to_d (returns true)

Still works, and it’s definitely cleaner, but remembering to append ‘.to_d’ may be somewhat of a pain (and unnecessarily ugly.) The innaccuracy of Float can still bite you, however; check this out:

require 'bigdecimal'
require 'bigdecimal/util'
x = 1.2000000000000000001.to_d
puts x.to_s('F') (prints 1.2)

Yep, our 1 in the 1/1000000000000000000th place at the end is lost. This is probably because BigDecimal is aware of the innaccuracy of Float, and since that was of such small value, it assumed it was just a precision issue and is dropped. Frustrating!

Another issue for us might be that using BigDecimal in place of Float probably has more overhead; I don’t personally have any benchmarks to compare the two. But, then again, I don’t really need them. For me, being precise far outweighs it being fast (to a point of course). If I was performing some super-intensive process, that did crazy math, and as a result I only needed an answer that was pretty close but not exact, I’d probably give Float a chance. But until then, it’s BigDecimal for me, despite it not being the easist/cleanest/prettiest solution.

At any rate, I can live (for now) with implementing BigDecimal in this way (or ‘new’ing them up when appropriate.) But if you happen to use ActionWebService in Rails, you have another problem. Currently (as of version 1.2.3), when you define your API, and use the :float datatype, you’ll find this does in fact use Float to convey numbers. Dig a little, and you’ll find that in their SVN repository they may be working on changing this to use BigDecimal instead. One can only hope!

A coworker and I attempted to dig in and try to convert it ourselves for use in a current project, but that attempt was fairly short-lived, and we instead use the “.to_d” method above to convert them to BigDecimals once inside the service method. This works for us, since we’re generally dealing with dollar amounts that aren’t terribly huge, so we’re only concerned with accuracy to the penny.

I fully intend, at some point, to revisit this issue and perhaps instead of replacing :float to use BigDecimal, using :decimal or :bigdecimal, thus leaving the ability to use Float if so desired. Hopefully by the time I get to it, they’ll release a new version with it already implemented. I can dream can’t I?

As I just said, this blog is probably pointless… but alot of the time, I have crap to say and nobody will listen, so I may just type it here, and you can deal with that.

Oh, and don’t vote for Hillary. She’s a socialist weasel.