Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Browsing the ruleby source code, I noticed that they were calling Container(:and), which is something I rarely see. In fact, the only other place I've seen it is in the fabrication gem
A quick look showed that Container subclasses Array, and a quick hop into Pry showed that Array(:anything) #=> [:anything].
Another quick look at the ruby documentation for Array doesn't shed much light on to this question.
What method is being called by Array(), where is it documented, how can one define a method like this, and is it considered "bad form" in ruby?
For your first question, the answer is that it makes an array of its parameters.
For your second, I have no clue, but it's simple enough.
For your third, here it is: In Ruby, defining a global method with the same name as the class is considered good form only when used to construct or convert from object of that type of a more fundamental type. You should not define this method unless you are creating some sort of low type. You could define this for some class like BigInt128 but you shouldn't for ObscureOrSpecializedType678. There is also a design for these methods.
If the data that you are passed is of the returned type, return it. If the data is of a directly related type, perform obvious conversions (Fixnum to BigInt128). If the data passed in can be converted and is somewhat related (String to Fixnum) convert it (this conversion is usually only for String). If the data can not be converted, throw an exception. You should NEVER return a "magic value".
The other use of this method is to create a semi-literal syntax for non-literal types. The best examples of this are Rational() and Complex(). These functions, in addition to doing conversions, allow you to create rations and complex numbers in a more natural way (Rational(1, 2) vs. Rational.new(1, 2)). If there is a certain argument list that is simpler to the literal representation of a type, you would define a Classname() method.
For the most part, these methods are only part of the core language, and unless you are making a class like BigInt128 or FancyString or NaturalNumber, you should not define these methods.
From what I know the defined of these are:
Array(*args) -- Returns arguments as an array
Complex(real, complex) -- Create a complex number with given real and complex parts
Float(arg) -- Returns arg converted to a float (takes things like strings too)
Integer(arg) -- Same as Float(), but converts to an integer(floats are truncated)
Rational(numerator, denominator=1) -- Creates a Rational number with the given parts
String(arg) -- Converts argument to string by calling to_s
Also, some classes define [] as a class method, which is used for more complex initialization from basic data types (usual initialization only, not conversion) such as Hash[].
I don't know if it is really it, but made some tests with iurb and I guess it is only a helper funcion to create a new Array.
Given I have this class
class MyClass
def initialize(arg)
puts "Initialized with #{arg.to_s}"
end
end
then I can define a helper function like
def MyClass(arg)
MyClass.new(arg)
end
and here you go
irb(main):009:0> MyClass(1)
Initialized with 1
=> #<MyClass:0x4770e10>
uhhhh, since you're in Pry why not ask Pry to show you the documentation?!?!
[25] (pry) main: 0> show-doc Array
From: object.c in Ruby Core (C Method):
Number of lines: 4
Owner: Kernel
Visibility: private
Signature: Array(arg1)
Returns arg as an Array. First tries to call
arg.to_ary, then arg.to_a.
Array(1..5) #=> [1, 2, 3, 4, 5]
[26] (pry) main: 0> show-method Array
From: object.c in Ruby Core (C Method):
Number of lines: 5
Owner: Kernel
Visibility: private
static VALUE
rb_f_array(VALUE obj, VALUE arg)
{
return rb_Array(arg);
}
[27] (pry) main: 0>
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
class Library
attr_accessor :games
def initialize(games)
#games = games
end
end
How comes there is a colon infront of games?
Whenever I research what the : means I usually find articles where people say its a symbol, then give a very ambiguous definition of what a symbol is.
To keep it simple: symbols are nothing more than a name for a constant. The value is irrelevant, but only symbols with the same name share the same value:
Symbol objects represent names [...] inside the Ruby interpreter. They are generated using the :name and :"string" literals syntax, and by the various to_sym methods.
See Ruby docs on Symbol for more details.
The usual use cases for symbols include:
keys for hashes (hsh[:foo] 0 42; hsh[:foo] #=> 42)
method or variable names, since those types of objects are not first-class citizens of Ruby (there is a Method class representing a method, but that's something different)
Please note, that symbols won't be garbage collected, unlike strings. That means, you should avoid code like
key = :"oh-my-#{bar}" # like string interpolation
when bar is build from user (attacker) generated input.
In the case of attr_accessor, the parameter (:games in your case), creates an instance variable with the same name (#games) plus a setter and getter method (let l = Library.new, then the setter l.games=(val) and the getter l.games become available).
Instances of Symbol class. However it's mentioned and explained in all tutorials or beginner guides I've seen so far.
The colon indicates the variable is a symbol. Symbols are Strings, with one important difference, Symbols are immutable. Mutable objects can be changed after assignment while immutable objects can only be overwritten.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am making a dating simulator. One of the first things I need is to keep track of the way characters feel about each other. In this sim, anyone can date anyone else, and there are two variables for relationship (one for love and one for friendship).
So I thought the easiest way to do this would be for each character to have a separate class that kept track of how they felt about everyone else. Below is one such sample class. I also thought that the easiest way to keep track of where points should be added was by giving each character a hash that pointed to their own variable, and then using a swap function to trade targets with the person they are speaking to.
However, I am getting an error message.
class HRelatStatus
def initialize
{#target=> #hrelat}
#krelat =[10, 10]
#arelat =[9, 4]
#srelat =[13, 11]
#jrelat =[12, 1]
#brelat =[5, 5]
#hrelat=[0, 0]
end
def dataaccess
attr_accessor :target, :krelat, :arelat, :srelat, :jrelat, :brelat, :hrelat
end
def makehappy
#target[0] = #target[0]+1
end
end
hfeels=HRelatStatus.new
puts #krelat.class
puts #krelat[1]
hfeels.makehappy
puts #target[0]
When I try to run this, #krelat comes back as a Nil class. And when I try to run the makehappy method (or any method, really) I get the error message undefined method '[]' for nil class.
How do I stop my instance variables from being nil classes? How can I sucessfully make methods that will add to one variable in the array for a specific character? And does anyone have a better idea for how I can specify who to target?
You are saying:
hfeels=HRelatStatus.new
puts #krelat.class
But there is no such thing as #krelat in this context. What you are after is the krelat instance variable inside your instance, i.e. hfeels.krelat.
(Of course, that won't work either because you've hidden your accessor generators inside an instance method.)
The first thing you actually need to do is learn how Ruby (or really, variable scope in any language) works.
#krelat outside of the class is totally unrelated to #krelat inside the class.
The makehappy method won't work because { #target => #hrelat } doesn't do anything in Ruby (well, it creates a hash with a nil key pointing to a nil value and then discards that hash. Ie. effectively nothing.
This code is a total mess, learn Ruby first. Buy "Programming Ruby" and read it.
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 10 years ago.
Most of the examples I see are trivial, and I'm not sure what this adds to the language. I get why you would use blocks in Objective-C for handling callbacks or in Javascript with closures used as callbacks for timers, but I'm not sure what I'd be using blocks for in Ruby. Is it something that could be used instead of a function with something like inject?
Ruby uses blocks all over, it's one of the most ubiquitous features of the language. It is basically an optimised case of a function-as-a-value. A real function object, like in JavaScript is in Ruby an instance of a Proc class. A block is not an object, and thus avoids some of the overheads that objecthood incurs. The reasoning is, in almost all cases where you want to pass a function as an argument, you'll only be passing one, and you'll want to define it right there on the spot, so why not optimise, and make things a bit syntactically nicer?
This is a block:
[1, 2, 3].each do |i|
puts i
end
This is a function:
func = Proc.new do |i|
puts i
end
[1, 2, 3].hypothetical_each(func)
You can see that even defining a functional value involves a block (as a parameter to Proc constructor).
You normally use a block in inject, not a function. You use it in pretty much every loop structure in Ruby (while is very uncommonly used).
You also use blocks to construct domain-specific languages like Sinatra:
get 'index.html' do
"Hello World"
end
or Rspec:
describe "addition" do
it "should add two numbers together" do
(1+2).should equal(3)
end
end
Learn blocks well, because you can't read, nor write Ruby well without them.
The secret to blocks in ruby is held in the nature of ruby's design.
Ruby was designed with an object modal where method calls are sent as 'messages' to the object and return values are responses. In ruby (unlike python and some other languages), functions and methods are NOT object themselves.
Blocks are ruby's way of allowing function-like messages in this modal and are key to how ruby handles iteration in general.
Someone please correct me if I'm wrong but I believe it is in fact impossible to do any iteration in ruby without creating a block or using a while statement
and in fact the for i in object notation is just syntax shorthand for access to the object each method.
ie.
for i in 1..5
#do stuff with i
end
Is executed exactly the same as:
1..5.each do |i|
#do stuff with i
end
By the ruby VM where the Range object 1..5 (which includes the ruby standart lib Enumerable module) yields it's elements to the passed block
Under the hood this operation looks something like this (note this is a simplified version that fails to take into account the ... exclusive and .. inclusive version of range)
class Range
def init(start, end)
#start = start
#end = end
end
def each
i = #start
while i < #end
yield i
i += 1
end
end
end
So when that for loop is called it creates a range object obj = Range.new(1,5) then sends a message to the object obj.send(:each, &block) and inside the each method is use a while loop and yields to the block
TL;DR
Ruby uses block internally as they are critical to it's very design, without them the language itself would not work with it's message => object => response modal.
So you should not ask: "Why should I use blocks?" Because you can't write a ruby program without them.
Instead you should ask: "How is a block in ruby different than a block in Objective-C and Javascript?" Because they ARE a different.
I cant speak for Objective-C but in JavaScript a block is very much an object. It's a container for code that other objects can pick up and use to do whatever it needs to, the block doesnt even have to relate to the object using it.
In ruby a block is more like a set of instruction an object receives in the mail that it uses on itself (which it then passes to the mail man the next time he comes around)
Instead of supporting method overloading Ruby overwrites existing methods. Can anyone explain why the language was designed this way?
"Overloading" is a term that simply doesn't even make sense in Ruby. It is basically a synonym for "static argument-based dispatch", but Ruby doesn't have static dispatch at all. So, the reason why Ruby doesn't support static dispatch based on the arguments, is because it doesn't support static dispatch, period. It doesn't support static dispatch of any kind, whether argument-based or otherwise.
Now, if you are not actually specifically asking about overloading, but maybe about dynamic argument-based dispatch, then the answer is: because Matz didn't implement it. Because nobody else bothered to propose it. Because nobody else bothered to implement it.
In general, dynamic argument-based dispatch in a language with optional arguments and variable-length argument lists, is very hard to get right, and even harder to keep it understandable. Even in languages with static argument-based dispatch and without optional arguments (like Java, for example), it is sometimes almost impossible to tell for a mere mortal, which overload is going to be picked.
In C#, you can actually encode any 3-SAT problem into overload resolution, which means that overload resolution in C# is NP-hard.
Now try that with dynamic dispatch, where you have the additional time dimension to keep in your head.
There are languages which dynamically dispatch based on all arguments of a procedure, as opposed to object-oriented languages, which only dispatch on the "hidden" zeroth self argument. Common Lisp, for example, dispatches on the dynamic types and even the dynamic values of all arguments. Clojure dispatches on an arbitrary function of all arguments (which BTW is extremely cool and extremely powerful).
But I don't know of any OO language with dynamic argument-based dispatch. Martin Odersky said that he might consider adding argument-based dispatch to Scala, but only if he can remove overloading at the same time and be backwards-compatible both with existing Scala code that uses overloading and compatible with Java (he especially mentioned Swing and AWT which play some extremely complex tricks exercising pretty much every nasty dark corner case of Java's rather complex overloading rules). I've had some ideas myself about adding argument-based dispatch to Ruby, but I never could figure out how to do it in a backwards-compatible manner.
Method overloading can be achieved by declaring two methods with the same name and different signatures. These different signatures can be either,
Arguments with different data types, eg: method(int a, int b) vs method(String a, String b)
Variable number of arguments, eg: method(a) vs method(a, b)
We cannot achieve method overloading using the first way because there is no data type declaration in ruby(dynamic typed language). So the only way to define the above method is def(a,b)
With the second option, it might look like we can achieve method overloading, but we can't. Let say I have two methods with different number of arguments,
def method(a); end;
def method(a, b = true); end; # second argument has a default value
method(10)
# Now the method call can match the first one as well as the second one,
# so here is the problem.
So ruby needs to maintain one method in the method look up chain with a unique name.
I presume you are looking for the ability to do this:
def my_method(arg1)
..
end
def my_method(arg1, arg2)
..
end
Ruby supports this in a different way:
def my_method(*args)
if args.length == 1
#method 1
else
#method 2
end
end
A common pattern is also to pass in options as a hash:
def my_method(options)
if options[:arg1] and options[:arg2]
#method 2
elsif options[:arg1]
#method 1
end
end
my_method arg1: 'hello', arg2: 'world'
Method overloading makes sense in a language with static typing, where you can distinguish between different types of arguments
f(1)
f('foo')
f(true)
as well as between different number of arguments
f(1)
f(1, 'foo')
f(1, 'foo', true)
The first distinction does not exist in ruby. Ruby uses dynamic typing or "duck typing". The second distinction can be handled by default arguments or by working with arguments:
def f(n, s = 'foo', flux_compensator = true)
...
end
def f(*args)
case args.size
when
...
when 2
...
when 3
...
end
end
This doesn't answer the question of why ruby doesn't have method overloading, but third-party libraries can provide it.
The contracts.ruby library allows overloading. Example adapted from the tutorial:
class Factorial
include Contracts
Contract 1 => 1
def fact(x)
x
end
Contract Num => Num
def fact(x)
x * fact(x - 1)
end
end
# try it out
Factorial.new.fact(5) # => 120
Note that this is actually more powerful than Java's overloading, because you can specify values to match (e.g. 1), not merely types.
You will see decreased performance using this though; you will have to run benchmarks to decide how much you can tolerate.
I often do the following structure :
def method(param)
case param
when String
method_for_String(param)
when Type1
method_for_Type1(param)
...
else
#default implementation
end
end
This allow the user of the object to use the clean and clear method_name : method
But if he want to optimise execution, he can directly call the correct method.
Also, it makes your test clearers and betters.
there are already great answers on why side of the question. however, if anyone looking for other solutions checkout functional-ruby gem which is inspired by Elixir pattern matching features.
class Foo
include Functional::PatternMatching
## Constructor Over loading
defn(:initialize) { #name = 'baz' }
defn(:initialize, _) {|name| #name = name.to_s }
## Method Overloading
defn(:greet, :male) {
puts "Hello, sir!"
}
defn(:greet, :female) {
puts "Hello, ma'am!"
}
end
foo = Foo.new or Foo.new('Bar')
foo.greet(:male) => "Hello, sir!"
foo.greet(:female) => "Hello, ma'am!"
I came across this nice interview with Yukihiro Matsumoto (aka. "Matz"), the creator of Ruby. Incidentally, he explains his reasoning and intention there. It is a good complement to #nkm's excellent exemplification of the problem. I have highlighted the parts that answer your question on why Ruby was designed that way:
Orthogonal versus Harmonious
Bill Venners: Dave Thomas also claimed that if I ask you to add a
feature that is orthogonal, you won't do it. What you want is
something that's harmonious. What does that mean?
Yukihiro Matsumoto: I believe consistency and orthogonality are tools
of design, not the primary goal in design.
Bill Venners: What does orthogonality mean in this context?
Yukihiro Matsumoto: An example of orthogonality is allowing any
combination of small features or syntax. For example, C++ supports
both default parameter values for functions and overloading of
function names based on parameters. Both are good features to have in
a language, but because they are orthogonal, you can apply both at the
same time. The compiler knows how to apply both at the same time. If
it's ambiguous, the compiler will flag an error. But if I look at the
code, I need to apply the rule with my brain too. I need to guess how
the compiler works. If I'm right, and I'm smart enough, it's no
problem. But if I'm not smart enough, and I'm really not, it causes
confusion. The result will be unexpected for an ordinary person. This
is an example of how orthogonality is bad.
Source: "The Philosophy of Ruby", A Conversation with Yukihiro Matsumoto, Part I
by Bill Venners, September 29, 2003 at: https://www.artima.com/intv/ruby.html
Statically typed languages support method overloading, which involves their binding at compile time. Ruby, on the other hand, is a dynamically typed language and cannot support static binding at all. In languages with optional arguments and variable-length argument lists, it is also difficult to determine which method will be invoked during dynamic argument-based dispatch. Additionally, Ruby is implemented in C, which itself does not support method overloading.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Ruby functions vs methods
Im just reading some ruby documentation and t seems to use the term function and method in an interchangeable way, i jut wanted to know if there is any distinction?
the docs im looking at refer to this as a function:
def saysomething()
puts "Hello"
end
saysomething
and this a method:
def multiply(val1, val2 )
result = val1 * val2
puts result
end
this may be a something semantic but i wanted to check
jt
In Ruby, there are not two separate concepts of methods and functions. Some people still use both terms, but in my opinion, using "function" when talking about Ruby is incorrect. There do not exist executable pieces of code that are not defined on objects, because there is nothing in Ruby that is not an object.
As Dan pointed out, there's a way to call methods that makes them look like functions, but the underlying thing is still a method. You can actually see this for yourself in IRB with the method method.
> def zomg; puts "hi"; end
#=> nil
> method(:zomg)
#=> #<Method: Object#zomg>
> Object.private_instance_methods.sort
#=> [..., :zomg]
# the rest of the list omitted for brevity
So you can see, the method zomg is an instance method on Object, and is included in Object's list of private instance methods.