Can someone help me grasp symbols a bit better? Pickaxe says: "The construct :artist is an expression that returns a Symbol object> corresponding to artist. You can think of :artist*name* of the variable > artist, while plain artist is the *value* of the variable."Ok, Got it. But what''s the point? In what context do I use artist, and when do I use :artist? Thanks! _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Monday 13 June 2005 04:04, Mike Payson wrote:> Can someone help me grasp symbols a bit better? Pickaxe says: > > "The construct :artist is an expression that returns a Symbol object > > > corresponding to artist. You can think of :artist*name* of the variable > > artist, while plain artist is the *value* of the variable." > > Ok, Got it. But what''s the point? In what context do I use artist, and when > do I use :artist?If you are familiar with X11 atoms - a symbol (or intern) is same as atom. There''s only one instance of symbol per ruby process. So when you use :stuff it resolves to one single object anywhere in your ruby program. -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Monday 13 June 2005 04:51, Mike Payson wrote:>> There''s only one instance of symbol per ruby process. > > > > So when you use :stuff it resolves to one single object anywhere in your > > ruby > > program. > > Sorry, I''m not familiar with X11 atoms, so that doesn''t help. I assume that > there is a difference between symbols and globals, correct? Can you give me > a brief code snippet or IRB output that demonstrates the difference?Not quite. Globals are just variables, but _you cannot assign to symbol_. irb(main):001:0> $my = true => true irb(main):002:0> :my = 123 SyntaxError: compile error (irb):2: syntax error :my = 123 ^ from (irb):2 You can assign other variable a symbol however, and whenever this assignment is made all variables will point to the same object irb(main):001:0> $my = :test => :test irb(main):002:0> module Test irb(main):003:1> var = :test irb(main):004:1> puts $my == var irb(main):005:1> end true => nil irb(main):006:0> class Some irb(main):007:1> attr :local irb(main):008:1> def test irb(main):009:2> puts $my == @local irb(main):010:2> end irb(main):011:1> def initialize irb(main):012:2> @local = :test irb(main):013:2> end irb(main):014:1> end => nil irb(main):015:0> Some.new.test true => nil (A _global may change_ but a _symbol can not change_ during the run of ruby interpreter) If you reference non-existing global you get an error. If you reference non-existing symbol it will be created in symbol table and next time you ask for it the same instance will be returned. Hope this highlights the differences. -- Best regards, Stanislav Karchebny Skype name: berkus Get skype for free from www.skype.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
A symbol is nothing more then a "unique" variable. Symbols are mostly
used as identifiers, for example in a hash:
instead of:
a =
{"username"=>"joe","password"=>"secret"}
you can write
b = {:username => "joe", :password=>"secret"}
Remember: they are not the same!! (so a[:username] would return nil as
would b["username"]). But this is only one of the many uses. Symbols
are
basically just a representation of an identifier (as far as I understand
them :) ).
Hope this clears it up a bit.
Flurin
Mike Payson wrote:
> Can someone help me grasp symbols a bit better? Pickaxe says:
>
> "The construct |:artist| is an expression that returns a |Symbol|
> object corresponding to |artist|. You can think of |:artist|/name/
> of the variable |artist|, while plain |artist| is the /value/ of
> the variable."
>
>
> Ok, Got it. But what''s the point? In what context do I use artist,
and
> when do I use :artist?
>
> Thanks!
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
No, my understanding of before_filter is that "before_filter" just takes a symbol as a parameter. The symbol itself doesn''t say wether it''s a method or something else. However before_filter knows that it _only_ accepts "names" of methods. Therefore it tries to find the method which is named like the symbol. Flurin Mike Payson wrote:> On 6/13/05, *Flurin Egger* <f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org>> wrote: > > A symbol is nothing more then a "unique" variable. Symbols are mostly > used as identifiers, for example in a hash: > instead of: > > a = {"username"=>"joe","password"=>"secret"} > > you can write > > b = {:username => "joe", :password=>"secret"} > > Remember: they are not the same!! (so a[:username] would return nil as > would b["username"]). But this is only one of the many uses. > Symbols are > basically just a representation of an identifier (as far as I > understand > them :) ). > > Hope this clears it up a bit. > > > That does help. In the context of hashes, this makes perfect sense. > I''m still a bit confused by them in other contexts, though. For > example, the beta book has the following: > before_filter :authorize, except => :login > > Now, I understand what this is doing, just not quite how it''s doing > it. Authorize is a method, and this basically passes it as a variable > to another method. Are methods automatically given matching symbols > for cases just like these, or is there some behind the scenes magic > that I''m missing? > > > > > > >
Ok, I think I''ve got it. Symbols are simply globally unique identifiers. Since you can''t actually give them a value, they are closer to constants then globals, but still not quite the same. If I understand them correctly, they are really just a convenience, and if you wanted, you could write Ruby all day without using them, though they probably make your programs cleaner & less bug-prone. Does that sound about right? On 6/13/05, Flurin Egger <f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org> wrote:> > No, my understanding of before_filter is that "before_filter" just takes > a symbol as a parameter. The symbol itself doesn''t say wether it''s a > method or something else. However before_filter knows that it _only_ > accepts "names" of methods. Therefore it tries to find the method which > is named like the symbol. > > Flurin > > Mike Payson wrote: > > > On 6/13/05, *Flurin Egger* <f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org > > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org>> wrote: > > > > A symbol is nothing more then a "unique" variable. Symbols are mostly > > used as identifiers, for example in a hash: > > instead of: > > > > a = {"username"=>"joe","password"=>"secret"} > > > > you can write > > > > b = {:username => "joe", :password=>"secret"} > > > > Remember: they are not the same!! (so a[:username] would return nil as > > would b["username"]). But this is only one of the many uses. > > Symbols are > > basically just a representation of an identifier (as far as I > > understand > > them :) ). > > > > Hope this clears it up a bit. > > > > > > That does help. In the context of hashes, this makes perfect sense. > > I''m still a bit confused by them in other contexts, though. For > > example, the beta book has the following: > > before_filter :authorize, except => :login > > > > Now, I understand what this is doing, just not quite how it''s doing > > it. Authorize is a method, and this basically passes it as a variable > > to another method. Are methods automatically given matching symbols > > for cases just like these, or is there some behind the scenes magic > > that I''m missing? > > > > > > > > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Jup that''s exactly what they are about. Flurin Mike Payson wrote:> Ok, I think I''ve got it. Symbols are simply globally unique > identifiers. Since you can''t actually give them a value, they are > closer to constants then globals, but still not quite the same. If I > understand them correctly, they are really just a convenience, and if > you wanted, you could write Ruby all day without using them, though > they probably make your programs cleaner & less bug-prone. Does that > sound about right? > > On 6/13/05, *Flurin Egger* <f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org>> wrote: > > No, my understanding of before_filter is that "before_filter" just > takes > a symbol as a parameter. The symbol itself doesn''t say wether it''s a > method or something else. However before_filter knows that it _only_ > accepts "names" of methods. Therefore it tries to find the method > which > is named like the symbol. > > Flurin > > Mike Payson wrote: > > > On 6/13/05, *Flurin Egger* <f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org> > > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org > <mailto:f.egger.mailings-c2BlD8dJSIudKNnQ2JlF7Q@public.gmane.org>>> wrote: > > > > A symbol is nothing more then a "unique" variable. Symbols > are mostly > > used as identifiers, for example in a hash: > > instead of: > > > > a = {"username"=>"joe","password"=>"secret"} > > > > you can write > > > > b = {:username => "joe", :password=>"secret"} > > > > Remember: they are not the same!! (so a[:username] would > return nil as > > would b["username"]). But this is only one of the many uses. > > Symbols are > > basically just a representation of an identifier (as far as I > > understand > > them :) ). > > > > Hope this clears it up a bit. > > > > > > That does help. In the context of hashes, this makes perfect sense. > > I''m still a bit confused by them in other contexts, though. For > > example, the beta book has the following: > > before_filter :authorize, except => :login > > > > Now, I understand what this is doing, just not quite how it''s doing > > it. Authorize is a method, and this basically passes it as a > variable > > to another method. Are methods automatically given matching symbols > > for cases just like these, or is there some behind the scenes magic > > that I''m missing? > > > > > > > > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org <mailto:Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > >------------------------------------------------------------------------ > >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >
I don''t get it. Why would I prefer :username over "username"? In a static language this would make sense - ie. have USERNAME = "username" and work with USERNAME so you get a compile time error if you make a typo, but I don''t see it''s use in Ruby. Coming from .NET I prefer :username just because of what I said and because it looks "safer" to me, but there is no real reason for doing this. Even if you use the string or the symbol, you are exposing yourself to the same danger of making a typo. What am I missing here? Flurin Egger wrote:> A symbol is nothing more then a "unique" variable. Symbols are mostly > used as identifiers, for example in a hash: > instead of: > > a = {"username"=>"joe","password"=>"secret"} > > you can write > > b = {:username => "joe", :password=>"secret"} > > Remember: they are not the same!! (so a[:username] would return nil as > would b["username"]). But this is only one of the many uses. Symbols are > basically just a representation of an identifier (as far as I understand > them :) ). > > Hope this clears it up a bit. > > Flurin > > Mike Payson wrote: > >> Can someone help me grasp symbols a bit better? Pickaxe says: >> >> "The construct |:artist| is an expression that returns a |Symbol| >> object corresponding to |artist|. You can think of |:artist|/name/ >> of the variable |artist|, while plain |artist| is the /value/ of >> the variable." >> >> Ok, Got it. But what''s the point? In what context do I use artist, and >> when do I use :artist? >> >> Thanks! >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Wed, 2005-06-15 at 07:41 +0300, Ioan Bizau jr. wrote:> What am I missing here?Did I not read somewhere that using a symbol is, somehow, more efficient (i.e. - faster)? Howard
On 15/06/2005, at 2:41 PM, Ioan Bizau jr. wrote:> I don''t get it. Why would I prefer :username over "username"? > In a static language this would make sense - ie. have USERNAME = > "username" and work with USERNAME so you get a compile time error if > you make a typo, but I don''t see it''s use in Ruby. > Coming from .NET I prefer :username just because of what I said and > because it looks "safer" to me, but there is no real reason for doing > this. Even if you use the string or the symbol, you are exposing > yourself to the same danger of making a typo. > What am I missing here?A string is a full blown Ruby object instance whereas a symbol is just an identifier (or tag). Symbols give you the equality operator (i.e. :foobar == :foobar) without needing to instantiate string objects and perform a string comparison. If you don''t need the String class''s functionality and are just using the string as an identifier then you probably just need a symbol instead. - tim lucas
On 6/14/05, Tim Lucas <t.lucas-l/qNJNvq70OzaBltdDZI6w@public.gmane.org> wrote:> On 15/06/2005, at 2:41 PM, Ioan Bizau jr. wrote: > > I don''t get it. Why would I prefer :username over "username"? > > In a static language this would make sense - ie. have USERNAME > > "username" and work with USERNAME so you get a compile time error if > > you make a typo, but I don''t see it''s use in Ruby. > > Coming from .NET I prefer :username just because of what I said and > > because it looks "safer" to me, but there is no real reason for doing > > this. Even if you use the string or the symbol, you are exposing > > yourself to the same danger of making a typo. > > What am I missing here? > > A string is a full blown Ruby object instance whereas a symbol is just > an identifier (or tag). > > Symbols give you the equality operator (i.e. :foobar == :foobar) > without needing to instantiate string objects and perform a string > comparison. > > If you don''t need the String class''s functionality and are just using > the string as an identifier then you probably just need a symbol > instead.Thank you. That gives me the last piece that I need to fully make sense of symbols. They are now perfectly clear.
On Wednesday 15 June 2005 01:36 am, Tim Lucas wrote:> On 15/06/2005, at 2:41 PM, Ioan Bizau jr. wrote: > > A string is a full blown Ruby object instance whereas a symbol is just > an identifier (or tag).Say what? Symbols are as real an object as every other. The primary difference between Symbol and String are that Symbol is an imutable object, where as String is mutable.
I think this is a much bigger difference than mutability:
irb(main):001:0> a = "test"
=> "test"
irb(main):002:0> b = "test"
=> "test"
irb(main):003:0> c = :test
=> :test
irb(main):004:0> d = :test
=> :test
irb(main):005:0> a.object_id == b.object_id
=> false
irb(main):006:0> c.object_id == d.object_id
=> true
^^^^-------------------- All identical symbols call the same
place in memory
Lucas Carlson
http://tech.rufy.com/
On Jun 15, 2005, at 3:17 AM, David Corbin wrote:
> On Wednesday 15 June 2005 01:36 am, Tim Lucas wrote:
>
>> On 15/06/2005, at 2:41 PM, Ioan Bizau jr. wrote:
>>
>> A string is a full blown Ruby object instance whereas a symbol is
>> just
>> an identifier (or tag).
>>
>
> Say what? Symbols are as real an object as every other. The primary
> difference between Symbol and String are that Symbol is an imutable
> object,
> where as String is mutable.
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
On Wednesday 15 June 2005 06:28 am, Lucas Carlson wrote:> I think this is a much bigger difference than mutability: > > irb(main):001:0> a = "test" > => "test" > irb(main):002:0> b = "test" > => "test" > irb(main):003:0> c = :test > => :test > irb(main):004:0> d = :test > => :test > irb(main):005:0> a.object_id == b.object_id > => false > irb(main):006:0> c.object_id == d.object_id > => true > ^^^^-------------------- All identical symbols call the same > place in memory >That is correct, but to me it''s just a side effect of the immutability issue. Strings literals can''t do that (like the can in other languages like Java), because their mutable. There certainly may be circumstances where this is relevant, but I''m big believer in not doing premature optimazation, which is what worry about this is. David
On 15/06/2005, at 8:17 PM, David Corbin wrote:> On Wednesday 15 June 2005 01:36 am, Tim Lucas wrote: >> A string is a full blown Ruby object instance whereas a symbol is just >> an identifier (or tag). > > Say what? Symbols are as real an object as every other. The primary > difference between Symbol and String are that Symbol is an imutable > object, > where as String is mutable.Ok my bad. Yes its true that symbols are (optimised) instances of the class Symbol, but the point was more conceptual than implementation. The question was "why use a symbol over a string", where the following advice still holds:> If you don''t need the String class''s functionality and are just using > the string as an identifier then you probably just need a symbol > instead- tim lucas
On 15/06/2005, at 9:50 PM, David Corbin wrote:> On Wednesday 15 June 2005 06:28 am, Lucas Carlson wrote: >> I think this is a much bigger difference than mutability: > > That is correct, but to me it''s just a side effect of the immutability > issue. > Strings literals can''t do that (like the can in other languages like > Java), > because their mutable. > > There certainly may be circumstances where this is relevant, but I''m > big > believer in not doing premature optimazation, which is what worry > about this > is.I don''t think the use of a symbol is a matter of premature optimisation. If you''re only using a String object as a label in your program code then you''re using the wrong tool for the job. If you find a situation where you need to use a String method on a symbol (say, for pattern matching) then just use the symbol''s to_s method. - tim lucas