Why have a Symbol class?

ruby-talk
1

Hi

As far as I understand Symbols are interned Strings. Why have a different
Symbol class? Any advantages?

Regards,
Rohit

2

rolo wrote:

Hi

As far as I understand Symbols are interned Strings. Why have a different
Symbol class? Any advantages?

I would say it’s a matter of efficiency in time and space, and maybe
a small psychological gain.

Note that:

  1. Symbols are immutable
  2. Only one instance of a given Symbol ever exists
  3. I think they’re stored specially, but I’m not sure of
    the details

I had a fourth point, but I lost it. :slight_smile:

Hal

3

It is for efficiency. A Symbol is just an entry in the symbol table;
it’s hash value is the same as its object id:

irb(main):001:0> :foo.id
=> 3979534
irb(main):002:0> :foo.hash
=> 3979534

Compare this to a String, where the hash value is computed based on the
String’s value:

irb(main):003:0> “foo”.id
=> 537781650
irb(main):004:0> “foo”.hash
=> 876516207

The result is that hash operations with Symbols are much faster:

irb(main):005:0> require ‘benchmark’
=> true
irb(main):006:0> puts Benchmark.measure {
irb(main):007:1* h = {}; 1000000.times { h[:foo] = 1 }
irb(main):008:1> }
0.960000 0.010000 0.970000 ( 0.975577)
=> nil
irb(main):009:0> puts Benchmark.measure {
irb(main):010:1* h = {}; 1000000.times { h[“foo”] = 1 }
irb(main):011:1> }
2.410000 0.000000 2.410000 ( 2.427366)
=> nil

Paul

···

On Tue, May 25, 2004 at 01:01:25AM +0900, rolo wrote:

Hi

As far as I understand Symbols are interned Strings. Why have a different
Symbol class? Any advantages?

4

I am having a small dillema. In a program I and a friend are writing I am
proposing to have a Singleton Error/Status object that is updated with
error/status information. For example (this code is nont tested and it is
just a conceptual look):

class StatusSingleton
def setStatus( returnCode , message , obj=nil )
@returnCode = returnCode
@message = message
@obj = obj
end

def getLastReturnCode
	return @returnCode
end

def getLastMessage
	return @message
end

end

class MyObj
def setTrue
#A Big Error Occurs
StatusSingleton.setStatus( “0x0080” , “Could not set true” );
end
end

m = MyObj.new();
if( !m.setTrue() ) then
MyTkTextFieldWidget.setText( StatusSingleton.getLastMessage() )
end

Is my StatusSinglton overkill? I am trying to consolidate error information
into one class. What do you think?

Thanks,

Zach

···

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.684 / Virus Database: 446 - Release Date: 5/13/2004

5

Hello –

“Zach Dennis” zdennis@mktec.com writes:

I am having a small dillema. In a program I and a friend are writing I am
proposing to have a Singleton Error/Status object that is updated with
error/status information. For example (this code is nont tested and it is
just a conceptual look):

class StatusSingleton
def setStatus( returnCode , message , obj=nil )
@returnCode = returnCode
@message = message
@obj = obj
end

def getLastReturnCode
return @returnCode
end

A quick hint: rather than use methods that start with “get” and “set”
and just return instance variables, use the attr_* family of methods
instead.

def getLastMessage
return @message
end
end

class MyObj
def setTrue
#A Big Error Occurs
StatusSingleton.setStatus( “0x0080” , “Could not set true” );
end
end

m = MyObj.new();
if( !m.setTrue() ) then
MyTkTextFieldWidget.setText( StatusSingleton.getLastMessage() )
end

Is my StatusSinglton overkill? I am trying to consolidate error information
into one class. What do you think?

Another idea might be just to create your own Exception class:

class SomeException < Exception; end

and then raise and rescue accordingly:

begin
m = MyObject.new
# do stuff that raises a SomeException on error
rescue SomeException => e
MyTkTextFieldWidget.set_text(e.message)
end

But there may be something that this doesn’t give you that I’m not
taking into account.

David

···

–
David A. Black
dblack@wobblini.net

6

“Zach Dennis” zdennis@mktec.com writes:

Is my StatusSingleton overkill? I am trying to consolidate error information
into one class. What do you think?

This reminds me of errno in C. You’ll find your program becomes

line_of_program
if error() {
handle it
}
another_line
if error() {
handle it
}
third_line
.
.
.

As David said, you may find Exceptions help to keep your code cleaner.
See the PickAxe chapter on them.

Cheers

Dick ( who spent this week writing modperl auth handlers to hook DAV
to NetWare and really wishes Perl had built-in exceptions).

7

Let me better define my Status object. It would be used to handle displaying
messages to the user in a universal format in a GUI instead of having error
that should be reported to the user going like:

if( error = type1 ) then
MyFrame.myTextField.text = “error of type one. you can’t do that.”
elsif( error = type2 )then
MyFrame.myOthrTextField.text =“error of type two. you can’t do that.”
elsif
etc…
end

I am suggeting to use a Singleton Status object handle this so you could jut
say:

if( error ) then
UIStatus.setErrorCode( 1 );
UIStatus.setMessage( “error here” );
elsif( warning ) then
UIStatus.setErrorCode( 2 );
UIStatus.seMessage( “this is a warning…don’t do that!” );
end

The prototype for this is in Ruby, the actual program is in a scripting
language that doesn’t have exceptions, Flash ActionScript.

I have been reading and rereadin the Design Patterns book and the
Refactoring book published by Addison Wesley and I am trying to properly
patterns where they “make sense”. Does my definition of the staus object fit
the need for a Singleton?

I am thinking yes, but looking for more input. Thanks for responding.

Zach

···

-----Original Message-----
From: Dick Davies [mailto:rasputnik@hellooperator.net]
Sent: Wednesday, May 26, 2004 3:53 PM
To: ruby-talk ML
Subject: Re: Design Question

“Zach Dennis” zdennis@mktec.com writes:

Is my StatusSingleton overkill? I am trying to consolidate error
information
into one class. What do you think?

This reminds me of errno in C. You’ll find your program becomes

line_of_program
if error() {
handle it
}
another_line
if error() {
handle it
}
third_line
…
…
…

As David said, you may find Exceptions help to keep your code cleaner.
See the PickAxe chapter on them.

Cheers

Dick ( who spent this week writing modperl auth handlers to hook DAV
to NetWare and really wishes Perl had built-in exceptions).

Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.684 / Virus Database: 446 - Release Date: 5/13/2004

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.684 / Virus Database: 446 - Release Date: 5/13/2004

8

The way i look at what you wanna do, is that you wanna inform the user
that ‘something’ happened. This is more general than what you
describe. I would probably solve this with something related to
Observer-Observable. I would define an ‘EventManager’, which would be
a Singleton. (there should be only 1 EventManager, and it should be
accessible from anywhere) An object that wants to be notified of a
certain ‘Event’, should subscribe itself for those events in the
EventManager. Every time a certain Event happens, the object that
causes the Event, should ‘fire’ the Event with the EventManager and
the EventManager will notify all objects that subscribed for this
Event.

In your case… if an error happens somewhere, then the EventManager
should be warned about it and the Eventmanager would then notify the
Textfield (or every object that is interested in that particular
error) that has to show the error.

(Something i like in Ruby, is that an object that wants to be
registered for a certain event in the eventmanager, can actually just
‘give’ the eventmanager the code that should be executed when the
event is triggered as an extra parameter in the ‘subscribe’-call. I
wonder whether there are people who use something like this.)

The difference with your StatusObject is that this is more general,
you allow any kind of object that is interested in the event to
register itself for it. Also, the EventManager doesn’t have to know
anything about the objects that want to be notified and in this way
you won’t create any dependencies in your ‘domain’ on the ‘GUI’.

In your case, you would probably have an ‘ErrorEvent’ which contains
the number of the error and the description of the error. Maybe also a
(probably Singleton) class that would build the ErrorEvents given an
error number. Then the EventManager would call something like
“triggered_error(myErrorEvent)” on the objects that subscribed for
ErrorEvents in the EventManager.

Ruben

···

At Thu, 27 May 2004 05:12:33 +0900, Zach Dennis wrote:

Let me better define my Status object. It would be used to handle displaying
messages to the user in a universal format in a GUI instead of having error
that should be reported to the user going like:
[snip]
I have been reading and rereadin the Design Patterns book and the
Refactoring book published by Addison Wesley and I am trying to properly
patterns where they “make sense”. Does my definition of the staus object fit
the need for a Singleton?

I am thinking yes, but looking for more input. Thanks for responding.