Hi you all,
I am reading the “Why’s (poignant) guide to Ruby”. I’ve reached to the
example where he explains how you can change the core “String” class
definition, adding variables and methods (in
http://poignantguide.net/ruby/chapter-5.html). My question is… if I run
this file with the new definitions..., does the core String class of
Ruby remain changed forever? I dunno…is not this feature a little
dangerous?
--
Posted via http://www.ruby-forum.com/.
It remains changed for as long as that particular instance of the ruby
interpreter is run.
"Ruby, you'll shoot your eye out"
It is changed until you unchange it, or the interpreter stops -- not
forever. But yes changing core classes is "dangerous." But so are most
things worth doing or having. To quote another movie:
"with great power comes great responsibility"
Write unit tests and enjoy.
pth
On 7/6/06, Damaris Fuentes <dfl_maradentro@yahoo.es> wrote:
My question is… if I run
this file with the new definitions..., does the core String class of
Ruby remain changed forever? I dunno…is not this feature a little
dangerous?
Hello,
Yeah, it could be dangerous. But it's also incredibly useful at times. For instance, in Rails it's possible to write declarations like
30.minutes.ago
that allow you to express units of time and space as Ruby declarations. However, if you look at Numeric in Ruby, there is no such method 'minutes' or 'ago' defined. Rails adds them, so they can have them defined for all Numeric objects for convenience. To see why this is convenient, imagine how that code would be in the traditional model where you'd extend through inheritance. Rails would have to define a class RailsFixnum that adds those methods and the user would have to code this as
x = RailsFixnum.new(30)
x.minutes.ago
Ugly and more error prone. Ruby code is supposed to be consistent and concise, and the flexibility of modifying base classes helps that sometimes. It's democratic. You can work with main classes to suit them better for your needs. I think it's excellent to modify and extend core classes for your needs, but be sure to test!
Jake
On Jul 6, 2006, at 7:22 PM, Patrick Hurley wrote:
On 7/6/06, Damaris Fuentes <dfl_maradentro@yahoo.es> wrote:
My question is… if I run
this file with the new definitions..., does the core String class of
Ruby remain changed forever? I dunno…is not this feature a little
dangerous?"Ruby, you'll shoot your eye out"
It is changed until you unchange it, or the interpreter stops -- not
forever. But yes changing core classes is "dangerous." But so are most
things worth doing or having. To quote another movie:"with great power comes great responsibility"
Write unit tests and enjoy.
pth
Hi --
My question is if I run
this file with the new definitions..., does the core String class of
Ruby remain changed forever? I dunno is not this feature a little
dangerous?"Ruby, you'll shoot your eye out"
It is changed until you unchange it, or the interpreter stops -- not
forever. But yes changing core classes is "dangerous." But so are most
things worth doing or having. To quote another movie:"with great power comes great responsibility"
I keep hearing that in the context of this question, but I haven't
figured out how it translates into practical advice. I think it's
been used to argue both that one should not re-open core classes, and
that it's OK to do so as long as one is willing to live with
unpredictable runtime failure 
Write unit tests and enjoy.
Testing doesn't address the main problem associated with core changes,
though, namely how they'll affect code that doesn't know about them.
For example, if someone writes code that depends on certain bang
methods returning nil when their receivers don't change, and then
someone "fixes" them so that they return their receivers, something is
likely to break at an unexpected (and unlikely to have been pinpointed
by tests) point.
I tend to think that core changes are surrounded by too much mystique
-- as if they were different from any other code change. If I write a
library and someone uses it, and that person redefines a method so
that it does something different and produces a different return
value, they can't expect the rest of my library to work. The Ruby
core is our communal library, and the same conditions apply.
Of course not every core change is in this category. Pass-through
method overrides, where the original method ends up getting called
anyway, are relatively innocuous, and one could even imagine chaining
them without ill effect. Additive ones (completely new methods) are
*probably* usually safe... until two people add differently-behaving
methods with the same name.
David
On Fri, 7 Jul 2006, Patrick Hurley wrote:
On 7/6/06, Damaris Fuentes <dfl_maradentro@yahoo.es> wrote:
--
"To fully realize the potential of Rails, it's crucial that you take
the time to fully understand Ruby--and with "Ruby for Rails" David
has provided just what you need to help you achieve that goal."
-- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
Complete foreword & sample chapters at http://www.manning.com/black\!
Hi again,
It is changed until you unchange it, or the interpreter stops -- not
forever. But yes changing core classes is "dangerous." But so are most
things worth doing or having. To quote another movie:
I'm quite new to Ruby, so... I open the Irb, I change a core class
and...then... I exit Irb... if I run Irb again...this changes are not
there, right? I'm pretty sure this question is very stupid, but I wanna
be sure I've understood this (I have not worked with interpreters
languages either before..)
--
Posted via http://www.ruby-forum.com/\.
That's right. When you change core classes, you're changing the state of
the Ruby that exists "in memory", so to speak.
;D
On 7/9/06, Damaris Fuentes <dfl_maradentro@yahoo.es> wrote:
I'm quite new to Ruby, so... I open the Irb, I change a core class
and...then... I exit Irb... if I run Irb again...this changes are not
there, right?
--
Daniel Baird
http://tiddlyspot.com (free, effortless TiddlyWiki hosting)
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things
That Suck)
> "with great power comes great responsibility"
I keep hearing that in the context of this question, but I haven't
figured out how it translates into practical advice.
I take it to mean you should think twice before doing it -- especially
where you are actually changing (as opposed to adding/expanding)
functionality. If your change could break libraries or other code you
have written -- it is your responsibility. Put another way, consider
if the notational convience exceeds the cost.
Similarly not all core changes are created equal -- I cannot imaging
(outside of a joke) changing Fixnum#+ to be an alias for Fixnum#- but
there are times when adding a method to Array or more likely
Enumerable makes a lot of sense. You have the power to do either, but
it is your responsibility to write clear maintainable code.
> Write unit tests and enjoy.
Testing doesn't address the main problem associated with core changes,
though, namely how they'll affect code that doesn't know about them.
For example, if someone writes code that depends on certain bang
methods returning nil when their receivers don't change, and then
someone "fixes" them so that they return their receivers, something is
likely to break at an unexpected (and unlikely to have been pinpointed
by tests) point.
But if that is the case, it is still likely the tests will fail (right
after I made the change) and back tracking to the cause is not too
hard. Tests are the safety net -- without them I would be afraid to
change most core classes as I would not know if it might break other
code, gems etc I was using. With tests if something breaks I know
right away and can back track to the cause much easier -- even if I
had not written the test for the exact functionality that changed.
I tend to think that core changes are surrounded by too much mystique
-- as if they were different from any other code change. If I write a
library and someone uses it, and that person redefines a method so
that it does something different and produces a different return
value, they can't expect the rest of my library to work. The Ruby
core is our communal library, and the same conditions apply.
But it is this great features that allow me to test and use patches
against other peoples code without modifying the original source.
I don't think we really disagree, but since my original answer may
have been to glib, I felt compelled to explain myself.
Enjoy yourself, otherwise why bother
pth
On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
On Fri, 7 Jul 2006, Patrick Hurley wrote:
What if I'm running two rails apps on the same (apache) server?
Couldn't changes to core classes made by one of these apps effect the
other one?
Or does each instance of "ruby someAppOrOther.rb" start up a new
interpreter in memory?
thanks,
jp
Daniel Baird wrote:
On 7/9/06, Damaris Fuentes <dfl_maradentro@yahoo.es> wrote:
I'm quite new to Ruby, so... I open the Irb, I change a core class
and...then... I exit Irb... if I run Irb again...this changes are not
there, right?That's right. When you change core classes, you're changing the state
of
the Ruby that exists "in memory", so to speak.;D
--
Posted via http://www.ruby-forum.com/\.
Jeff-
Yeah each ruby foo.rb starts a new interpreter in memory and opening classes will only affect that instance of the interpreter. Your two rails apps won't step on each other.
-Ezra
On Jul 8, 2006, at 8:30 PM, Jeff Pritchard wrote:
What if I'm running two rails apps on the same (apache) server?
Couldn't changes to core classes made by one of these apps effect the
other one?Or does each instance of "ruby someAppOrOther.rb" start up a new
interpreter in memory?thanks,
jp
Ezra might know more than I do on this subject, but I remember hearing that mod_ruby needed a special version of dispatch.rb to avoid rails apps conflicting. All the other deployment methods just work though. In short, make sure to read the docs and you'll be fine.
-Mat
On Jul 9, 2006, at 11:38 PM, Ezra Zygmuntowicz wrote:
On Jul 8, 2006, at 8:30 PM, Jeff Pritchard wrote:
What if I'm running two rails apps on the same (apache) server?
Couldn't changes to core classes made by one of these apps effect the
other one?Or does each instance of "ruby someAppOrOther.rb" start up a new
interpreter in memory?thanks,
jpJeff-
Yeah each ruby foo.rb starts a new interpreter in memory and opening classes will only affect that instance of the interpreter. Your two rails apps won't step on each other.
-Ezra
I know this is lame and has been asked 64 times before.
Currently, what is the best way to have access to serial ports
on a PC using Ruby ?
Regards
Gus S Calabrese
Denver, CO
720 222 1309 303 908 7716 cell
I allow everything with "spamcode2006" in the subject or text to pass my spam filters
Yeah mod_ruby is a different story altogether. I don't knoiw anyone who actually uses it with rails though as it is not a good option for rails apps. IIRC it shares an interprer between apps so you can't run more then one rails app on one apache server with mod_ruby. I seem to remember a patched version that got around this somehow but i am not certain. I would stay away from mod_ruby for your rails apps completely. But mod_ruby is great if you just want to serve .rhtml or .rb files for simple little apps.
-Ezra
On Jul 10, 2006, at 5:30 AM, Mat Schaffer wrote:
On Jul 9, 2006, at 11:38 PM, Ezra Zygmuntowicz wrote:
On Jul 8, 2006, at 8:30 PM, Jeff Pritchard wrote:
What if I'm running two rails apps on the same (apache) server?
Couldn't changes to core classes made by one of these apps effect the
other one?Or does each instance of "ruby someAppOrOther.rb" start up a new
interpreter in memory?thanks,
jpJeff-
Yeah each ruby foo.rb starts a new interpreter in memory and opening classes will only affect that instance of the interpreter. Your two rails apps won't step on each other.
-Ezra
Ezra might know more than I do on this subject, but I remember hearing that mod_ruby needed a special version of dispatch.rb to avoid rails apps conflicting. All the other deployment methods just work though. In short, make sure to read the docs and you'll be fine.
-Mat
This was the previous answer to your question.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35355
You might also look at the ruby-serialport project on rubyforge.
http://rubyforge.org/projects/ruby-serialport/
This should be installable as a gem, but I have never used it, nor do
I know if it works on Windows.
By the way, have you ever attended the Boulder/Denver Ruby User Group?
We meet once a month in Superior just up US36 from Denver. Good
times are had by all, and I always leave with a little more ruby foo
under my belt.
http://rubyforge.org/news/?group_id=1241
That link gives the meeting times and locations. The next meeting is
Wednesday, July 19 at 6:00 PM.
Blessings,
Tim Pease
On 7/10/06, Gus S Calabrese <gsc@omegadogs.com> wrote:
I know this is lame and has been asked 64 times before.
Currently, what is the best way to have access to serial ports
on a PC using Ruby ?Regards
Gus S Calabrese
Denver, CO
720 222 1309 303 908 7716 cell
I allow everything with "spamcode2006" in the subject or text to
pass my spam filters
Gus S Calabrese wrote:
I know this is lame and has been asked 64 times before.
Currently, what is the best way to have access to serial ports
on a PC using Ruby ?
Windows? Do you need CTS/RTS, DSR/DTR ?
Regards,
JJ
I know this is lame and has been asked 64 times before.
Currently, what is the best way to have access to serial ports
on a PC using Ruby ?
You don't mention the platform, but on Linux I just open /dev/tts/X and
read and write to it like a file. As long as you have it set up before
hand using the stty command, it works just fine.
Caleb
Windows is fine and I do not need CTS RTS DSR DTR
AGSC
Gus S Calabrese wrote:
I know this is lame and has been asked 64 times before.
Currently, what is the best way to have access to serial ports
on a PC using Ruby ?
Windows? Do you need CTS/RTS, DSR/DTR ?
Regards,
JJ
Gus S Calabrese
Denver, CO
720 222 1309 303 908 7716 cell
I allow everything with "spamcode2006" in the subject or text to pass my spam filters
On 2006-Jul 11, at 15:28hrs PM, John Johnson wrote: