Rails vs. Ruby Evolution

[gwtmp01]

I was just reading through http://scottraymond.net/articles/
2006/02/28/rails-1.1, which gives an overview of the next Rails release.

I noticed a number of extensions to the core ruby classes:

Object#to_json
Enumerable#group_by
Array#in_groups_of
Hash#to_xml
Array#to_xml
Object#extended_by

and so on. Earlier versions of Rails also have lots of extensions to
the core libraries.

Is anyone else concerned that the rapid evolution and adoption of
Rails is de facto
forking the core and standard libraries of Ruby?

I don't like the idea of having to know if I'm looking at Ruby on
Rails or Ruby Classic.


Gary Wright

 

[Bill Kelly]

I noticed a number of extensions to the core ruby classes:

Object#to_json
Enumerable#group_by
Array#in_groups_of
Hash#to_xml
Array#to_xml
Object#extended_by

and so on. Earlier versions of Rails also have lots of extensions to
the core libraries.

Is anyone else concerned that the rapid evolution and adoption of
Rails is de facto
forking the core and standard libraries of Ruby?

On the other hand, one of the things I love about Ruby is that
applications and libraries are *allowed* to extend core classes.

I don't know Rails well enough, but I wouldn't be surprised if
they've factored these extensions into a library one could
require separately/independently from Rails?

I like the approach taken by Nitro ( http://www.nitrohq.com/ )
which seems to be working in close collaboration with the facets
( http://facets.rubyforge.org/ ) library. I'm just learning
Nitro, but from what I've read, they seem to be consciously
factoring their core extensions out to the facets library where
appropriate, which makes those extensions available for anyone
to use, on a method-by-method granularity. Neat.


Regards,

Bill

 

[Ryan Leavengood]

Is anyone else concerned that the rapid evolution and adoption of
Rails is de facto
forking the core and standard libraries of Ruby?

I don't like the idea of having to know if I'm looking at Ruby on
Rails or Ruby Classic.

Yes this could get tricky and/or dangerous.

But it makes me wonder: if the Rails guys found these so useful and
needful then why not add some to the standard library?

It would at least be nice if they were easily required and used
outside of Rails (this may be the case, I haven't looked lately.)

Ryan

 

[gwtmp01]

But it makes me wonder: if the Rails guys found these so useful and
needful then why not add some to the standard library?

I'm sure that some features could be incorporated into the
standard distribution. It just seems like the change rate
of the standard distribution is about an order of magnitude
smaller than the Rails change rate. At its current pace,
the Rails distribution will become the de facto Ruby dialect
in short order.

What I would really hate to see would be the same feature implemented
in slightly different ways in the standard library vs. Rails.


Gary Wright

 

[Seth Rasmussen]

I was just reading through http://scottraymond.net/articles/
2006/02/28/rails-1.1, which gives an overview of the next Rails release.

I noticed a number of extensions to the core ruby classes:

Object#to_json
Enumerable#group_by
Array#in_groups_of
Hash#to_xml
Array#to_xml
Object#extended_by

and so on. Earlier versions of Rails also have lots of extensions to
the core libraries.

Is anyone else concerned that the rapid evolution and adoption of
Rails is de facto
forking the core and standard libraries of Ruby?

I am not concerned. This is why the language is open.

I am perplexed by the notion some seem to have that the open nature of
Ruby is really just something like a trophy wife that you don't
actually love, but love the idea of.

I don't like the idea of having to know if I'm looking at Ruby on
Rails or Ruby Classic.

I don't either. I think a healthy dose of familiarity with both should
foil that potential "crisis."

 

[Kev Jackson]

I am not concerned. This is why the language is open.

I am perplexed by the notion some seem to have that the open nature of
Ruby is really just something like a trophy wife that you don't
actually love, but love the idea of.

On the other hand, if the rails team are finding it useful to have these
extensions to the stdlib, maybe its worth having a discussion on wether
or not some of these changes should be rolled into the standard? Yes
the core is open for all comers - which is great, but are the usecase
for these changes sufficiently large enough to warrant consideration
into the core of ruby, or will they always be just useful for web
development and therefore should be contained within Rails?

Kev

 

[pat eyler]

 

[hunt]

I don't think it's the openness of the classes that anyone is worried
about, it's the potential for divergence when a significant percentage
of the language's users come from a superset of the main language.

This is a great opportunity (as has been mentioned) to really look at
the additions made by the Rails team. Some of those additions are
likely candidates for inclusion into the core and/or stdlib. Others
could be extracted into a library (a la nitro and facets) to allow
wider use without having to include Rails.

Most of these methods are in activesupport which is a separate gem.

 

[Avdi Grimm]

I like the approach taken by Nitro ( http://www.nitrohq.com/ )
which seems to be working in close collaboration with the facets
( http://facets.rubyforge.org/ ) library. I'm just learning
Nitro, but from what I've read, they seem to be consciously
factoring their core extensions out to the facets library where
appropriate, which makes those extensions available for anyone
to use, on a method-by-method granularity. Neat.

There's a fair amount of overlap between ActiveSupport and Facets,
from what I've seen. It would be nice if the Rails team would
collaborate with the Facets team, since the original intent of Facets,
as I understand it, was to provide a single source for all the handy
extensions people were coming up with.

~Avdi

 

[Peter Fitzgibbons]

------=_Part_2273_7498038.1143039165161
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Most of these methods are in activesupport which is a separate gem.

My take on this is that this question is a question of language domain.
Ruby is domain-agnostic. The objects and methods available in core and
stdlib seem to be the medium-common-demoniator of all neded facilities and
standard routines to produce solutions to ANY computational problem.
The web otoh, and Rails specifically, is a domain. So it makes a lot of
sense for the framework, I would say any framework, to extend the language
to resolve the medium-common-demoniator standard routines and facilities. =
I
take Date as my pet example. Date manipulation on the web, especially thos=
e
coding to multiple-timezone, is painful enough. It's nice to have 1.day in
your code instead of a 3-level routine nesting to be able to do time-zone
calculations and manipulations.



--

 

[Eric Kidd]

I was just reading through http://scottraymond.net/articles/
2006/02/28/rails-1.1, which gives an overview of the next Rails
release.

I noticed a number of extensions to the core ruby classes:

Object#to_json
Enumerable#group_by
Array#in_groups_of
Hash#to_xml
Array#to_xml
Object#extended_by

and so on. Earlier versions of Rails also have lots of extensions
to the core libraries.

Many of the most useful Rails extensions are actually provided by
ActiveSupport, which can be installed as a gem and used from non-
Rails applications.

Most interesting to me, though, is Object#to_json. This serializes
basic Ruby types in "JavaScript Object Notation", i.e., as JavaScript
literals. This is obviously web-specific, but in a web environment,
it needs to be defined on Object, so that you can serialize any type
(or get a meaningful error).

This is a nice feature of Ruby: You can add new polymorphic behavior
to other people's classes, which requires caution, but can be very
useful in the right circumstances. It's sort of like a single-
dispatch version of generic functions.

Cheers,
Eric

 

[stu]

It would be nice to see them do Object#ROR_to_json so its know what is
really 'core' and what is a rails thing, prefix things with ROR or
something.

I dont want to know rails, and have no plan to use rails, and I
shouldnt need to know rails to know ruby as seth implies further down
in the thread.



-stu

 

[gwtmp01]

Many of the most useful Rails extensions are actually provided by
ActiveSupport, which can be installed as a gem and used from non-
Rails applications.

[...]

This is a nice feature of Ruby: You can add new polymorphic
behavior to other people's classes, which requires caution, but can
be very useful in the right circumstances. It's sort of like a
single-dispatch version of generic functions.

I think it is great that the language is flexible enough to allow these
sorts of extensions. I understand that they are all bundled into
ActiveSupport (or Facets) but that doesn't remove the potential for
syntactic or semantic clashes or overlaps between ActiveSupport, Facets,
and the standard distribution.

The proliferation of core class add-ons doesn't really matter if they
are small additions used by a couple of projects. When it becomes
large additions used by hugely popular frameworks, then it starts to
become a different ball game.

I've been playing with ActiveRecord but the price for doing that is
that much of ActiveSupport is also dragged in even though I'm not using
it directly. If I were to release my project it would now be
dependent on
ActiveSupport simply because ActiveRecord depends on it.

I'm not taking a position on the particular additions in Facets or
ActiveSupport. I'm just uneasy about where this is all heading.


Gary Wright

 

[Guillaume Marcais]

Le 22 mars 06, =E0 10:34, stu a =E9crit :

It would be nice to see them do Object#ROR_to_json so its know what = is
really 'core' and what is a rails thing, prefix things with ROR or
something.

This is rather ugly. Wouldn't namespace be able to solve this issue in=20=

a cleaner way?

Guillaume.

 

[Hampton]

Kev-

I think you've got the right idea.

I don't think it would be the rails developers job to extend Ruby.
Changes to Ruby need to be made much, much more carefully than Rails.
And, that's a good thing. A little stability in a language and taking
the time to really understand a feature as it goes.

Now, the idea of multiple versions of ruby appearing is simply not
going to happen. All that Rails is doing is adding some methods which
the team found useful, to the standard core of objects. They are not
modifying the actual ruby code, but doing inline extensions.

Deciding if they end up in Ruby Core propper should be the decision of
the Ruby Core team. Its their responsibility to be the keepers of the
core of the language and so they should argue out on there thread if
any of these niceties should be added to the standard distribution.

Rails is just an application. One I use an awful lot, but its just an
application framework, not the language. And, it doesn't pretend to do
anything more. (Which, is why I agree with the domains point brought up
by Peter)

-hampton.

 

[Gregory Brown]

I am not concerned. This is why the language is open.

I am perplexed by the notion some seem to have that the open nature of
Ruby is really just something like a trophy wife that you don't
actually love, but love the idea of.

Very well put. +1

 

[Trans]

The proliferation of core class add-ons doesn't really matter if they

are small additions used by a couple of projects. When it becomes
large additions used by hugely popular frameworks, then it starts to
become a different ball game.

This is something Facets was designed to address. When using facets you
can require just the particular methods your application needs. While
obviously this doesn't completely solve the issue of potential
conflicts it helps mitigate it a great deal.

T.

 

[Seth Rasmussen]

It would be nice to see them do Object#ROR_to_json so its know what is
really 'core' and what is a rails thing, prefix things with ROR or
something.

I dont want to know rails, and have no plan to use rails, and I
shouldnt need to know rails to know ruby as seth implies further down
in the thread.

No, I don't. Please read more carefully.

Regarding uneasiness and dependency issues... if you're not going to
DIY, how much room do you have to complain? Well, of course we can all
complain all day, but... what are you going to do with that?

If you're going to depend on the work of others, you should expect
some restrictions on your ideals.

It's just what I sense as this sort of Chicken Little, obsessive
control type of worrying that seems unwarranted. If the community
wants to take some stuff from Rails and put it in core, then great,
let's do it. If you want an ActiveRecord that doesn't depend on other
libraries, then write it. Etc.

Many are so worried about Rails somehow ruining Ruby when, for my
money, I'm just happy and excited that such tools exist. You can
always take core Ruby, WHATEVER that is, and make it WHATEVER you
want. You can always rewrite a better Rails. You can always write a
Rails-killer.

What more do you want?

 

[stu]

In reply to seth;

well your quote

I think a healthy dose of familiarity with both should
foil that potential "crisis."

implies that one should know both in order to know Ruby...

I have no doubt Rails is a good thing at all, but I dont think Rails
should drive the direction of a generic programming language. I want to
see more adoption of Ruby and Rails is driving that, I just dont want
to see Rails dictate what goes into Ruby.

How many rails programmers will expect 'to_json' to be standard Ruby
since its bound to Object? (i guess, I am making the gross assumption
that there are more Rails programmers than Ruby programmers, making the
disction between rails only programmers and those that do rails and
ruby)...

its all just smoke and mirrors in the end isnt it.

-Stu. meh i miss a real newsreader that quotes properly.

 

[Gregory Brown]

In reply to seth;

well your quote


implies that one should know both in order to know Ruby...

No. I think he means if you are doing Rails, you should have a healthy
dose of Ruby with it.
Not necessarily the other way around.