And now, something entirely impractical.
I picked up
Beginning Ruby by Peter Cooper the other day to look
for some teaching material. Flipping through, I came across a basic
feature that had heretofore escaped my notice: the
Struct class. If
you want to use a class for nothing more than bundling together a few
values, you can create a Struct instead of writing out
initialize and
attr_accessor yourself. The idiom is like
this:
class Server < Struct.new(:host, :port, :password)
def to_s
port == 6600 ? host : "# host :# port "
end
end
That particular one's from
Njiiri (which may clue you in that it took
me several months to get around to writing this post). For educational
purposes, it's nice: you can point out how we give a name to a class
(I've also tried to explain assignment as "naming" rather than
"storing"), that there's an unnamed class (classes are also objects!),
and overriding a method (which uses the dynamically defined stuff),
without any boilerplate to get in the way.
So it's tempting to use this in a lesson. Unfortunately, Ruby is a
little bit weird here, and you run into those distracting "practical"
issues about the particular language you're working in. Your classes
can't subclass Class, and thus you can't say
Foo.new like you can
Struct.new. Struct is actually implemented in C (or Java, or
whatever's native). So you have to do some handwaving.
This is because the "metaclasses" we have in Ruby are implemented, so
to speak, as singleton classes of objects (including class objects). I
do not mean this as a criticism of Matz at all, but they seem like
more of a serendipitous thing than an intentional design -- "hey, if
we implement classes in this particular way, we get this sort of
metaclassing automatically ." (The clearest explanation of why
this is that I've found is in the first chapter of
Advanced Rails
by Brad Ediger.)
I wanted to be able to just subclass Class, rather than have all that
fun power that we normally get to abuse in Ruby, only because I think
this is the clearest way to explain the abstraction. Even I still have
trouble describing singletons in plain English. Struct is intuitively
a class of classes, and factors out similar/boring stuff -- a good
practice. It could be an example of how to refactor some simple
classes, if only we could follow it.
I decided to give up on the idea for my tutorial, but it kept me up at
night. Ruby metaclasses clearly can do anything that the sort of
Struct-like metaclasses I have in my mind -- "parametric" classes, if
you will -- can do, and I can dynamically define just about anything;
why not make it happen? We
can instantiate Class itself, but the
tool we have to shape that class is singleton methods. This can
certainly be abstracted away. So, I whipped something up.
Before getting to it, though, let's visit a new construct in Ruby
1.9 and 1.8.7:
Object#tap. Apart from the obvious debugging use
described in its documentation, it makes it quite easy to factor out
this pattern:
def gimme_a_thing
thing = Thing.new
thing.do_stuff_to_it
thing
end
Into something closer to the style of functional or declarative
programming:
def gimme_a_thing
Thing.new.tap thing
thing.do_stuff_to_it
end
end
(Well, "do stuff" is obviously still procedural, but A for effort.)
Which one is "better" could probably be the subject of much debate,
but: I really prefer the second one; even though it has exactly the
same effect, it looks like "what" rather than "how" (something else I
try to beat into impressionable young heads. :-)), which is I think
easier to write tests for. I'm going to use it here, because it's
shorter.
Now, Object#tap passes the object as an argument to the block; in our
case, we are going to define a metaclass, so we want to work with
self, instead. So we define a new version,
class_tap -- by
analogy with
class_def, I suppose --- which
class_evals the
block rather than simply evaluating it:
class Class
def class_tap(&blk)
tap _self _self.class_eval &blk
end
end
And to do the following trickery, we make use of
MetAid, written by
why the lucky stiff -- it's very small, so we could always just
incorporate the bits we want into the code here, but this short file
provides a common vocabulary for talking about metaclass stuff which
is quite valuable.
Now, we can write a method to create our new classes on the fly.
Here's what I came up with:
require 'metaid'
class << Class
def meta(_super=Object, &blk)
new.class_tap do # 1
meta_def :new do *args # 2
Class.new(_super).class_tap do # 3
class_exec *args, &blk # 4
end
end
end
end
end
(Note the "
class << Class", opening the singleton, rather than
"
class Class", opening Class itself. Also, the distinction between
new and
Class.new -- they are the same method, but from inside
the
meta_def we're no longer in the Class class.) The lines of
meta itself mean:
- The value of this thing is a generated class, which
we will describe thusly:
- Its singleton class has a new method, which gives you a
value that is:
- Another generated class, which is defined by:
- the original block, which now gets run with new's arguments.
Nary an assignment in sight!
The (embarrassing) caveat is that methods in the block that
defines the new class instance cannot use
def to create methods
as normal. A
def is evaluated in a totally fresh scope (I don't
think I get the opinion behind this decision, to be honest), so we
need to use
class_def instead. This is, I must admit, rather
hideous. Perhaps someday the language will change.
But, first things first: now we can implement Struct in pure Ruby.
class MyStruct < Class.meta \
do *args
attr_accessor *args
class_def :initialize do *instance_args
args.zip(instance_args).each do attr, val
instance_variable_set :"@# attr ", val
end
end
end
end
The real Struct class does a few other nice things for you, but this
is the heart of it; I can go back to that Njiiri example and just swap
in
MyStruct for
Struct (Providing an instant performance gain
of -200%... :-)).
Here's a "shapes" example from my abandoned OO lesson:
class Polygon < Struct.new(:sides)
def perimeter
@sides.inject(&:+)
end
end
class RegularPolygonClass < Class.meta(Polygon) \
do n_sides
class_def :initialize do side_length
@sides = [side_length] * n_sides
end
class_def :area do
@sides.size * @sides.first**2 / Math.tan(Math::PI / @sides.size) / 4
end
end
end
class Square < RegularPolygonClass.new(4); end
class Pentagon < RegularPolygonClass.new(5); end
(Note that
area has no free variables and thus could actually be
defined with
def. It would just look funny.)
You only have to change one number here to make new polygon classes,
rather than accumulating parameter lint or explicitly subclassing and
redefining something implicit just for the derived class . In a way it
the exact analogue of the imperative vs. tap style described above.
There is quite a bit of aesthetics involved; one way is not "right".
Apart from the syntactical wart, I like being able to do things this
way. Ruby is, as they say, optimized for programmer happiness and the
principle of least surprise. Still, I'm sure it is quite slow, and
I don't particularly need it for any real-world application right now.
For an intro to OO it's way too much complexity to have lurking
unexplained beneath the surface and still requires getting bogged down
in the language you happen to be using. But hey! It's neat.
Way back in mid-late May, I switched keyboard layouts from standard US QWERTY to Colemak. I’d played around with the layout a bit before that and thought it seemed pretty solid, but it hadn’t been a good time to switch then. (I did, however, snag the idea of remapping Caps Lock to Backspace from that early trial though, and to this day that’s probably the most annoying thing about typing on QWERTY, because I associate Caps Lock with Backspace on both layouts now. Anyway.) This time, however, I strategically timed it to coincide with the end of classes, so I had no assignments due and could make a fool out of myself during the first few days of my summer job. Smashing success.
It only took a couple days to get past the point of extremely frustrating slowness. Two weeks in I was up to 40wpm, which was about the point where I stopped noticing that I’d taken a backwards step in typing speed, as it didn’t really hinder anything I did on a regular basis. By the end of the summer I was back up to the same speed as I’d been prior to switching (around 75wpm). I didn’t really do any typing lessons after the first few days, as I found just doing whatever I would normally do on a computer much more interesting.
The biggest hurdle after the initial adaptation of actually being able to type on the layout was, for a command-line lover like myself, dealing with “hjkl” not being a convenient way of navigating around in console apps like mutt, vim, aptitude, and less. After a bit of experimentation, I stole an idea from this page and started adapting my dotfiles to make these programs use ne for jk and st for hl, and that seems to be working out well. The worst key that this clobbers in general is n, but it’s pretty easy to remap that to QWERTY’s n, which is easy to remember and is the hardly-used k on the Colemak layout.
For any interested others, I’ve thrown the relevant dotfile snippets up here. I’d been putting off blogging this because I wanted to finish setting up dotfiles/homedirs-in-git la Joey Hess beforehand, but I figure I’ll never actually get it done if I keep using that excuse. For mutt, the given snippet goes in your .muttrc (or whatever you source keybindings into your muttrc from). The same goes for vim. Aptitude keybindings go in .aptitude/config. For less, it’s a little more arcane: first you stick your keybindings in .lesskey, and then you run the command lesskey. I also remapped screen’s escape key to ctrl-t.
Why not Dvorak?
Dvorak seems to be the most well-known QWERTY alternative around, so why didn’t I switch to that if I wanted something better? I did try Dvorak first, but the incredibly uncomfortable combination of ls on the right pinky was a complete deal-breaker. I also found it very slow-going to try to adapt to Dvorak after typing on QWERTY for years. The Colemak FAQ has some more notes on Dvorak deficiencies that it addresses.
Overall, I’ve found typing on Colemak to be remarkably lacking in anything that particularly bothers me. I still type on QWERTY a little, but mostly just for login prompts on Athena workstations and the desktop machine in my room which my roommate sometimes uses. I have to glance down at the keyboard when typing on QWERTY to get it back in my head, but generally I only need it for a few minutes anyway and it’s no big deal. As long as I glance down occasionally I can still maintain a speed level well above that of frustration. On the plus side, this means that if I look at the keyboard when typing normally in Colemak, I get screwed up because I start thinking in QWERTY. So it’s good touch-typing reinforcement in general.
(Part 1 of an ongoing series: shiny things in telepathy-glib)
I spent much of this week in Alicante. It was wonderful to have a
few days away from the beginnings of Winter in Cambridge - Alicante's
in South West Spain, right on the Mediterranean. It's a lovely city,
although it was very quiet due to the time of year.
I was invited down to Alicante by organisers of the 
When I first read 
The Open Source Repository and Observatory (OSOR), a new site sponsored
by the European Commission to foster the exchange of FOSS related
information and software among European public administrations, recently
published 
So, as everyone knows by now, 
FTWCA copyright issues, there’s interesting stuff on 
Well 
First, let me make one thing clear. This isn't constructive criticism. This is just criticism. It's directed at software that's so wrong-headed that there's no way to make it significantly better, and everyone involved would be much better spending their time doing something else instead of trying to fix any of what I'm about to describe. It's not worth it. Sit in a park or something instead. Meet new and interesting people. Take up a hobby that doesn't involve writing shell scripts for Linux. You'll be happier. I'll be happier. Everyone wins.