use Perl

http://search.cpan.org/~bingos/metabase-relayd-0.18/bin/metabase-relayd

Email went away because the expense of operating the required services became to high for the people who were donating the machine-time for free, and because the technical debt inherent in the design was too high.

The relayd above is already in use by heavy testers.

"FWIW you can already call object_id($obj)."

Oh, of course, because although it is advertised that you're importing it to be called via your package as a method, it can be imported in for use as a function. Hooray!

Perhaps you could add something like
Object::ID->object_id_for($object)

Or use Object::ID qw(obj_id);

These would both avoid UNIVERSAL and avoid needing to add *anything* to *any* class *ever*.

Every time someone puts something in UNIVERSAL, %%RND_BAD_THING%%.

I am continually impressed with your calm, reasoned response to the onslaught of boorish armchair compiler designers. I don't know why people feel good about attacking other people, but it makes me feel good when I see responses like yours.

...keeps reminding me of http://www.youtube.com/watch?v=UW2_3rvNUL8

I'm a snowplow (programmed not to know that I'm a snowplow).

Like the other said, use die.

Also, consider using Try::Tiny to replace eval. It's a very small, VERY helpful tweak to how eval works.

I have seen exactly one library on the CPAN that uses the "return undef and set $@" pattern. It is bizarre and annoying, and not like anything else. When I mentioned it to a coworker, he sputtered and said something like, "WHY WOULD THEY DO THAT???"

Don't be that guy!

Good plan. I'll only be going if I get a talk accepted, which means I better submit one really soon. I'm not sure a talk on DZ will be accepted, but I think it's what I'll submit.

If I go, I will definitely order cake, and will inform you of when you may obtain a slice and a glass of ice cold milk.

I think I might have to decline partaking of that.

OSCON includes my birthday again this year. Maybe I'll order a cake to eat there...

I'm not a big fan of version numbers meaning anything but "newer," but I'd always suggest 1.YYYYMMDD over YYYYMMDD because later if you decide that 20100720 is a terrrible version number, you're kind of stuck with it. If you used 1.YYYYMMDD, you just bump to 2.000.

You definitely haven't been a pain in the neck, you've provided consistently useful reports that almost always allowed me to quickly make releases that greatly improved the chances of my software to "just work." So, thanks very much!

Git Triforce

I've had this page open in a tab for days now, and I keep meaning to decide whether I should reply with anything more than "Aw, shucks!" but since I can't think of anything much to say, I'll stick to that. It's always great to see you around and I hope to split a burger with you again in 2010. I feel that way about almost the whole community, which is great. It's like my job came with a built-in community of friends, potential friend, and support group members. I hope it stays that way until I retire and afterward!

...why would you use Exporter when Sub::Exporter is right there? I mean, it's practically a parameterized role itself...

That is extremely exciting! I didn't know SQLite was adding this feature, but I look forward to incorporating it into our code. Thanks for helping to keep things up to date.

I think hdp was asking an honest, simple question. I think your answer is "yes, subclassed override should also warn if not marked," with added explanation. Is that correct?

I have no strong feelings either way, although I'd rather all my existing code didn't go crazy with warnings. I just wonder what your opinion is on other forms of method occlusion or augmentation.