As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm coming from a static typed language background (C#/Java), and while I have developed apps using Rails, I'm still not fully confident when in comes to class design.
Are there any 'gotchas' when it comes to inheritance in Ruby?
Maybe things to do with static variables, constructors (initializers), the meta/singleton class (I think the official name is something like eugene class)?
I have read a ruby book and I'm looking for those with real world experience to point out things that might not be so obvious in practise.
The biggest gotcha I encountered is that "class variables" (variables whose names start with ##) don't behave the way you would expect. The variable is actually shared among the class and all the subclasses, so you can't change its value in the subclasses without affecting the parent class. Here's an example:
class Foo
##x = 1
def self.x
##x
end
end
class Goo < Foo
##x = 2
end
puts Foo.x # => 2
puts Goo.x # => 2
Instead of using class variables, you might want to use instance variables of the class object, but then you don't automatically get inheritance so you have to define all those variables each time you define a new subclass:
class Moo
#y = 1
def self.y
#y
end
end
class Noo < Moo
#y = 2
end
puts Moo.y # => 1
puts Noo.y # => 2
Alternatively, just make a class method (e.g. self.x) that returns the desired value. Then you get inheritance and the ability to override it in subclasses.
One thing I've discovered as I'm using Ruby more and more is to avoid using inheritance unless it really is necessary and logical to do so. So much more can be accomplished in Ruby by using modules and including them in your class than in C#/Java.
Doing so will make your design more flexible and easier to use in any unforeseen scenarios where a consumer of the design doesn't want to "use up" their parent class just to satisfy your library/API. Additionally, this helps me follow the "favor composition over inheritance" wisdom in a new way I couldn't in C#/Java.
Not sure if this qualifies as a 'gotchya' or simply something new to consider compared to those other languages.
Related
Although I agree that extending native types and objects is a bad practice, inheriting from them should not be.
In a supposedly supporting gem (that I could not find), the way that the native types were to be used would be as follows:
require 'cool-unkown-light-gem'
class MyTypedArray < CoolArray # would love to directly < Array
def initialize(*args)
super(*args)
# some inits for DataArray
#caches_init = false
end
def name?(name)
init_caches unless !#caches_init
!!#cache_by_name[name]
end
def element(name)
init_caches unless !#caches_init
#cache_by_name[name]
end
private
# overrides the CoolArray method:
# CoolArray methods that modify self will call this method
def on_change
#caches_init = false
super
end
def init_caches
return #cache_by_name if #caches_init
#caches_init = true
#cache_by_name = self.map do |elem|
[elem.unique_name, elem]
end.to_h
end
end
Any method of the parent class not overridden by the child class that modifies self would call, let's say (in this case), the on_change function. Which would allow to do not have to re-define every single one of those methods to avoid losing track on changes.
Let's say the MyTypedArray would array Foo objects:
class Foo
attr_reader :unique_name
def initialize(name)
#unique_name = name
end
end
a short example of the expected behaviour of its usage:
my_array = MyTypedArray.new
my_array.push( Foo.new("bar") ).push( Foo.new("baz") )
my_array.element("bar").unique_name
# => "bar"
my_array.shift # a method that removes the first element from self
my_array.element("bar").unique_name
# => undefined method `unique_name' for nil:NilClass (NoMethodError)
my_array.name?("bar")
# => false
I understand that we should search for immutable classes, yet those native types support changes on the same object and we want a proper way to do an inheritance that is as brief and easy as possible.
Any thoughts, approaches, or recommendations are more than welcome, of course. I do not think I am the only one that have thought on this.
The reason why I am searching for a maintained gem is because different ruby versions may offer different supported methods or options for native types / classes.
[Edit]
The aim of the above is to figure out a pattern that works. I could just follow the rules and suggestions of other posts, yet would not get things work the way I am intended and when I see it proper (a coding language is made by and for humans, and not humans made for coding languages). I know everyone is proud of their achievements in learning, developing and making things shaped in a pattern that is well known in the community.
The target of the above is because all the methods of Array are more than welcome. I do not care if in the version 20 of Ruby they remove some methods of Array. By then my application will be obsolete or someone will achieve the same result in far less code.
Why Array?
Because the order matters.
Why an internal Hash?
Because for the usage I want to make of it, in overall, the cost of building the hash compensates the optimization it offers.
Why not just include Enumerable?
Because we just reduce the number of methods that change the object, but we do not actually have a pattern that allows to change #caches_init to false, so the Hash is rebuilt on next usage (so same problem as with Array)
Why not just whitelist and include target Array methods?
Because that does not get me where I want to be. What if I want anyone to still use pop, or shift but I do not want to redefine them, or even having to bother to manage my mixins and constantly having to use responds_to?? (perhaps that exercise is good to improve your skills in coding and read code from other people, but that is not what it should be)
Where I want to be?
I want to be in a position that I can re-use / inherit any, I repeat, any class (no matter if it is native or not). That is basic for an OOP language. And if we are not talking about an OOP language (but just some sugar at the top of it to make it appear as OOP), then let's keep ourselves open to analyse patterns that should work well (no matter if they are odd - for me is more odd that there are no intermediate levels; which is symptom of many conventional patterns, which in turn is symptom of poor support for certain features that are more widely required than what is accepted).
Why should a gem offer the above?
Well, let's humble it. The above is a very simple case (and even though not covered). You may gain in flexibility at some point by using what some people want to call the Ruby way. But at a cost when you move to bigger architectures. What if I want to create intermediate classes to inherit from? Enriched native classes that boost simple code, yet keeping it aligned with the language. It is easier to say this is not the Ruby way than trying to make the language closer to something that escalates well from the bottom.
I am not surprised that Rails and Ruby are almost "indistinctly" used by many. Because at some point, without some Rails support, what you have with Ruby is a lot of trouble. As, consequently, I am not surprised that Rails is so maintained.
Why should I redefine a pop, or a last, or first methods? For what? They are already implemented.
Why should I whitelist methods and create mixins? is that a object or method oriented programming?
Anyway... I do not expect anyone to share my view on this. I do see other patterns, and I will keep allowing my mind to find them. If anyone is open enough, please, feel free to share. Someone may criticize the approach and be right, but if you got there is because it worked.
To answer your question as it is written, no, there is no gem for this. This is not a possibility of the language, either in pure Ruby or in C which is used internally.
There is no mechanism in detect when self is changed, nor any way to detect if a method is pure (does not change self) or impure (does change self). It seems you want a way to "automatically" be able to know when a method is one or the other, and that, to put simply, is just not possible, nor is it in any language that I am aware of.
Internally (using your example) an Array is backed by a RArray structure in C. A struct is simple storage space: a way to look at an arbitrary block of memory. C does not care how you choose to look at memory, I could just as easily cast the pointer of this struct and say it is a now a pointer to an array of integers and change it that way, it will happily manipulate the memory as I tell it to, and there is nothing that can detect that I did so. Now add in the fact that anyone, any script, or any gem can do this and you have no control over it, and it just shows that this solution is fundamentally and objectively flawed.
This is why most (all?) languages that need to be notified when an object is changed use an observer pattern. You create a function that "notifies" when something changes, and you invoke that function manually when needed. If someone decides to subclass your class, they need only continue the pattern to raise that function if it changes the object state.
There is no such thing as an automatic way of doing this. As already explained, this is an "opt-in" or "whitelist" solution. If you want to subclass an existing object instead of using your own from scratch, then you need to modify its behavior accordingly.
That said, adding the functionality is not as daunting as you may think if you use some clever aliasing and meta-programming with module_eval, class_eval or the like.
# This is 100% untested and not even checked for syntax, just rough idea
def on_changed
# Do whatever you need here when object is changed
end
# Unpure methods like []=, <<, push, map!, etc, etc
unpure_methods.each do |name|
class_eval <<-EOS
alias #{name}_orig #{name}
def #{name}(*args, &block)
#{name}_orig(*args, &block)
on_changed
end
EOS
end
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In Java, every instruction executed is defined inside a method. In Ruby, you can do something like this:
class A
puts "Inside of A class" # [1]
end
and [1] will be executed when A is loaded. An example of this is the following code in Rails:
class Product < ActiveRecord::Base
validates :title, :presence => true, length: 1..19, :uniqueness => true
end
What sense does it have to write code outside of a method? How can it be used (how can it be invoked)?
I assume you want to know why you'd place code to execute "inside a class," when there's no way to have it execute more than once (when the class is first loaded.)
In Ruby, all classes are themselves objects - they are instance of the class Class. So what's happening under the hood when Ruby "reads" a class definition, is that Ruby is actually running methods on that instance of the class Class.
So a def inside the class definition of the class A is actually the same as A.send(:define_method, ...) - to understand what that means, you have to understand what senders and receivers are, and how they are implemented in Ruby. That SO post I linked to does a pretty good job of referring you to more material. The def syntax is just a convention to make the sending/receiving look like the syntax of other languages so that it's easier to "transition" to Ruby from other languages.
Ruby doesn't require that you should only call methods on the class itself when defining the class - so you can run any code you want. One use case is when you define a variable prefixed with an # inside the class definition:
class A
#class_var=123
def self.class_var
#class_var
end
def self.class_var=(inp)
#class_var=inp
end
end
a=A.new
b=A.new
b.class.class_var=5
puts a.class.class_var
# 5
Note the def self. notation that defines "class methods" - they can then access the "class variable" that you created by writing the code "inside the class."
This question comes up a lot for me, so I've written a more extensive blog post about it, to try and go into more detail about how Ruby implements these concepts. I have written them here in scare quotes, because they mean slightly different things in Java and C++, so don't apply their meanings very directly to try and understand what they mean in Ruby.
What sense has write code out of methods?
You've already seen it. Instead of changing the language itself (and the compiler) to add annotations to Ruby, the makers of Rails could make model validations easily (and lots of DSL for different things). Another example is att_accessor, a method that called in the context of a class will add accessor methods. And there are many many more.
Basically, you are adding that way lots of flexibility to the language.
How it can be used (how can it be invoked)?
You already did in your example. Just put the code there... and it is executed.
You can use and invoke it like such:
def putString
puts "Inside method outside of class"
end
class A
puts "Inside of A class" #[1]
putString
end
It gets invoked when you require the file.
Uses?
Meta-programming is one
['foo','bar'].each |m| do
def m
[m]
end
end
There's an even sneakier scenario where you can put code outside of the class, never mind the method, confused the heck out me when I first saw it.
Most of the answers here refer to code inside a class and outside its methods. I think the OP asked about code outside everything - forbidden in Java!
Java mimics the C languages' compilation cycle. In C, only certain kinds of lines can happen during compilation. Then, only the remaining kinds of lines can run during execution.
In Ruby, code evaluates from top to bottom. The commands class and def essentially mean "capture all these tokens, and evaluate them later." So, because the entire file evaluates at runtime, things outside classes can happen very early.
The most notorious example is:
require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
require is (prepare for a shock) just a method, and File is (prepare for another one) always available. So a Ruby programmer can exchange zillions of boring, fragile lines of configuration files (in Java ANT or C MAKE) for just a few ugly - but bullet-proof - lines of raw Ruby, at the top of each file.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Okay, this one is pretty hard to google.
Occasionally, I stumble upon code in any language that uses a naming convention where variable names start with the prefix 'the' under certain circumstances.
I could not figure out, however, what these circumstances are. So my questions are:
Is this convention common? Does it have a name?
If 1) is still "ungoogleable": What are the principles behind this convention? What problems does it address? I would like to understand.
If not covered by 1) and 2): Where does the convention come from? What are its origins? Is or was it connected to a specific programming language?
Examples:
From the Steinberg ASIO SDK 2.3, file asiodrivers.cpp, line 88:
extern IASIO* theAsioDriver;
where IASIO is an interface definition.
http://hl7api.sourceforge.net/base/apidocs/src-html/ca/uhn/hl7v2/util/StringUtil.html
http://xml.apache.org/xalan-c/apiDocs/classXStringAllocator.html
http://www.cplusplus.com/forum/beginner/65050/
http://www.cise.ufl.edu/~sahni/dsaac/enrich/c20/fold2.htm
I am hoping for some insight into why people do this. One example might be to tell parameters from members in setter/getter methods, but this choice of prefix seems random to me.
The only time I would be tempted to start a variable name with the would be to indicate that it is a singleton. Other than that its use seems unnecessary.
Based on personal experience (mostly Java, Ruby, Python, and long ago C and C++), the convention you describe is not common.
There is a related convention, the "Type Suggesting Parameter Name" pattern in Kent Beck's "Smalltalk Best Practice Patterns" (an excellent book regardless of whether you write Smalltalk), which names method parameters a(type) or an(type), e.g. anObject. My understanding is that this convention is to make code read a little more like English, not to avoid any naming collision that might otherwise arise. (Smalltalk classes are capitalized, so one could name parameters with downcased class names and there would be no collision.)
An expanded version of this convention which I saw somewhere prefixed parameters or locals with a or an and object instance variables with the, which makes some sense: the instance variable is "the" one most important to the containing object, while the parameter or local is just "a" thing. I wish I could remember where I saw it. I think it was written by a well-known author.
I don't normally use these conventions myself; instead I (like most code I've seen) use this. in Java and self. in Ruby to disambiguate instance variables and rely on short methods to sidestep the need to disambiguate parameters and locals. Naming variables for their roles and not their types (the best practice in any case) also usually eliminates the need for such conventions.
However, inspired by whatever it was I once read, I use the when a local shadows a method or function and I just can't think of a different meaningful name for the local.
In Ruby, a local shadows a method only when the method has no arguments:
def foo
7
end
foo = foo
=> nil # the left hand side shadowed the right hand side
This can be avoided by calling the method with empty parentheses:
def foo
7
end
foo = foo()
=> 7
but empty parentheses seem so un-Ruby to me that I prefer "the":
def foo
7
end
the_foo = foo
=> 7
In Python a local can shadow a function regardless of the function's argument count, so I find myself reaching for the more often.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Steve Klabnik recently said in a pull request for a utility module:
[The code] obscures the fact that these are class methods, and we
want to use them that way. Plus, I think that extend self is generally
an anti-pattern, and shouldn't really be used except in some cases. I
thought about it, and I think this is one of those cases.
When creating a utility module (e.g., for math) what's the best way to declare the methods?
And when is the extend self idiom ever appropriate?
It's not exactly helpful that he doesn't say 1) why he thinks it is an anti-pattern (other than obscuring the fact that you are defining class methods) or 2) why, having thought about it, this is one of the cases he thinks it shouldn't be used, so it's hard to specifically counter any of his arguments.
However, I'm not convinced that extend self is an anti-pattern. A utility module seems like a good example of a use case for it. I've also used it as easy storage for test fixtures.
I think it's worth examining what extend self is, what possible problems there might be with it, and what alternatives there are.
At it's core, it is simply a way to avoid having to write self. before every method definition in a module that you never intend to mix into a class, and that will therefore never have an 'instance' of itself created, so can by definition only have 'class' methods (if you want to be able to call them, that is).
Does it disguise the fact that you intend the methods to be used as class methods? Well, yes, if you don't look at the top of the file to where it says extend self, that's possible. However, I would argue that if it's possible for you to make this confusion, your class is probably too complicated anyway.
It should be obvious from your class - from its name and from its contents - that it is intended as a collection of utility functions. Ideally it wouldn't be much more than a screen tall anyway, so extend self would almost never be out of sight. And as we'll see, the alternatives also suffer almost exactly the same problem.
One alternative would be to use class << self like this:
module Utility
class << self
def utility_function1
end
def utility_function2
end
end
end
I am not a fan of this, not least because it introduces an extra layer of indentation. It's also ugly (totally subjective, I know). It also suffers from exactly the same problem of 'obscuring' the fact that you're defining class methods.
You're also free, using this approach, to define instance methods outside the class << self block - which might lead to the temptation to do so (although I'd hope it wouldn't), so I'd argue that extend self is superior in this regard by removing the possibility of this muddying of the waters.
(The same is true, of course, of the 'long-hand' style of using def self.utility_function.)
Another approach could be to use a singleton object. I don't think this is a good idea at all, because a singleton object is an object for a reason - it's meant to hold state and do stuff, but also be the only one in existence. That simply doesn't make sense for a utility module, which should be a series of independent stateless functions. You don't want MathUtils.cos(90) to ever return a different value based on internal state of MathUtils, right? (I know that you can of course hold state in a module and do all these things, but it's more of a semantic division for me than a technical one).
It also leads to the same problem of arguably obscuring the fact that the methods are intended to be called as class methods (sort of). They are defined as instance methods, and you call them as instance methods, but by first getting the single instance of the class by calling the class method instance.
class MathSingleton
include Singleton
def cos x
end
end
MathSingleton.instance.cos x
This would be a terrible alternative to extend self for this purpose. But look, also, the only thing indicating that these methods are to be used as methods on the singleton instance is that one line just up at the top, just like extend self.
So what other possible downsides are there? I don't know of any, but I'd be interested to hear them if anyone else does.
I would argue that extend self leads to shorter code, that leaves out the extraneous self.s and allows you to concentrate on the names and therefore meanings of its methods.
It also has the nice property that, if you are writing another class that uses lots of your utility functions, for example, you can just mix it in and they will be available without having to use the module name each time. Much like static imports work in other languages.
Utility modules, as opposed to mixins, are containers that wrap constants and methods with some common concern. Mixins, such as this one,
module SingingCapability
def sing; puts "I'm singing!" end
end
Human = Class.new
Fred = Human.new.tap { |o| o.extend SingingCapability }
generally pose some requirements on their includers. That is, generally only certain objects are good candidates to include or extend a given mixin. Hypothetically, it is possible that a module is at the same time a utility module, and a mixin. And if the module itself belongs among eligible candidates to be extended by it, then go ahead and extend it.
In sum, I do think it's somewhat not a very good practice, but Ruby defies me on this one since we even have Module#module_function method to facilitate this malpractice:
module SingingBox
def sing; "Tralala!" end
module_function :sing
end
SingingBox.sing #=> "Tralala!"
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Ruby is a beatifull language, but with a key word "end" which I hates to write many many times.
Is there any method by which I can write concise code without writing "end" every time?
Ok, this is partially non-responsive, but originally, begin ... end was the paradigm. And by originally, I mean languages you or I have never seen; things called funny names like Algol. Some languages (FORTRAN, Basic) staggered along for years with only single-statement conditionals.
Then C, and later, Java, came along and took over the world. They had { .. }. and that was not bad.
Python and a few others (including a microcode assembler I wrote years before Python was invented) have experimented with using indent for block structure. Nice solution but apparently it wasn't all that popular.
All of those worked but there were various issues.
Believe it or not, Ruby's syntax design no-doubt involved consideration of all these other less-than-perfect dead ends.
My suggestion is: give it another chance just the way it is.
Ruby merges the groundbreaking and technically worshipped Smalltalk and Lisp with the practical and actually useful Perl. For whatever reason, Smalltalk and (((Lisp))) haven't succeeded in 30 and 55 years, roughly, and Perl is fading. Ruby is by far the most advanced language ever to become popular.
The future is Ruby (and Python and JavaScript) and people like Ruby for a reason. One of those reasons is the really user-friendly syntax.
Believe me, the alternatives are worse.
Keep trying!
You don't actually have to write end at all to write Ruby:
Foo = Class.new {
define_method(:bar) {
puts "I don't recommend this"; \
return 42 \
if (:what_is_going_on?)
}
}
Foo.new.bar # => 42
Expect other Rubyists reading your code to wonder what got through your mind, though...
Another possibility without any end that replaces all the dreadful end with your favorite character:
# encoding: utf-8
define_singleton_method(:_){|code|
eval(code.gsub("◊", "e\156d"))
}
_ <<-EOC
class Foo
def bar
if :what_is_going_on?
puts "I don't recommend this either"
return 42
◊
◊
◊
p Foo.new.bar # => 42
EOC
Or replace _ with your own parser that generates ends according to the indentation!