Advantages of Symbols over constants 
Author Message
 Advantages of Symbols over constants

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



Thu, 17 Nov 2005 20:46:53 GMT  
 Advantages of Symbols over constants

Quote:

> 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.

--
Jim Freeze
----------
Good day to avoid cops.  Crawl to school.



Thu, 17 Nov 2005 21:51:41 GMT  
 Advantages of Symbols over constants
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


Quote:

>> 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.



Thu, 17 Nov 2005 23:13:21 GMT  
 Advantages of Symbols over constants

Quote:

> 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.



Thu, 17 Nov 2005 23:21:02 GMT  
 Advantages of Symbols over constants

Quote:

> 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)

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?

--
Jim Freeze
----------
Every successful person has had failures but repeated failure is no
guarantee of eventual success.



Fri, 18 Nov 2005 03:06:13 GMT  
 Advantages of Symbols over constants
Dnia nie 1. czerwca 2003 21:06, Jim Freeze napisa3:

Quote:
> 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

    ^^     http://qrnik.knm.org.pl/~qrczak/



Fri, 18 Nov 2005 03:51:17 GMT  
 Advantages of Symbols over constants

Quote:

> 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)

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



Fri, 18 Nov 2005 08:04:04 GMT  
 Advantages of Symbols over constants

Quote:

> 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

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.

--

---------------------------------------------------------------------
"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)



Fri, 18 Nov 2005 09:23:16 GMT  
 Advantages of Symbols over constants

Quote:

>> 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.

Quote:
> 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
--
Marek Janukowicz



Sat, 19 Nov 2005 00:57:02 GMT  
 Advantages of Symbols over constants

Quote:

>> 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.

Quote:
>  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).

Quote:
> 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.

--
Marek Janukowicz



Sat, 19 Nov 2005 00:57:03 GMT  
 Advantages of Symbols over constants

Quote:

> 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.

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.



Sat, 19 Nov 2005 02:22:46 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. symbols for global constants

2. mov [edi], constant vs mov [edi+4], constant

3. Usage Constant or other means of noting constants.

4. PGF90-S-0087-Non-constant expression where constant expression required

5. PGF90-S-0087-Non-constant expression where constant expression required

6. named constants vs. literal constants

7. Non-constant expression where constant expression required.

8. Change symbol factory activex for standard symbol factory v1 or v2

9. make-symbol defiencies (how make a direct symbol?)

10. How to get symbol-value from symbol-name

11. PDSE advantages over PDS?

12. Advantages of Smalltalk over Java

 

 
Powered by phpBB® Forum Software