[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Rails vs. Ruby Evolution

Gary Wright

3/22/2006 5:30:00 AM

I was just reading through http://scottraymond.net...
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
38 Answers

Bill Kelly

3/22/2006 6:00:00 AM

0

From: <gwtmp01@mac.com>
>
> 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.ni... )
which seems to be working in close collaboration with the facets
( http://facets.ruby... ) 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

3/22/2006 6:02:00 AM

0

On 3/22/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
> 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

Gary Wright

3/22/2006 6:22:00 AM

0


On Mar 22, 2006, at 1:01 AM, Ryan Leavengood wrote:
> 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

3/22/2006 6:52:00 AM

0

On 3/21/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> I was just reading through http://scottraymond.net...
> 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."

--
Seth Thomas Rasmussen
http://sethrasm...

Kev Jackson

3/22/2006 7:16:00 AM

0

Seth Rasmussen wrote:

>On 3/21/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
>
>>I was just reading through http://scottraymond.net...
>>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.
>
>
>
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

3/22/2006 1:50:00 PM

0

On 3/21/06, Seth Rasmussen <seths.mailing.lists@gmail.com> wrote:
> On 3/21/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> > I was just reading through http://scottraymond.net...
> > 2006/02/28/rails-1.1, which gives an overview of the next Rails release

hunt

3/22/2006 2:38:00 PM

0

pat eyler wrote:
>
> 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.

--
Posted via http://www.ruby-....

Avdi Grimm

3/22/2006 2:46:00 PM

0

On 3/22/06, Bill Kelly <billk@cts.com> wrote:
> I like the approach taken by Nitro ( http://www.ni... )
> which seems to be working in close collaboration with the facets
> ( http://facets.ruby... ) 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

3/22/2006 2:53:00 PM

0

On 3/22/06, hunt@mets.ee <hunt@mets.ee> wrote:
>
> pat eyler wrote:
> >
> > 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.
>
> --
> Posted via http://www.ruby-....
>
>
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 those
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.



--
------------------------------
Forget the icing. Bake the Cake!
- the epi-centered developer
------------------------------
Peter Fitzgibbons

Eric Kidd

3/22/2006 3:15:00 PM

0

On Mar 22, 2006, at 12:29 AM, gwtmp01@mac.com wrote:
> I was just reading through http://scottraymond.net...
> 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