Say I have class Player and I want a boolean method to check if a player is attacked:
class Player
attr_accessor :name, :health, :attacked?
def initialize(name)
#name = name
#health = 100
#attacked? = false
end
end
I get a syntax error:
SyntaxError: (irb):14: syntax error, unexpected '='
#attacked? = false
^
from /usr/bin/irb:12:in `<main>'
Removing the question mark from attacked fixes the problem, but I thought it would better follow convention to have attacked? in my code. It's not a big deal to forgo the question mark, but why are zero? and nil? conventions when#variables? and def methods?= are invalid?
Note that if you comment out the line causing your error (#attacked? = false), you will still get an error relating to the question mark:
NameError: invalid attribute name `attacked?'
The problem is that ? is not a valid character in a variable name. The first error (the SyntaxError that you’re seeing) is caused at parse time and caught immediately. The second error is caused when Ruby tries to evaluate the code and cannot create an instance variable with a name containing an invalid character.
A question mark is a valid character at the end of a method name though (actually it’s possible to have a method with a ? anywhere in its name, but you can’t call such a method directly).
One way to achieve what you want is something like this:
class Player
attr_accessor :name, :health, :attacked
alias :attacked? :attacked
def initialize(name)
#name = name
#health = 100
#attacked = false
end
end
This leaves attacked without the question mark, but adds attacked? as an alias.
I've run into the same problem before, and wished that I could make instance variables with a trailing question mark. It seems to be a corner case in Ruby's grammar. Check this out:
>> 1 ? 2 : 3
=> 2
>> 1?2:3
=> 2
>> #a = true
=> true
>> #a?1:2
=> 1
>> a = true
=> true
>> a ? 1 : 2
=> 1
>> a?1:2
SyntaxError: (irb):9: syntax error, unexpected ':', expecting $end
So the ? symbol is overloaded in Ruby's grammar -- it is used for the ternary operator, and as part of valid identifiers for method names. This causes ambiguity in the last case, where Ruby's lexer seems to bite off the a? as a single token, which leaves it unable to parse the rest of the ternary operator properly. With instance variables, this can't happen.
Again, I agree that allowing question marks in instance variable names would be very useful, certainly more valuable than making some obscure uses of the ternary operator non-ambiguous.
Related
I have this very simple piece of code (using Ruby 3)
def eat(main, dessert*)
if dessert.empty?
puts "I eat #{main}"
else
puts "I eat #{main} than #{dessert}."
end
end
Wher I run eat("mushrooms") that provokes errors:
argu.rb:1: syntax error, unexpected '*', expecting ')'
def manger(plat, dessert*)
argu.rb:7: syntax error, unexpected `end', expecting end-of-input
I don't see why.
Splat operator should put before parameters so your signature should be
def eat(main, *dessert)
Not sure where you got the idea from using dessert*, but you could define your method as
def eat(main, dessert = [])
to provide a default argument (of course it must be one which can respond to empty?).
Of course it is up to you to justify, why "main" can be anything (i.e. a String), but dessert must be a collection. I would test for dessert as
if dessert.nil?
and hence provide nil as default value for the dessert.
I'm trying to get an if statement for users who put incorrect data.
Here's my code:
class Breweries::CLI
def start
puts "Hello!"
puts "---------------------------"
puts "Please enter your location:"
input = gets.strip.downcase
#data = Breweries::API.get_breweries(input)
#objects = Breweries::HoppyCode.all
if input.length < 1
puts "Sorry!!"
puts "```````"
start
else
display_info
end
end
def display_info
puts "You'll love the following spots!"
puts "********************************"
#objects.each.with_index(1) {|brewery, index| puts "#{index}. #{brewery.name}"}
puts "Please make a selection by index number for more information:"
input = gets.strip.downcase
if(input.to_i > 0)
#brewery = #objects[input.to_i - 1]
puts "name: #{#brewery.name}"
puts "street: #{#brewery.street}"
puts "city: #{#brewery.city}"
puts "phone: #{#brewery.phone}"
puts "website_url: #{#brewery.website_url}"
display_info
elsif (input == "quit")
quit
elsif (input == "menu")
start
end
end
def quit
puts "Goodbye. Drink responsibly and enjoy."
end
end
When I put something that would generate an error, it returns the following:
Please enter your location: nvifpejvf80ejvip
Traceback (most recent call last):
2: from bin/breweriesCLI:6:in `<main>'
1: from /home/munificent-format-5297/Development/breweries/lib/breweries/cli.rb:8:in `start' /home/munificent-format-5297/Development/breweries/lib/breweries/api.rb:6:in `get_breweries': undefined method `[]' for nil:NilClass (NoMethodError)
How can I solve the undefined method '[]' error? Here's the API code in case that's necessary.
class Breweries::API
def self.get_breweries(input)
#breweries_hash = HTTParty.get("https://api.openbrewerydb.org/breweries?by_city=#{input}")
breweries_obj = {
name: #breweries_hash[1]["name"],
street: #breweries_hash[3]["street"],
city: #breweries_hash[4]["city"],
phone: #breweries_hash[10]["phone"],
website_url: #breweries_hash[11]["website_url"]
}
Breweries::HoppyCode.new(breweries_obj)
end
end
When the input is invalid, the call to
#breweries_hash = HTTParty.get("...")
returns not the object you expect (I’d suggest it returns an empty hash.) That makes it impossible to get to details in the following lines. Depending on how are you to handle it, you might decide to e. g. early return from this function, or raise, or do something else.
To approach this, start with debugging the issue, like this:
#breweries_hash = HTTParty.get("...")
puts #breweries_hash.inspect
...
That way you’ll see what gets returned and get the ideas of how to handle it.
If I am right, and what is returned is an empty hash, you might want to early return from this function.
#breweries_hash = HTTParty.get("...")
return if #breweries_hash.empty?
...
Identifying the Problem
There are lots of ways to solve for the nil problem, but at a quick glance it seems like part of the problem here is that you're somehow expecting input to return a valid Hash object from your API call, but an empty String or an instance of FalseClass may not do that. Consider the following:
input = gets.strip.downcase # <RETURN> here gets an empty string
input #=> ""
input.to_i > 0 #=> false
Then consider that some downstream of Breweries::API.get_breweries is expecting to operate on a Hash object instead if an instance of NilClass. In this case, that looks like #breweries_hash[1]["name"] and other operations on #breweries_hash.
Some Options
Without knowing more about your code, I don't want to be prescriptive here. But in general, you can do one or more of the following:
Coerce arguments into the expected class in the method call, the method signature, or the method body. For example, for Array objects:
# coerce a String to an Array, raising an exception if it can't
input = ""
Array(input)
#=> [""]
# coerce some Array to a Hash
array = [:name, "foo", :street, "bar"]
Array(array.each_slice 2).to_h
#=> {:name=>"foo", :street=>"bar"}
Explicitly check that you have an Hash object:
fail "#breweries is not a Hash" unless #breweries.is_a? Hash
Raise an exception rather than return 0 if input isn't actually a valid Integer representation in the first place:
input = Integer(gets.strip.downcase)
Check if your Hash or Array object responds to the relevant method calls, and raise a more helpful exception message:
raise sprintf("#brewery: %s", #brewery.class) unless #brewery.respond_to? :[]
There are other things you might do as well. Broadly speaking, you need to adjust your code to check the return value of your call to ensure it's not nil, then branch/raise/rescue appropriately depending on whether or not you ever expect nils as a valid return value from Breweries::API.get_breweries.
A Note on Using Exceptions for Non-Exceptional Circumstances
As a rule of thumb, you should only raise exceptions for truly unexpected circumstances, or when the program should halt because some condition can't (or shouldn't) be handled within the program during runtime. Which is best in your particular use case is really a design decision, and outside the scope of the original question. However, you might want to read Avdi Grimm's Exceptional Ruby for a deeper explanation of when exceptions might better than branching or handlers (or vice versa), but the choice in your code is a little left of center of the problem you're actually dealing with right now.
I'm using create() to insert into a table that already exists, but some of the table fields and variable names start with a number. Currently in Ruby I'm getting a syntax error "unexpected tIDENTIFIER" when I try to do something like the following-
foo.each do |x|
Object.create(
3pm: x.3pm,
3pa: x.3pa
)
end
If I change it to '3pm' => x.3pm, it gives me a syntax error on the x.3pm portion.
How could I escape this to get it functioning?
The problem is that 3pm is not a valid identifier in Ruby. In Ruby, symbol literals declared with the :name syntax and method names must both be valid identifiers.
In the case of the keys, you can get around this by either using strings instead, as you discovered, or by using the :'name' syntax for symbol literals:
foo.each do |x|
Object.create(
:'3pm' => x.3pm,
:'3pa' => x.3pa
)
end
Unfortunately, this still leaves the problem of 3pm and 3pa not being valid method names. Normally, since those are not valid methods names, they couldn't even be methods on x in the first place. In this case though, x is likely using the either the define_method or method_missing features of Ruby to create or simulate the existance of a method named 3pm (even though that's normally not a valid method name in Ruby).
Thankfully, we can get around this by using Object#public_send to call the method:
foo.each do |x|
Object.create(
:'3pm' => x.public_send(:'3pm'),
:'3pa' => x.public_send(:'3pa')
)
end
That should resolve your problem.
This question already has answers here:
How to understand symbols in Ruby
(11 answers)
Closed 10 years ago.
class A
def test
"Test from instance"
end
class << self
def test
"Test from class"
end
end
end
p A.send(:test) # "Test from class"
p A.new.method(:test).call # "Test from instance"
Here symbol works as expected, but here:
s="test"
s1=:s
p s1 # :s
why :s is printed here?? I dont understand the reason behind it.
Can anyone please explain for me ?
Symbols are sort of lightweight strings (though they are not strings). The send() and method() methods can take strings or symbols; one is converted to the other in the inner workings (not sure which) and then ruby executes the method with the matching name. Hence A.send(:text) is equivalent to A.text(). If you had a variable named methodName = :text, you could do A.send(methodName) but not A.methodName().
Symbols are not variables, so you can't assign a value to a symbol. In your example, the symbol :s is unrelated to the variable s (despite the fact that they have the same "name", preceding it with a colon makes it a symbol instead of a variable). You're assigning a string value to the variable s but telling it to print the symbol :s, which it does.
Symbols are just a special kind of stringlike value that's more efficient for the runtime to deal with than a regular string. That's it. They aren't methods or variables or anything like that.
When you do A.send(:test), all you are doing is saying "hey, A, call the method named 'test'". You aren't sending the method itself, just the name; it's the logic inside send that is responsible for looking up the actual method to call.
The same thing goes when you ask for method with A.new.method(:test). All you are passing to method is the name "test", not the method defined with that name. It's up to method to use the name and find the actual method so it can return it, and it's that return value - a Method object - that you are doing call on. You can't do call on a Symbol like :test, because it's just a name.
From https://stackoverflow.com/a/1255362/509710:
p foo does puts foo.inspect, i.e. it prints the value of inspect instead of to_s, which is more suitable for debugging (because you can e.g. tell the difference between 1, "1" and "2\b1", which you can't when printing without inspect).
s="test"
s1=:s
p :s.object_id #137448
p s.object_id #77489950
p s1.object_id #137448
I have understand it now. I was assigning a symbol but expecting a string.
You set the value of s1 to be :s, so why would you expect it to return anything different?
If you look at the ruby API for the Object class, you will see both Object#send and Object#method take a symbol as a parameter, so the top example is also totally expected.
I'm trying to write a method that acts as a setter and takes some extra arguments besides the assigned value. Silly example:
class WordGenerator
def []=(letter, position, allowed)
puts "#{letter}#{allowed ? ' now' : ' no longer'} allowed at #{position}"
end
def allow=(letter, position, allowed)
# ...
end
end
Writing it as an indexer works and I can call it like this:
gen = WordGenerator.new
gen['a', 1] = true
# or explicitly:
gen.[]=('a', 1, true)
But when I try any of the following, the interpreter complains:
gen.allow('a', 1) = false # syntax error
gen.allow=('a', 1, false) # syntax error
Why won't this work, am I missing the obvious?
It doesn't work because the parser doesn't allow it. An equals sign is allowed in expressions of the form identifier = expression, expression.identifier = expression (where identifier is \w+), expression[arguments] = expression and expression.[]= arguments and as part of a string or symbol or character literal (?=). That's it.
gen.send(:allow=, 'a', 1, false) would work, but at that point you could as well just give the method a name that doesn't include a =.
I have come across this and decided to pass my arguments as an array or hash.
E.g.:
def allow=(arguments)
puts arguments[:letter]
puts arguments[:position]
puts arguments[:allowed]
end
object.allow={:letter=>'A',:position=>3,:allowed=>true}