Forum: Ruby Rails vs. Ruby Evolution

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-22 06:30
(Received via mailing list)
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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-03-22 06:59
(Received via mailing list)
From: <gwtmp01@mac.com>
> 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
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-03-22 07:01
(Received via mailing list)
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-22 07:22
(Received via mailing list)
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
1c32688ea30399fc36eb61605f543aaf?d=identicon&s=25 Seth Rasmussen (Guest)
on 2006-03-22 07:51
(Received via mailing list)
On 3/21/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>         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."
2a0f7bd2c54fbc44329d69555b96f1c5?d=identicon&s=25 Kev Jackson (Guest)
on 2006-03-22 08:15
(Received via mailing list)
Seth Rasmussen wrote:

>>        Array#in_groups_of
>>
>>
>
>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
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2006-03-22 14:49
(Received via mailing list)
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/articles/
> > 2006/02/28/rails-1.1, which gives an overview of the next Rails release.

> > 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 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.
41231db9f0620d2dea414da4465821af?d=identicon&s=25 Guest (Guest)
on 2006-03-22 15:37
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.
Fea3202718832fe11a0db6bb44a5cc37?d=identicon&s=25 Avdi Grimm (Guest)
on 2006-03-22 15:46
(Received via mailing list)
On 3/22/06, Bill Kelly <billk@cts.com> wrote:
> 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
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-03-22 15:53
(Received via mailing list)
On 3/22/06, hunt@mets.ee <hunt@mets.ee> wrote:
> > 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
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.



--
B6e200953f671dd7d33380b8e507b796?d=identicon&s=25 Eric Kidd (Guest)
on 2006-03-22 16:15
(Received via mailing list)
On Mar 22, 2006, at 12:29 AM, gwtmp01@mac.com wrote:
> 	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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-22 16:34
(Received via mailing list)
On Mar 22, 2006, at 10:15 AM, Eric Kidd wrote:
> 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
A75904fde646d1b9111eb32ea8f40ef3?d=identicon&s=25 stu (Guest)
on 2006-03-22 16:36
(Received via mailing list)
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
D8831c4665a164c6ce484003deb1afd6?d=identicon&s=25 Guillaume Marcais (Guest)
on 2006-03-22 16:46
(Received via mailing list)
Le 22 mars 06, à 10:34, stu a écrit :

> 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
a cleaner way?

Guillaume.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-03-22 16:52
(Received via mailing list)
On 3/22/06, Seth Rasmussen <seths.mailing.lists@gmail.com> wrote:
> On 3/21/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 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
A77873df3a9766b208e009248a2a9a56?d=identicon&s=25 Hampton (Guest)
on 2006-03-22 16:53
(Received via mailing list)
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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-22 17:09
(Received via mailing list)
> 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.
1c32688ea30399fc36eb61605f543aaf?d=identicon&s=25 Seth Rasmussen (Guest)
on 2006-03-22 20:11
(Received via mailing list)
On 3/22/06, stu <yakumo9275@gmail.com> wrote:
> 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?
A75904fde646d1b9111eb32ea8f40ef3?d=identicon&s=25 stu (Guest)
on 2006-03-22 21:38
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-03-22 21:55
(Received via mailing list)
On 3/22/06, stu <yakumo9275@gmail.com> wrote:
> 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...

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.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-22 22:06
(Received via mailing list)
Hi --

On Thu, 23 Mar 2006, Gregory Brown wrote:

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

You mean... you should have Ruby for Rails? :-)


David

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black
1c32688ea30399fc36eb61605f543aaf?d=identicon&s=25 Seth Rasmussen (Guest)
on 2006-03-22 22:32
(Received via mailing list)
Hi stu,

On 3/22/06, stu <yakumo9275@gmail.com> wrote:
> 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...

No, it doesn't.

It implies that if one is worried about confusing Ruby for Rails or
vice versa, that simply knowing which is which will avoid that.

> 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 know not every piece of opinion begs comment, but it seems
interesting that you seem to be responding to things which have not
been stated or implied. This all started by somebody simply saying,
basically, "Hey Rails has a bunch of nice core extensions... maybe
some of them should be in the Ruby core?" That says nothing about
Rails driving anything but its own success and some other people
going, "hey, that's not too shabby."

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

It's going to be okay... it's going to be okay...

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

I dunno, who cares? Are you like those fools? No? Great. The world spins
on..
Ded98dc06a045924f0d48b2e46fdf229?d=identicon&s=25 Henrik Martensson (Guest)
on 2006-03-23 10:21
(Received via mailing list)
On Wed, 2006-03-22 at 21:38, stu wrote:
<snip>
>
> 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)...
<snip>

There will be a few. These mistakes will be made by the same kind of
people who believe ASP is a programming language, confuse Perl with CGI,
believe that compiled languages are inherently superior to interpreted
languages (or vice versa), and that writing a document in Word is
"programming the computer".

Still, I would not worry too much. The benefits of being able to extend
Ruby code without modifying it, the way the Rails developers do, far
outweighs the drawbacks. What you will see in the future are a few
really strange questions in the mailing lists, but beyond that I believe
you don't have to worry.

When Ruby becomes a blip on the radar of major IT companies, _then_ you
will have cause to worry. Enterprise Ruby Beans...


/Henrik

--
http://kallokain.blogspot.com/ - Blogging from the trenches of software
development
http://www.henrikmartensson.org/  - Reflections on software development
http://tocsim.rubyforge.com/ - Process simulation
http://testunitxml.rubyforge.org/  - XML test framework
http://declan.rubyforge.org/ - Declarative XML processing
32edd0717b3144d5c58a352d613abdc9?d=identicon&s=25 gabriele renzi (Guest)
on 2006-03-23 10:49
(Received via mailing list)
Avdi Grimm ha scritto:
> 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.

+1
2a0f7bd2c54fbc44329d69555b96f1c5?d=identicon&s=25 Kev Jackson (Guest)
on 2006-03-23 11:15
(Received via mailing list)
>When Ruby becomes a blip on the radar of major IT companies, _then_ you
>will have cause to worry. Enterprise Ruby Beans...
>
>
Ack the very thought!  Indeed part of the fun I'm having learning ruby
is that the there are many many more informed posts on this list
compared to the average sludge on google groups for anything Java (and
especailly Hibernate) related.  I often learn totally new things just by
browsing this lsit - that couldn't be said for java groups/mailing
lists...

Compare the number of posts to the rails list that start of with "[Hi
I'm new, what IDE/debugger tool do I use for Rails? | I'm coming from
PHP, I can do this ${thing} in PHP how do I do it in Rails? | Hi  I'm
(java|.net|vb|php) programmer, how do I get Rails to talk to my
(Microsoft|IBM|Bea) server?] style posts with the posts here.  I know
that partly this is to do with the popularity of Rails as a framework
advertised/marketed to php/java programmers to replace their existing
frameworks, but I also think that this is simply a factor of popularity
- ie the more popular the list the more posts it attracts, regardless of
the value of the post for other people.

That's of course not to suggest that this post has any value. :p

I think my point is that, right now, ruby is in quite a nice place,
where there are many bright people invloved on the lists and there is
real value lurking and studying the code (Ruby Quiz is one of the finest
examples).  In the future this may not be the case, as more 'enterprise
architects' and 'paper MCSE's' start to appear on the list and the truly
insightful posts get drowned out by the ocean of mediocrity.  Or
something like that.

So I'm happy that ruby is (currently) a niche language, at least we
don't have people suggesting a 'standards committee' or 'certified
exams' etc (yet)

Kev
Cfdeff3ac35010e4de8f85d954f24f4a?d=identicon&s=25 Damphyr (Guest)
on 2006-03-23 11:58
(Received via mailing list)
stu wrote:
> 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...
>
No, it implies that if one uses Rails, he/she should know Ruby.
You are worrying about people who come from Rails having a familiarity
with things not 'of the core'.
Well, I say let them have problems. It doesn't take more than a few
hours to sort through the differences and it's probably the best way to
solidify a good knowledge of Ruby which in turn will make for better
understanding of Rails.

> 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.
Me neither. Just like a previous post stated (I'm to lazy to quote
properly), Rails is domain specific, Ruby isn't.
I make my living coding Ruby and I have only read about Rails out of
personal interest. The thing is, the guys writing Rails know quite a bit
of Ruby and use the language in a very efficient way.
Ergo, I can learn (and have learned) quite a bit from Rails and the
solutions based on Rails.
Now if some of these solutions transcend the domain of Rails I would be
very happy to see them in core.
Until then, they remain in Rails and it's adjacent libraries, nice
little gems available to everyone. You only have to *know* Ruby to use
them properly.
>
> 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)...
Well, I expect a "Rails programmer" to very quickly become a "Ruby
programmer", which is what one should be from the start. It isn't all
that difficult (part of the charm of the language) and it really
shouldn't be otherwise.

Cheers,
V.-

--
http://www.braveworld.net/riva
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-03-23 17:05
(Received via mailing list)
On 3/22/06, Bill Kelly <billk@cts.com> wrote:
> 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.  :)

...I just wish that facets didn't try to muck with some of the things
that it mucks with unnecessarily.

The number one reason I will not use Nitro is facets.

-austin
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-03-23 17:10
(Received via mailing list)
On 3/22/06, Avdi Grimm <avdi.grimm@gmail.com> wrote:
> 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.

I would prefer that they didn't. The primary maintainer of Facets has
some odd notions on what should and should not be in Ruby, the language
that I think makes Facets nigh-unusable.

I would prefer to see something that does what Facets does, but does it
smarter and without trying to change the way that Ruby itself works.
This is unlikely to happen under the current maintainer of Facets.

-austin
573b9499030e1ccb867ef80f0ff1ac49?d=identicon&s=25 Justin Bailey (Guest)
on 2006-03-23 17:21
(Received via mailing list)
Care to elaborate? Not asking for a flame war or anything. I've used
Rails
quite a bit and wanted to give Nitro a try on a toy project to see how I
like it, but I've also tried to use Facets before and found it to not be
well-documented, which irritated me. What is it about Facets you are
concerned with?
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-03-23 17:34
(Received via mailing list)
On 3/23/06, Justin Bailey <jgbailey@gmail.com> wrote:
> Care to elaborate? Not asking for a flame war or anything. I've used
> Rails quite a bit and wanted to give Nitro a try on a toy project to
> see how I like it, but I've also tried to use Facets before and found
> it to not be well-documented, which irritated me. What is it about
> Facets you are concerned with?

The documentation problem is part of it. There have been attribution
problems in the past, but I think that those are mostly fixed, and the
licensing issue is still not 100% clear (the copyright and licence
granted are for the *collection* facets; individual facet
implementations may be under different licences). Mostly, I have issues
with the changes that facets makes -- or has made in the past --
#require and some of the schemes that the primary maintainer has come up
with. They're both ugly and unworkable.

I think that Gavin Sinclair's "extensions" is a much better approach --
group related code, don't separate things into individual files
unnecessarily.

-austin
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-03-23 18:22
(Received via mailing list)
Justin Bailey wrote:
> Care to elaborate? Not asking for a flame war or anything. I've used Rails
> quite a bit and wanted to give Nitro a try on a toy project to see how I
> like it, but I've also tried to use Facets before and found it to not be
> well-documented, which irritated me.

The lack of documentation is the bane of many projects.  There are
efforts underway to improve this in Nitro and related libraries.

I've used Nitro for a number of projects, and not had any issues that
weren't simply from bugs (that have since been fixed) or my own misuse
due to lack of docs.

That a given library makes deep changes to core objects or behavior
should not be an issue if the nature and reasoning for those changes are
made clear.

I expect that when people build, say, a Rails application, that they are
fully aware that the framework adds or munges certain aspects of Ruby,
and that some of the things they are able to (or not) do differs from
general Ruby programming.

As for certain features finding their way into the core language,
general discussion of RCRs may be indicative.  It seems that if some
feature is easily added though conventional means (a mixin, for example)
then there is little enthusiasm for bundling it into the language.

For example, the to_json method is quite nice in certain cases, and has
been available via a ruby-json gem for over a year now.    There's no
compelling reason to make a part of Ruby itself, though.  It's too easy
for developers to just add it when they want to.


--
James Britt

http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.30secondrule.com   - Building Better Tools
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-23 18:32
(Received via mailing list)
On Mar 23, 2006, at 12:22 PM, James Britt wrote:
> That a given library makes deep changes to core objects or behavior
> should not be an issue if the nature and reasoning for those
> changes are made clear.

Until you need/want to use two such libraries.

Gary Wright
D8598ce8f08e821c8496b8e81645319a?d=identicon&s=25 Kashia Buch (Guest)
on 2006-03-23 18:52
(Received via mailing list)
Hi,

> Care to elaborate? Not asking for a flame war or anything. I've used
> Rails
> quite a bit and wanted to give Nitro a try on a toy project to see how I
> like it, but I've also tried to use Facets before and found it to not be
> well-documented, which irritated me. What is it about Facets you are
> concerned with?

The part of, "being not well-documented" applies to Nitro as well,
sadly.

For Facets screwing around with core functions: Why should I care? If it
doesn't interfer with anything I do, so I really could care less what it
exactly does.

As for Nitro, for me it is the best web framework I ever used, despite
all it's shortcomings.

If you want to learn some stuff, first thing you should look at, are the
small examples by George himself.

Give Nitro a try, if you're not afraid of looking at code from Nitro
itself, otherwise stay away right now :)
Or use the paths that George flattened himself, they're _very_ smooth ;D

Kashia
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-03-23 19:01
(Received via mailing list)
gwtmp01@mac.com wrote:
>
> On Mar 23, 2006, at 12:22 PM, James Britt wrote:
>
>> That a given library makes deep changes to core objects or behavior
>> should not be an issue if the nature and reasoning for those  changes
>> are made clear.
>
>
> Until you need/want to use two such libraries.

Can you give an example?
A77873df3a9766b208e009248a2a9a56?d=identicon&s=25 Hampton (Guest)
on 2006-03-24 17:04
(Received via mailing list)
Kev-

Don't get me started on the Rails usenet group. Its a wasteland.

Every time I browse there I consider it Outreach work.

It makes me shudder to realize that only about 1% of Rails programmers
actually understand programming. That is, I can code in pure Ruby one
hour, then switch over and use the same patterns and style in a website
application. Its absolutely wonderful in that way.

But, alas, 90% of the user base is completely ignorant of actual
effective programming.

It makes me understand why DHH hangs out here in comp.lang.ruby and not
the rails group. It would depress me if my baby was being abused so.

-hampton.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-25 03:38
(Received via mailing list)
Austin Ziegler wrote:
> granted are for the *collection* facets; individual facet
> implementations may be under different licences). Mostly, I have issues
> with the changes that facets makes -- or has made in the past --
> #require and some of the schemes that the primary maintainer has come up
> with. They're both ugly and unworkable.
>
> I think that Gavin Sinclair's "extensions" is a much better approach --
> group related code, don't separate things into individual files
> unnecessarily.

Well, documentation of Facets, I think, is actually fairly good
compared to many projects. Understand that there are over 400 methods
and over 60 modules in there, so it's a lot to keep on top of. The fact
that the vast majority of this work does have documentation --a
explanation and an example or two, I'd say, is pretty good. Some of the
main docs have gotten out of sync with developement but that's b/c the
last fve months or so were a difficult time of working out an cleaner
organization for the two library sections. I've been trying to have a
single lib for both extensions and additions, but it hasn't been easy
and twice I've all but given up and gone back to two separate projects.
But as of yesterday actually, that has been resloved.

As for mucking with the underlying Ruby. You couldn't be more wrong.
Only a dozen or so  methods do any mucking about and these are listed
in an "noauto" file so as not to be included in any multi-facet
require. You can use them if you know what you are doing, but you have
to ask for them specifically. And that's really the thing about Facets.
Since it is utilized by selecting the specific methods you want to use
and no more, actual efffects are minimized, which is the benefit of
it's atomicity. This is unlike ActiveSupport where everything is
preloaded.

> problems with the changes that facets makes -- or has made in the past --
> #require and some of the schemes that the primary maintainer has come up
> with. They're both ugly and unworkable.

As for this, you are refering to a one time attemp of mine to use a
special method for loading the methods. Eg. 'String.use Facets,
:blank?' This method has advantages, but it wasn't popular simply
because it's not a common idiom for loading extenal code. I understand
that and so I got rid of it.

T.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-27 23:21
(Received via mailing list)
On Mar 23, 2006, at 1:01 PM, James Britt wrote:

> gwtmp01@mac.com wrote:
>> On Mar 23, 2006, at 12:22 PM, James Britt wrote:
>>> That a given library makes deep changes to core objects or
>>> behavior  should not be an issue if the nature and reasoning for
>>> those  changes are made clear.
>> Until you need/want to use two such libraries.
>
> Can you give an example?

If you are asking for a specific example of a method redefinition
from two
current and popular frameworks that are mutually incompatible, no.

But here is a examples that make me wonder:
Rails redefines Module#const_missing to auto load Rails controllers.

It seems to me that playing around with const_missing by more than one
library would be problematic.  I'm not saying that it can't be done but
that all implementations would have to respect some set of conventions.

Rails defines Hash#to_options (a alias for Hash#symbolize_keys).  It
just
so happens that in framework I'm working on I defined a method
Array#to_options to help parse a variable argument list.  Not a
direct clash
but pretty close.

Rails redefines the backtick method (Kernel#`) to hide the Errno::ENOENT
exception.  The comment indicates that only Win32 systems raise the
exception
but the redefinition will catch and suppress that exception.

I'm not trying to say that frameworks should never redefine or extend
core
classes.   I was just trying to see if other people were thinking
about this
and what conventions and/or language features might assist in avoiding
mutually incompatible changes/extensions to the core libraries.


Gary Wright
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-03-27 23:35
Gary Wright wrote:
> But here is a examples that make me wonder:
> Rails redefines Module#const_missing to auto load Rails controllers.
>
> It seems to me that playing around with const_missing by more than one
> library would be problematic.  I'm not saying that it can't be done but
> that all implementations would have to respect some set of conventions.

An actual conflict with const_missing has already occurred.  I added a
const_missing handler to Rake when I cleaned up the global namespace and
moved some constants into the Rake namespace.  But I wanted people using
constants in the top level namespace to get a deprectated message with
instructions regarding what they had to change to work with the new Rake
command.

I carefully wrote the handler to complain only about the handful of
constants I moved, anything else would be forwarded to the previous
const_missing handler.

Well, that worked great until the new rake was used in a Rails project.
At the time, rails didn't forward chain const_missing requests, so
things got kinda messed up.  IIRC, Jamis was one the problem as soon as
I mentioned something (or maybe he told me ... I don't remember), and a
fix was commited almost immediately.

Today, both Rake and Rails use a const_missing handler without
interfering with each other.

The moral of the story is: You need to be careful in creating libraries
that touch the "public" portions of Ruby.  I've been meaning to write
down a few guidelines that I tend to follow, but haven't had time yet.
I think the time is ripe for someone to codify a "How to play together
nicely in Ruby" set of guidelines.

--
-- Jim Weirich
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-28 01:11
(Received via mailing list)
On Mar 27, 2006, at 4:35 PM, Jim Weirich wrote:
> Well, that worked great until the new rake was used in a Rails
> project.

Interesting.  When writing my post I grepped through some gems
for 'const_missing' and saw the hit in the Rake gem.  I almost included
that as an example but didn't bother to look any deeper.

Gary Wright
This topic is locked and can not be replied to.