I was recently reading a presentation on “10 things Java programmers
should know about Ruby.” Like many similar discourses, it talked about
classes being objects and singleton methods etc. etc. Now, I am familiar
with these different things, but I think I am too stupid to discern
their inherent worth.
Open classes. The other day, in a little Blackjack game I wrote in
Ruby, I used this feature to add in a method to the Array class instead
of making a class that inherited from Array and added that method.
However, a) I’m not sure if that was the “right” way and b) I’m not sure
if there is an advantage to that approach over the latter, per se.
Singleton methods. I really can’t think of a particular example where
I would use this… please help!
Blocks. Although now (after some practice and getting used to) these
make sense to me when I use them with methods already designed, I don’t
think I have internalized them to the point where I would write my own
methods that accepted them and worked with them. Has anyone else been in
the same boat, or do they usually just “click”?
Open classes. The other day, in a little Blackjack game I wrote in
Ruby, I used this feature to add in a method to the Array class
instead
of making a class that inherited from Array and added that method.
However, a) I’m not sure if that was the “right” way and b) I’m not
sure
if there is an advantage to that approach over the latter, per se.
Open classes are best used sparingly. There are problems with them,
of course, in that your code might collide with someone else’s code.
The plus though is that all instances of the changed class are
suddenly empowered with new methods you can count on. Some good uses,
in my opinion, are:
Conversion methods – I would rather type %w[a b c].to_csv than
CSV.generate_line(%w[a b c]. I don’t feel there’s much danger of
namespace collision here either due to the specific types in the
method names. Some disagree and feel this is polluting the namespace
though.
DSL – It can often be convenient to make Ruby understand the
language of your problem rather than to express your problem in Ruby.
Singleton methods. I really can’t think of a particular example
where
I would use this… please help!
Well, technically you use this feature in Ruby anytime you create a
class method. Outside of that, it’s another feature best used in
moderation. It does have interesting possibilities though. Here’s an
example to try and get you thinking in new directions:
Blocks. Although now (after some practice and getting used to)
these
make sense to me when I use them with methods already designed, I
don’t
think I have internalized them to the point where I would write my own
methods that accepted them and worked with them. Has anyone else
been in
the same boat, or do they usually just “click”?
I wrote about this on my blog a while back. Maybe it will help:
if there is an advantage to that approach over the latter, per se.
Thank you and sorry for the noobness,
It seems like you want to read the book “Design Patterns in Ruby”. It
goes into great detail when to use what, and why, and such stuff.
of making a class that inherited from Array and added that method.
However, a) I’m not sure if that was the “right” way and b) I’m not
sure
if there is an advantage to that approach over the latter, per se.
That was the correct way to do it! The advantage is you can
instantiate an array object like normal ([]), instead of having to do
MyArray.new(3, 4, 5)
Singleton methods. I really can’t think of a particular example
where
I would use this… please help!
When you would need to add a method into a class, or create a
subclass with a special method BUT the method is only used by one
object (IE, only one instantiation of MyArray).
Also, you should use it when you want methods to be called within a
class but outside of a method definition.
Blocks. Although now (after some practice and getting used to)
these
make sense to me when I use them with methods already designed, I
don’t
think I have internalized them to the point where I would write my own
methods that accepted them and worked with them. Has anyone else
been in
the same boat, or do they usually just “click”?
Open classes are best used sparingly. There are problems with them,
of course, in that your code might collide with someone else’s code.
The plus though is that all instances of the changed class are
suddenly empowered with new methods you can count on. Some good uses,
in my opinion, are:
Conversion methods
DSL
I think that rather than sparingly, the adverb should be carefully.
Open classes are very powerful in situations like building a
framework, (e.g. Rails). Features such as plugins, use formalized
patterns of extending open classes to allow opening classes while
minimizing the potential for collisions.
class << array; self; end.send(:define_method, :counts) do
?> counts
end
end
Right, another is to accomplish what the OP did by adding an instance
to Array in a safer more controlled fashion. Rather than “duck
punching” all now and future instance of Array we can specialize
particular instances.
if there is an advantage to that approach over the latter, per se.
I think that rather than sparingly, the adverb should be carefully.
Open classes are very powerful in situations like building a
framework, (e.g. Rails). Features such as plugins, use formalized
patterns of extending open classes to allow opening classes while
minimizing the potential for collisions.
In an example in Practical Ruby Projects, the author has to load some
some operating specific code. He feels that open classes are great
for that. He codes up the general interface of the class and then
insert the other methods tailored to the operating system later.
This does seem to come out smoother than having to deal with a bunch
of specific subclasses. The unneeded code is just not added in.
In an example in Practical Ruby Projects, the author has to load some
some operating specific code. He feels that open classes are great
for that. He codes up the general interface of the class and then
insert the other methods tailored to the operating system later.
This does seem to come out smoother than having to deal with a bunch
of specific subclasses. The unneeded code is just not added in.
There is almost no Ruby quiz solution I have ever submitted that does
not do that, it feels somehow like, look Ruby I know better than you
do though
My personal rule of thumb is, that when something “appears” logical and
straightforward, I use it.
And if i have had bad experience with it in the past, I dont use that
feature.
In the end I use only a subset of Ruby (but it makes me happy because it
is a lot more elegant than any other language I know of).
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
