Rails, Class Variables and Ruby 1.9

Hi,

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.

Comments?

-- 
Rick DeNatale

My blog on Ruby
http://talklikead
uck.denhaven2.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 23, 6:40 pm, "Michael Koziarski"
<mich...koziarski.com> wrote:
> 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.

Jeff


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

- Rob

On 10/23/07, Jeff <cohen.jeffgmail.com> wrote:
>
> On Oct 23, 6:40 pm, "Michael Koziarski"
<mich...koziarski.com> wrote:
> > 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.
>
> Jeff
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 24, 2007, at 3:03 AM, Rob Sanheim wrote:

>
> 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.

I don't think we have full coverage, so that's not going to
work.  
Besides, the tests might have to re-written for 1.9 too.

Manfred

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> I don't think we have full coverage, so that's not
going to work.

We do, however, have > 0 coverage ;)  If someone can set
up a 1.9 test
environment, I think that's a good step in the right
direction.

> Besides, the tests might have to re-written for 1.9
too.

I wouldn't anticipate any breakage of that magnitude,
jeremy's been
committing 1.9 related changes for a while so we're not
flying
completely blind.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On 10/24/07, Michael Koziarski <michaelkoziarski.com> wrote:
>
> > I don't think we have full coverage, so that's not
going to work.
>
> We do, however, have > 0 coverage ;)  If someone can
set up a 1.9 test
> environment, I think that's a good step in the right
direction.
>
> > Besides, the tests might have to re-written for
1.9 too.
>
> I wouldn't anticipate any breakage of that magnitude,
jeremy's been
> committing 1.9 related changes for a while so we're not
flying
> completely blind.

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.
-- 
Rick DeNatale

My blog on Ruby
http://talklikead
uck.denhaven2.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---