Well Google’s new Go language has no such limitation. If it quacks, it really is a duck in Go:

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

Well…there it is.

Stubbornella you have captivated me. I am now watching Nicole Sullivan‘s Object Oriented CSS talk for the second time. The OOCSS framework is a terse but ambitious thing in the tradition of YUI Grids CSS and Blueprint but with opinions that reach beyond grids, resets and typography.

While I have certainly not mastered the OOCSS concepts I do have some early observations I’d like to share nevertheless. This of course is dangerous territory since I risk having to eat my words later. So be it. Feel free to feed ’em to me as appropriate…

It strikes me from looking at the UML diagram for OOCSS that something is missing, or more accurately, some things are being conflated which shouldn’t be. If we’re thinking about objects and classes here the first question should be: what are we modeling? Well the semantic HTML folks might say we need to model things like paragraphs and headings, or at another level contacts and phone numbers, or at another level sidebars and navigation. These are all semantics.

When we think about modeling these things in HTML in such as way that CSS can be profitably applied, we use HTML element types to directly model semantics where we can (p element for paragraph, h1 element for top-level heading) and we use class attributes to express the rest (‘top-nav’, ‘address’, ‘phone’). If you have a look at the OOCSS UML diagram you will see in the “page layout” section a set of classes that fall into the former category ( ‘doc’, ‘hd’ for header, ‘bd’ for body, ‘ft’ for footer).

So far so good. But now how do we actually extend a class? The approach suggested in OOCSS is to change the (HTML) markup. One example from the talk is to specialize the media block class ‘media’ so that the fixed-size media is on the right instead of on the left. The suggestion is to define a new class ‘media_ext’ along with a new set of CSS rules. Then the idea is to change our HTML so that the element of interest carries two classes: ‘media’ and ‘media_ext’. And then we define some CSS for the new media_ext module, something like this:

.media_ext .fixedMedia { float:right }

This is the fundamental approach in OOCSS, so fundamental that it is on the short list of 10 Best Practices from slide 19 of the talk:

9. Extend objects by applying multiple classes to an element

The library defines a small set of base classes and a few core extensions to those. Users are invited to extend these further and we change our HTML to carry the full set of classes expressing semantics, layout and skinning too, all as separate classes.

The value in this approach is it certainly brings order to chaos. The downside is twofold: first we must pollute our HTML with layout and skinning choices and second, we must rely solely on coding conventions to ensure that each HTML element carries a self-consistent and complete set of classes.

aside: To me this feels much more akin to structured programming or maybe at best “abstract data types” than it does OO. I don’t really see language-level inheritance here, nor do I see polymorphism. But that’s just a terminological nit.

The first problem we need to solve is to get rid of the superfluous classes (on our elements). How could we make a media block (“fixed-width media object on the left with an open editable zone on the right”) into a right-handed media block without changing our HTML? Well the classic way in CSS is to use context to distinguish this situation. So let’s imagine that every odd media block ought to be right-handed. A classic approach is to have an ‘odd’ class on the element (or to use nth-child pseudo class). Perhaps something like this:

.media.odd .fixedMedia { float:right }

Where target is the fixed-width object we’d like to be on the right-hand side instead of the left. You get the idea. The problem with this approach is that we’ve just coded up some potentially reusable stuff (the {float:right} part) and we’ve got no way to reuse it in other circumstances. Also we are now guilty of committing pitfall #1 from the talk:

1. Location dependent styles

So you can see that we are definitely violating a key tennet of OOCSS. If you’re already an OOCSS dogmatist you may want to stop reading now. Still with me? OK, what if we want a right-hand media block for even rows next time? We’d have to edit that last CSS rule to look something like this:

.media.even .fixedMedia { float:right }

Yuck. What’s going on here? The problem is that CSS has no named/reusable/callable construct. No macro. No function. No Class. OOCSS does the best it can with plain old CSS by requiring us to define a new HTML class name. That lets us define a reusable set of CSS rules for it, but at the cost of polluting our HTML at each use.

I think a good way out of this is to break out of plain old CSS into a higher realm. Both SASS and CSS-SSC have a macro concept. SASS has its mixins and CSS-SSC has its base and based-on. What these actually add to CSS is named abstractions and reuse. So I could define a SASS mixin like this:

=right-hand-media
  .fixedMedia
    float: right

Now that is a reusable module. In my application I can apply that module to an element:

.media.odd
  +right-hand-media

Yay. Now I have the best of both worlds. If we have another app that wants even media items to be right-handed then we just define this:

.media.even
  +right-hand-media

The value of this is that I didn’t have to change my HTML markup in order to change the layout. There are examples of using the same approach to define a clearfix module. To those who say this approach is going to generate a lot of CSS I say, “well maybe, but I think our first priority needs to be making our source code manageable and this approach may just help us do that.”

As I already pointed out, this proposal (using SASS mix-ins or CSS-SSC macros to implement reusable modules, and then using contextual CSS Rules to apply those modules) violates a core principle of OOCSS. On the upside it solves one of the wish list items from the talk (on slide 60):

1. Extending objects—possible to make “sale module” inherit from “module”

.module{}
.saleModule{extends: module}

Now that approach is a bit different from the one I described for right-hand-media. But it is clear that mix-ins or macros could easily be used to reuse .module in .saleModule right? SASS mix-ins, for instance can be used (as in my first example) as straight-up mix-ins, or to implement inheritance. The choice is yours.

To close, I highly recommend watching the Stubbornella’s presentation. Twice. There is just a ton of gold in there. Meanwhile, I’ll go experiment with SASS mix-ins and let you know how it works in practice and how it can be combined with some of the other principles highlighted in the talk.

Now what if you don’t use cookie-based session storage at all? Well, just because you aren’t using cookie-based session storage doesn’t mean you aren’t using cookies. If your application has sessions at all, be they memcached ones or ActiveRecord ones, it is probably using cookies. It’s using cookies to store the session id so that when a request arrives, that id can be mapped to the corresponding session storage.

“So what” you say. “Well” I say… isn’t it cool that Rails generates that big random secret for you when you use cookie-based session storage? When we are not using cookie-based session storage, and that secret is not generated, don’t you wonder what secret is being used to secure your session id’s? You see, a session id must be hard to guess lest bad people gain access to your site. Usually when you want to make something hard to guess, you start with a secret and mix that with something that changes a lot and hash the whole shebang. So I went in search of this other secret.

What I found was that Rails calls CGI::Session#create_new_id to generate new session id’s. That routine uses no secrete per se. It hashes (MD5) a combination of:

1. the current date and time (expressed as a human-readable string)
2. the microseconds elapsed since the last second (expressed as a human-readable string)
3. a pseudo-random number greater than zero and less than one (from Kernel#rand)
4. the current process id number
5. the string ‘foobar’

Notice there is no secret keying material there. “But what about the Kernel#rand call Bill!” I hear you saying. If you go have a look at Kernel#rand and Kernel#srand you’ll see that if rand is called before srand is called with a number parameter then the random number will be generated from a combination of:

1. the current time
2. the process id number

So the security of these session ids hinges on the secrecy of current time (on the server running Ruby) and the process id. Given that the system time is returned in HTTP headers and process id’s are often in the hundreds or thousands, it’s only really the microseconds that are hard to guess here, from a statistical standpoint. Others have expressed similar concerns.

If you’re worried about this two suggestions come to mind:

• time out sessions on the server so that an attacker has to guess faster
• monkey-patch CGI::Session#create_new_id to hash its result with a great big old 128 character secret

Updated: October 15, 2008 expanded analysis of Kernel#rand and Kernel#srand and updated suggestions.

Quickie findings: the in-development Ruby 1.9 VM performed best — beating 1.8.6 by a factor of two. For the numbers (comparing 1.8.6, 1.9 pre-release, and Rubinius pre-release) have a look at the spreadsheet and chart over on Google Docs. Also of note: the Ruby solution did beat the four minute time limit for N=10MM given in the problem statement. This was on random input. Worst-case performance would not be as good.

It makes me happy that the Ruby solution had adequate performance. Also it was interesting to see how the Ruby language fit for a problem you’d usually see done in LISP. I would have liked to have dynamic scope to do a cleaner implementation of @@largest_so_far. On the other hand, “memoization” is pretty natural in an OO language like Ruby — you create an instance (of Skyline) for each context and simply use instance variables to hold previous results.

update Nov 15, 2007: Reader Sumudu points out that version 5 neglects to reset the timer between pruning and non-pruning variations. Version 6 rectifies this error. With that change it’s apparent that the pruning has no positive effect. In fact non-pruning actually wins by a small amount for N=1 to N=100,000 on my MacBook Pro.

I can of course invoke each with a block and print the numbers out:

With predictable results. But I cannot use a Nums as if it were Enumerable (unless I include Enumerable in the definition). So this:

Yields “undefined method `collect’ for # (NoMethodError) “

Folks who know Ruby will say “well — you have to include Enumerable”. To which I say “Nums already quacks like an Enumerable doesn’t it?” Or, more accurately — Nums quacks like something that satisfies the (un-named) interface that an object must implement in order to include Enumerable (to be enumerable). Nums implements the each method, which is all that Enumerable needs (so long as no one calls the ordering methods on Enumerable).

It just seems kind of wrong that I have to either include Enumerable directly in my class — or I have to explicitly add the interface after the fact using one of Object#extend (on a Nums instance), Object#instance_eval (on Nums), Module#include or Module#append_features on Nums, or by writing another class decl for Nums to extend it that way.)

The underlying issue here is that there’s no generic functions in Ruby. Topher Cyll has implemented a multiple dispatch gem for Ruby that does something similar. It’s not quite generic functions though because dispatch is scoped to a target object (receiver of message) whereas generic functions (in general) pattern match on all parameters — including message target.

So I got to playing around a little. I reasoned I could use method_missing to mixin Enumerable and others at runtime like this:

Then I could just “include RespondsToGenerics” in classes I wanted to have this behavior. It’s still ugly that I have to include anything, but hey — it’s a start. ‘course what I got then was:

Cuz Ruby won’t let me bind an Enumerable method to an Object that doesn’t include Enumerable. Augh!! In what way is that behavior aligned with the Zen of Duck Typing? I quack like a duck! Trust me Ruby. Back to the drawing board.

So to make this work I think I need to create a full-fledged proxy object (that includes all the interfaces in question). Then I can wrap each object (in method_missing) with the wrapper and the wrapper can forward the message using Object#send. But hang on, if the wrapper includes all the interfaces in question then I’ll have to use Module#undef_method to undef all the methods of the included interfaces so that method_missing gets called. Double-ugh. Thinking. Thinking…

What I really want is for the Nums class definition to be devoid of any code pertaining to (what should be) the generic mixins. What I really want is to introspect when Nums is defined — and if Nums implements the required protocol: namely, that Nums implements an each method, then Nums should get “tagged” with the Enumerable interface. Something like this say:

The idea is that I should be able to explicitly and in one place declare in any mixin module the requirements that module has on classes you might wish to mix it into. If I could do that then maybe I could make the actual mixing happen automatically — yielding mixins that are composed environmentally — not at each point of use. I really like the fact that this approach reifies the requirements on the target class. For example you can see that to mix in Enumerable the “each” method must be defined. It’s in code now — not just buried in the Pick Axe book.

Now implementing mix_in_when is pretty straightforward. We define it in class Module and we keep track of the predicate passed. Then some time later we want to do the mixing. That’s where the questions arise.

When should we do the mixing? I was initially tempted to try and redefine Class::new (a class method.) See, I could just hook creations of instances of class Class and at that point I’d have control and I could evaluate the predicates for the new class and inject the modules as appropriate. This turned out to be problematic for a couple reasons.

First off, hooking Class::new doesn’t work in all cases. In particular Class::new doesn’t get invoked when the class Foo;end syntax is used. Class::new is invoked only when the Class.new syntax is used. Then there’s the Class::inherited approach which does get called in all cases but it still wouldn’t really be what we want. Again I hear the crescendo of the Ruby cognescenti. Ruby class definition is dynamic. The various syntactic forms used to define program elements such as methods, instance variables and the like are mostly method invocations — evaluated not at compile time as those of us brutalized by long years of C, C++ and Java have been conditioned to expect (bell dings, Bill drools) — but evaluated at runtime. As a result, even if you hooked Class::initialize the actual class of interest wouldn’t have its methods defined yet. The method definition code runs in the context of the newly created Class object. And let’s say you could get a hook called after that initial method definition code ran. You wouldn’t be sure even then that the class wasn’t going to change on you — since idiomatic Rubyists are continually modifying other peoples’ classes at runtime — adding methods, adding variables.

Nope, there’s no easy way around the fact that you the programmer are going to have to choose when to perform the Big Mixing Act. For some applications you may even want to do it repeatedly. So here’s what the code actually looks like (I call it auto_mixins.rb):

With that code required in your project you can call Module.AddAutomaticMixins and begin using any conformant object as though it were Enumerable — without ever including Enumerable in the class yourself. Similarly for Comparable. Here’s an example:

Run it yourself and see. Is it something I’m dying to use in my next project? Well I’m not sure. My head is still spinning. In a good way. At this point it’s more of a thought experiment. I’m curious what other folks think about the general idea.