Hi –
On Thu, 23 Mar 2006, Gregory B. 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 ([email protected])
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
On Wed, 2006-03-22 at 21:38, stu wrote:
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)…
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
Avdi G. 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
Hi stu,
On 3/22/06, stu [email protected] 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…
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
That’s of course not to suggest that this post has any value. 
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 Q. 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
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.-
On 3/22/06, Bill K. [email protected] 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
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?
On 3/22/06, Avdi G. [email protected] 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
On 3/23/06, Justin B. [email protected] 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 S.'s “extensions” is a much better approach –
group related code, don’t separate things into individual files
unnecessarily.
-austin
Justin B. 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 B.
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
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
On Mar 23, 2006, at 12:22 PM, James B. 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 W.
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.
Austin Z. 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 S.'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.
[email protected] wrote:
On Mar 23, 2006, at 12:22 PM, James B. 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?
On Mar 23, 2006, at 1:01 PM, James B. wrote:
[email protected] wrote:
On Mar 23, 2006, at 12:22 PM, James B. 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 W.
On Mar 27, 2006, at 4:35 PM, Jim W. 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 W.
Gary W. 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 W.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs