I wonder what are the advantages of using symbols over constants. For
example: I want to define representation of SQL comparison operators. If
I use constants - I have to define them, but I don’t have to do explicit
check when using them (because exception will be raised on non-existing
constant). It is also easy to see which operators are defined when
looking at the source code. Another advantage - constants have
namespaces: they can be defined in the class scope. If I use symbols - I
don’t have to define them, but I need to verify whether the symbol is
valid. I have also to write additional documentation to indicate valid
Symbols for operators.
I find kind of general tendency on this group to recommend using symbols
rather then constants. From what I wrote above I’d rather use constants.
Could you please explain me why should I use symbols? Am I missing some
important symbols advantage?
···
–
Marek Janukowicz
One advantage is that symbols are faster than constants.
Regarding the namespace issue, it may be ok to ask yourself
if it really is needed. It may be that if an invalid symbol
is passed, then it just falls off the end of some if/else or case
statement and throws an error.
If, on the other hand you can’t do without the name space, create
a hash with the valid symbols as the key, and use #has_key?
to validate the symbol.
···
On Sunday, 1 June 2003 at 22:00:23 +0900, Marek Janukowicz wrote:
I wonder what are the advantages of using symbols over constants. For
example: I want to define representation of SQL comparison operators. If
I use constants - I have to define them, but I don’t have to do explicit
check when using them (because exception will be raised on non-existing
constant). It is also easy to see which operators are defined when
looking at the source code. Another advantage - constants have
namespaces: they can be defined in the class scope. If I use symbols - I
don’t have to define them, but I need to verify whether the symbol is
valid. I have also to write additional documentation to indicate valid
Symbols for operators.
I find kind of general tendency on this group to recommend using symbols
rather then constants. From what I wrote above I’d rather use constants.
Could you please explain me why should I use symbols? Am I missing some
important symbols advantage?
–
Jim Freeze
Good day to avoid cops. Crawl to school.
Marek Janukowicz wrote:
I wonder what are the advantages of using symbols over constants. For
example: I want to define representation of SQL comparison operators. If
I use constants - I have to define them, but I don’t have to do explicit
check when using them (because exception will be raised on non-existing
constant). It is also easy to see which operators are defined when
looking at the source code. Another advantage - constants have
namespaces: they can be defined in the class scope. If I use symbols - I
don’t have to define them, but I need to verify whether the symbol is
valid. I have also to write additional documentation to indicate valid
Symbols for operators.
I find kind of general tendency on this group to recommend using symbols
rather then constants. From what I wrote above I’d rather use constants.
Could you please explain me why should I use symbols? Am I missing some
important symbols advantage?
One advantage of symbols is that they know how to print themselves, but
you can of course get this advantage with constants that refer to symbols:
UP = :up
DOWN = :down
x = UP
puts “You are going #{x}”
Another advantage with constants is that, if you want to change the
value, there’s only one spot in the code to change and you don’t break
the API.
One of my concerns with symbols is they spring into exsistence on their own,
ie.
def foo(op)
case op
when :Bar
puts “Bar”
else
puts “a bug!”
end
end
foo(:bar)
···
–
Regards,
JJ
Be Kind, Be Careful, Be Yourself
on 6/1/03 9:51 AM, Jim Freeze at jim@freeze.org wrote:
On Sunday, 1 June 2003 at 22:00:23 +0900, Marek Janukowicz wrote:
I wonder what are the advantages of using symbols over constants. For
example: I want to define representation of SQL comparison operators. If
I use constants - I have to define them, but I don’t have to do explicit
check when using them (because exception will be raised on non-existing
constant). It is also easy to see which operators are defined when
looking at the source code. Another advantage - constants have
namespaces: they can be defined in the class scope. If I use symbols - I
don’t have to define them, but I need to verify whether the symbol is
valid. I have also to write additional documentation to indicate valid
Symbols for operators.
I find kind of general tendency on this group to recommend using symbols
rather then constants. From what I wrote above I’d rather use constants.
Could you please explain me why should I use symbols? Am I missing some
important symbols advantage?
One advantage is that symbols are faster than constants.
Regarding the namespace issue, it may be ok to ask yourself
if it really is needed. It may be that if an invalid symbol
is passed, then it just falls off the end of some if/else or case
statement and throws an error.
If, on the other hand you can’t do without the name space, create
a hash with the valid symbols as the key, and use #has_key?
to validate the symbol.
Well, yes … but I imagine that in the cases we are talking about the
actual value of the constant is irrelevant. In fact, if I were to use
constants, I would consider doing …
UP = Object.new
DOWN = Object.new
Now I can’t accidently use :up or :down in my code. I must use the
constant.
Since the value is unimportant, changing the value is unlikely.
However, it is possible that I later decide the constants should be
named TOP and BOTTOM instead of UP and DOWN. And this is a problem for
both symbols and constants equally.
···
On Sun, 2003-06-01 at 11:21, Joel VanderWerf wrote:
One advantage of symbols is that they know how to print themselves, but
you can of course get this advantage with constants that refer to symbols:
UP = :up
DOWN = :down
x = UP
puts “You are going #{x}”
Another advantage with constants is that, if you want to change the
value, there’s only one spot in the code to change and you don’t break
the API.
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)
I wonder what are the advantages of using symbols over constants. For
example: I want to define representation of SQL comparison operators. If
I use constants - I have to define them, but I don’t have to do explicit
check when using them (because exception will be raised on non-existing
constant). It is also easy to see which operators are defined when
looking at the source code. Another advantage - constants have
namespaces: they can be defined in the class scope. If I use symbols - I
don’t have to define them, but I need to verify whether the symbol is
valid. I have also to write additional documentation to indicate valid
Symbols for operators.
I find kind of general tendency on this group to recommend using symbols
rather then constants. From what I wrote above I’d rather use constants.
Could you please explain me why should I use symbols? Am I missing some
important symbols advantage?
One advantage is that symbols are faster than constants.
I don’t use constants too much, so speed is not a problem.
Regarding the namespace issue, it may be ok to ask yourself
if it really is needed.
Yes, I think so (in this particular case, of course). I have Qualifier
class representing “attribute operator value” and placing the operator
constants in this class seems good to me (frmo the design point of
view).
It may be that if an invalid symbol
is passed, then it just falls off the end of some if/else or case
statement and throws an error.
If, on the other hand you can’t do without the name space, create
a hash with the valid symbols as the key, and use #has_key?
to validate the symbol.
I’re right, but like I wrote before: when using constants I don’t have
to do explicit validation - undefined constants will raise an exception.
···
On Sun, 1 Jun 2003 22:51:41 +0900, Jim Freeze wrote:
–
Marek Janukowicz
I see your point. If the code was supposed to be
:bar instead of :Bar, then that would be a bug that
would not have happened if an enum were used.
I’m not saying you should never use enums, but
I may not choose to use enums, even in this case.
Instead, I would write a unit test that ensured correct
code.
I suppose deep down, this goes back to a static
vs dynamic typing issue. No?
···
On Monday, 2 June 2003 at 0:13:21 +0900, John Johnson wrote:
One of my concerns with symbols is they spring into exsistence on their own,
ie.
def foo(op)
case op
when :Bar
puts “Bar”
else
puts “a bug!”
end
end
foo(:bar)
–
Jim Freeze
Every successful person has had failures but repeated failure is no
guarantee of eventual success.
def foo(op)
case op
when :Bar
puts “Bar”
else
fail “Unrecognized symbol :#{op}”
end
end
foo(:Bar)
foo(:bar)
Voila! It is now a non-issue.
Cheers,
Julian
···
On Mon, 02 Jun 2003 00:13:21 +0900, John Johnson wrote:
One of my concerns with symbols is they spring into exsistence on their own,
ie.
def foo(op)
case op
when :Bar
puts “Bar”
else
puts “a bug!”
end
end
foo(:bar)
One advantage of symbols is that they know how to print themselves, but
you can of course get this advantage with constants that refer to symbols:
UP = :up
DOWN = :down
x = UP
puts “You are going #{x}”
Another advantage with constants is that, if you want to change the
value, there’s only one spot in the code to change and you don’t break
the API.
Well, yes … but I imagine that in the cases we are talking about the
actual value of the constant is irrelevant. In fact, if I were to use
constants, I would consider doing …
UP = Object.new
DOWN = Object.new
Isn’t it better to do eg.
UP = 1
DOWN = 2
This way you don’t create new (and in fact unnecessary) objects.
Now I can’t accidently use :up or :down in my code. I must use the
constant.
Since the value is unimportant, changing the value is unlikely.
However, it is possible that I later decide the constants should be
named TOP and BOTTOM instead of UP and DOWN. And this is a problem for
both symbols and constants equally.
I read what you and the others wrote and I am now even more convinced I
should use constants in my program.
Thanks for all answers
···
On Mon, 2 Jun 2003 10:23:16 +0900, Jim Weirich wrote:
Marek Janukowicz
I have also found fake classes to be a useful way of doing this:
class Myclass
class UP; end
class DOWN; end
def foo(option)
# useful stuff
end
end
a = Myclass.new
a.foo(Myclass::UP)
Just another option…
Regards,
Brian.
···
On Mon, Jun 02, 2003 at 10:23:16AM +0900, Jim Weirich wrote:
Well, yes … but I imagine that in the cases we are talking about the
actual value of the constant is irrelevant. In fact, if I were to use
constants, I would consider doing …
UP = Object.new
DOWN = Object.new
Now I can’t accidently use :up or :down in my code. I must use the
constant.
Dnia nie 1. czerwca 2003 21:06, Jim Freeze napisa³:
I suppose deep down, this goes back to a static
vs dynamic typing issue. No?
Not quite. If a dynamically typed language is statically scoped and doesn’t
default all unknown identifiers to some scope (e.g. global scope like Scheme
or instance methods on self like Ruby) but reports them as errors, there is a
difference between named constants and symbols in error reporting.
But most dynamically typed languages do default to some scope. (My language
will not.)
···
–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/