Not long ago on ruby-core, matz revealed that the ruby core team is
making a shift in how they designate production vs. experimental
versions of Ruby.
In the past rubys with even numbered minor version numbers have been
production, and those with odd numbered minor versions have been
experimental. So the working assumption has been that 1.9 will
continue to be experimental, and 2.0 would be the next production
release.
However, it now seems the the ruby core team will be using the
existence of a teeny version number to indicate production status, and
there will be an upcoming ruby 1.9.1 which will be considered
production. What this seems to mean is that when 1.9.1 is released,
the api/language changes from 1.8 will be frozen and subsequent 1.9.x
releases will focus on improving the implementation. The expectation
and hope would be that at this point, production code which uses ruby
would start adapting to Ruby 1.9 with the release. The sense is also
that 1.9.1 is probably going to be this years Christmas present from
the ruby core team.
With that all said, I've been wondering what some of the 1.9 changes
would mean to Rails.
In particular, since there's also been recent discussion on ruby-talk
about it, I'm thinking about the change to the semantics of class
variables. In Ruby 1.9, class variables won't be inherited by
subclasses, instead it seems as if they act more like class instance
variables which are magically visible in instance methods.
I notice that Rails seems to make significant use of class variables,
but I'm not sure how much it relies on their inheritablility. I
figure that this is a more appropriate question to raise here than on
the general rails group.
With that all said, I've been wondering what some of the 1.9 changes
would mean to Rails.
In particular, since there's also been recent discussion on ruby-talk
about it, I'm thinking about the change to the semantics of class
variables. In Ruby 1.9, class variables won't be inherited by
subclasses, instead it seems as if they act more like class instance
variables which are magically visible in instance methods.
I notice that Rails seems to make significant use of class variables,
but I'm not sure how much it relies on their inheritablility. I
figure that this is a more appropriate question to raise here than on
the general rails group.
We make quite a bit of use of class variables and in some places
(mostly configuration variables) we rely on them being available in
subclasses. In the event that that's no longer the case we'll have to
ship a maintenance release which works around this.
Methinks this could be a p.r. nightmare. If I understand correctly,
upgrading a server's Ruby from 1.8 to 1.9 will break Rails apps that
were frozen to a specific Rails gem (which we all do, because that's a
recommended practice and is normally exactly the right thing to do to
shield an app from Rails version changes).
I think ruby core needs to make it well publicized that 1.9 has
breaking changes in it.
I fear the minor version number change won't communicate that as well
as "2.0" might. And then they will think Rails did something wrong.
My understanding from the ruby list is that 1.9 won't see the light of
day until the 2nd half of 2008, so fortunately we do have time to
figure out a solution and/or broadcast the warnings far in advance.
Why not start testing edge rails against Ruby 1.9 in the continuous
integration build (as well as on local dev machines, of course), so
that breaking changes could be caught well before ruby 1.9 goes
public.
If the usage of inherited class variables in Rails is significant,
might it not be something to be raised with the ruby core team before
they finalize the change? It's not clear to me that the change is
actually a good one, although I'm not much of a direct user of class
variables myself.
If this is something that the rails core team thinks should be raised,
the time is ripe. I'm not sure what if anything might be set in stone
by rubyconf in Charlotte next week.
If this is a tempest in a teapot, then feel free to ignore my concerns.
If the usage of inherited class variables in Rails is significant,
might it not be something to be raised with the ruby core team before
they finalize the change? It's not clear to me that the change is
actually a good one, although I'm not much of a direct user of class
variables myself.
Class variables are already fairly restrictive and we use our own
'class inheritable attributes' in most places. Any changes will
probably be for the better and we'll be able to work around them with
our own macros.
If this is something that the rails core team thinks should be raised,
the time is ripe. I'm not sure what if anything might be set in stone
by rubyconf in Charlotte next week.
I won't be in charlotte as I've had just about enough of the long haul
from Auckland to San Francisco. But I know some of us will be and
perhaps it can be discussed over dinner :).
If someone can set up a 1.9 test
environment, I think that's a good step in the right direction.