From: Peter Fitzgibbons Date: 2006-03-22T23:53:03+09:00 Subject: Re: Rails vs. Ruby Evolution ------=_Part_2273_7498038.1143039165161 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/22/06, 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-forum.com/. > > 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. -- ------------------------------ Forget the icing. Bake the Cake! - the epi-centered developer ------------------------------ Peter Fitzgibbons ------=_Part_2273_7498038.1143039165161--