That has a snow ball in hell's chance. Really, it does.

Awhile back, I decided I needed to solve a problem I was having. No, it wasn't a plumbing problem. (Whew, says my reader. They come to this blog thinking I'll write about politics, or transgender issues or something and all they see is "Plumbing from a Man in a Dress"...) :-) ... Where was I? Oh yes. I was writing some code, in PHP, and I decided I needed something other than git's arcane and basically non-existent versioning to keep track of the code. (That checksum is *not* a version flag. It's an unnecessarily confusing and pedantic way of proving that Linus Torvalds refuses to understand normal programming problems if they are connected in any to "people".) I came up with something that was remarkably similar to the way Ruby does it. :-)

But with one significant difference.

In Ruby, you have the idea of a "Gem"; it's a self-contained bit of code that does something, and it has a defined directory [sic] structure. The entire edifice relies on a single property: the version number. Here's how: when you download the gem from rubygems.org and install it - the gem name is transformed from "my_widget" to "my_widget-1.0.1". If you supply version 1.0.2, the gem name is, predictably, "my-widget-1.0.2" When I was pondering my problem, I didn't know about Ruby's code naming pattern; it was so long ago it might not have coalesced. However, I did think of that pattern; I rejected it because it was cumbersome.

I came up with "mywidget", and a numbered folder for the version. A file would point you to the right folder. So if you inadvertently released a buggy bit of code - a big consideration for me! - you could simply change to the older version and all would be well.

An example:

mywidget/1.0.1/bits_of_code
mywidget/1.0.2/bits_of_now_fixed_code
mywidget/mywidget.php/rb/whatever <- point to the relevant folder

So, in Ruby, mywidget.rb would say:
current_version = "1.0.2"
require 'current_version/some_bit_of_code'

(I'd do the PHP version, but quite frankly I'm having a brain-freeze on it. Sorry!)

Ah:
The PSR-0 standard would be:
mywidget\$VersionNumber\BitsOfCode

(For some unknowable reason, PSR-0 uses backslashes, like Windows and MS-DOS... :-) <- Just causing trouble smiley... )

The advantage with my naming standard was that all the ancillary bits only have to be published once. Not that that is such a big deal in the day and age of humongous disks... Except it is, isn't it?

When we waste space on a zillion copies of the MIT license, for instance - the standard license for Ruby code - it becomes annoying. It's not efficient, that's for sure! If we ever get to the point where our file systems really are databases, then it won't be so bad - supply a pointer, with a bit of logic to make it's actually pointing at something relevant and Bob's yer uncle. (And who doesn't have an Uncle Bob? ... Erm, I don't. :-) )

But one of the main problems I thought about was common code. Let's say you have some code that doesn't change very often - there's a common bit of code called "deep merge", it merges to two simple arrays in a common-sensical and mathematically correct way, and it doesn't change. The problem has been solved and everyone wisely includes that bit of code when they need that feature. It's often accompanied by a "Thanks to whomever produced this bit of code". So my idea would have this included in a folder "common code"; I don't know if you need the same 'deep merge' as me, but I do know I need it. So I pop it into a common, known, folder and Uncle Bob has a Mrs. (So to speak... :-) )  The point being: I don't have to repeat it. (I do have to repeat it across "gems" with different authors and purposes, however.

Currently I can do something like that in PHP. But in Ruby? Not a chance.

Anyway, my musings don't get rid of the 'code management' problem - someone still has to go in there and delete unneeded code. And, without automated checking, there could be a security issue; that exists whenever you leave unneeded and old code lying around on your server, so it's not exactly a "new" problem. The biggest problem it solved was versioning.

I've been a system admin; I've managed large networks. When I did such foolishnesses for a living, one of the most frequent issues I've come across is version mismatching. Now, PHP is embracing interfaces and abstract classes as a partial solution to that problem. Ruby programmers break out in hives and think you're waving wooden stakes at them if you even suggest such heresies. Personally, I like interfaces - they're a contract, and I like those - and abstract classes (who doesn't want functionality for free? That's the basic idea behind gems...) What I'd really like is a sensible versioning system that doesn't rely on my repeating code that hasn't changed!

Anyway, it was just a thought. I tried implementing it in PHP (the code worked) but tossed it all out when I got fed up with Drupal's foibles. I did look into writing it into Ruby, but the whole gem system is entrenched and is nothing if not conservative. So, in a moment of idleness, I wrote about My Idea. Will anything come of it? I'd be surprised if it did.

And you know what? I'm good with that. :-)

Carolyn Ann