stupid question: Object#name

B

Benny

hi all,

its time for stupid questions again :)

is there a way to get the name of an object, e.g.

test = MyClass.new
test.name #=> "test"

I know we have it for classes (and yes: I could use a subclass instead)

but is there a way to do it with objects?

btw. why didn't matz make Class and Object be the same thing?

kind greetings to all the rubyists.

benny

(btw. I like ruby very much and using it as my primary programing language,
but every now and then when using it I am feeling like a child on another
planet. so the principal of least surprise didnt work for me at all (every
exploration was a big surprise, but a good one ))
 
F

Florian Gross

Benny said:
hi all,
Moin!

is there a way to get the name of an object, e.g.
test = MyClass.new
test.name #=> "test"

No, because Objects don't have names. Variables however do. The
association between an Object to a Variable isn't really something that
is unique.

Here are some samples:

x = 5; (4 + 1).name
x = y = Object.new; x.name, y.name
Object.new.name
I know we have it for classes (and yes: I could use a subclass instead)

It is a bit different with classes, mainly because their names are
constants that are available in the whole application.
but is there a way to do it with objects?

Nope, not really.
btw. why didn't matz make Class and Object be the same thing?

In which context? If he did Ruby would be a prototype-based language
where the only way to build similar Objects is to have a template object
which you clone.

BTW, what are you wanting that .name method for? If it is for debugging
reasons there might be another way of doing it.
kind greetings to all the rubyists.
benny

More regards,
Florian Gross
 
R

Robert Klemme

Benny said:
hi all,

its time for stupid questions again :)

is there a way to get the name of an object, e.g.

test = MyClass.new
test.name #=> "test"

That's not the name of the object but the name of a variable that
references the object. What would you expect to be the name in this case:

test = MyClass.new
t2 = test
# name?
I know we have it for classes (and yes: I could use a subclass instead)

That's a special case. Consider also:
=> true
but is there a way to do it with objects?
No.

btw. why didn't matz make Class and Object be the same thing?

Err... Because they are not the same concept. Object is an instance of
Class (as Class is also, which sometimes confuses people). Object defines
everthing an instance is capable of (ok, together with Kernel, but that
contains mostly methods that one uses as functions). Could be that the
self referenciality confused you - sometimes it's hard to grasp. :)

irb(main):051:0* Class.class
=> Class
irb(main):052:0> Class.ancestors
=> [Class, Module, Object, Kernel]
irb(main):053:0> Object.class
=> Class
irb(main):055:0> Class.ancestors
=> [Class, Module, Object, Kernel]
irb(main):056:0> Object.ancestors
=> [Object, Kernel]
kind greetings to all the rubyists.

Same to you.
(btw. I like ruby very much and using it as my primary programing language,
but every now and then when using it I am feeling like a child on another
planet. so the principal of least surprise didnt work for me at all (every
exploration was a big surprise, but a good one ))

Maybe you should get yourself a book about programming languages concepts
and / or about OO in special. Just an idea.

Kind regards

robert
 
B

Benny

ok after rethinking I have to correct me:
substitute Object#name with Object#names
in my first posting

Florian said:
No, because Objects don't have names. Variables however do. The
association between an Object to a Variable isn't really something that
is unique.
ok, but AFAIK there is no variable class in ruby :)
Here are some samples:
here are some possible implementations (for Object#names)
x = 5; x.names #=> ["x"]
(4 + 1).name #=> nil
x = y = Object.new;
x.names #=> ["x","y"]
y.names #=> ["x","y"]
Object.new.name
#=> nil

I think in the kernel we have symbols attached to object-ids (do we?)
so why not have a method to show us the symbols to a corresponding
object_id?
In which context? If he did Ruby would be a prototype-based language
where the only way to build similar Objects is to have a template object
which you clone.
but I thought we would have some: the class Object (since its a class its
also an object in ruby) or did I get you wrong (I must admit I have no idea
of the formal meaning / definition of »prototype-based language«)
BTW, what are you wanting that .name method for? If it is for debugging
reasons there might be another way of doing it.
you mean Kernel#caller, right? :)
so its simply comfortable if you can use

name = MyClass.new(params)

instead of

name = MyClass.new(name, params)

the last one is doubled effort and if you accidently choose
different names for the object and the content of the name-attribut
you may later on have to remember 2 different names or fix it.
it may also be confusing.

(I like to iterate over all objects of a class and often I need the name of
the object in the iteration to identify the current thing.
in the iteration I like to invoke certain methods, so in the end they are
processed on every object of that class)

More regards,
Florian Gross
dito,

benny
 
R

Robert Klemme

Benny said:
ok after rethinking I have to correct me:
substitute Object#name with Object#names
in my first posting

No good. Benny, I seriously think you should get rid of the idea that
variable identifiers are an object's names.
I think in the kernel we have symbols attached to object-ids (do we?)

Nope. The association between variable names and objects is contained in
the current binding (for local variables, that is). It's a different
story for instance variables.
#<Foo:0x101831c0>

so why not have a method to show us the symbols to a corresponding
object_id?

It's a one way street. You can only walk it in the direction of varible
to instance, not the other way. It's not needed and it would be a total
overhead to manage this at runtime.
but I thought we would have some: the class Object (since its a class its
also an object in ruby) or did I get you wrong (I must admit I have no idea
of the formal meaning / definition of »prototype-based language«)

As I said earlier, you got stuck in the self referentiality. Object is a
class and class in turn is an object, too.
you mean Kernel#caller, right? :)
so its simply comfortable if you can use

name = MyClass.new(params)

instead of

name = MyClass.new(name, params)

the last one is doubled effort and if you accidently choose
different names for the object and the content of the name-attribut
you may later on have to remember 2 different names or fix it.
it may also be confusing.

Of course.
(I like to iterate over all objects of a class and often I need the name of
the object in the iteration to identify the current thing.

No, you don't need the var name for that. You can always do

foo = Foo.new

ObjectSpace.each_object( Foo ) do |obj|
if obj.equal? foo
puts "found it"
else
puts "other instance"
end
end

http://www.ruby-doc.org/core/classes/Object.html#M000899

in the iteration I like to invoke certain methods, so in the end they are
processed on every object of that class)

You're making me curios why you need that and what you do.

Kind regards

robert
 
B

Benny

Robert said:
That's not the name of the object but the name of a variable that
references the object. What would you expect to be the name in this case:

test = MyClass.new
t2 = test
# name?
ok, see my other posting:

"substitute Object#name with Object#names
in my first posting"
so it would be

test = MyClass.new
t2 = test
t2.names #=> ["t2", "test"]
test.names #=> ["t2", "test"]

That's a special case.
yes I know: class names are constants
Consider also:

=> true
I dont get you here :(
I think as names of classes a constants and names of variables are symbols
they are a entirely different thing (in the way ruby handles it)
I only made the statement with the subclass to get no such answer from the
list ("use a subclass if you need names"). and as I didnt want to use
constants I also didnt want to use a subclass :)
from my other posting:

"I think in the kernel we have symbols attached to object-ids (do we?)
so why not have a method to show us the symbols to a corresponding
object_id?"
Err... Because they are not the same concept.
if they behave mostly the same way in ruby
it might be reflected behind the scenes.
are the differences in the abilities of Object and
Class so big that they legitimate hard distinction in the
interpreter? or are we loosing something if Object and Class
is based on the same fundamentals apart from syntactical restrictions
and the separated name spaces (constants vs. symbols)?
Object is an instance of
Class (as Class is also, which sometimes confuses people). Object defines
everthing an instance is capable of (ok, together with Kernel, but that
contains mostly methods that one uses as functions). Could be that the
self referenciality confused you - sometimes it's hard to grasp. :)

I think its not confusing me on the contrary: I even vote for narrowing the
differences.

Maybe you should get yourself a book about programming languages concepts
and / or about OO in special. Just an idea.
I read the whole pragmatic programmer (1st ver.) and "Programmieren mit
Ruby" /Röhrl/Schmiedl/Wyss several times and I thought it would be
sufficient. but perhaps you have a good recommendation for a pure OO book.

kind regards,

benny
 
F

Florian Gross

Benny said:
ok after rethinking I have to correct me:
substitute Object#name with Object#names
in my first posting

But would that really help you?

Imagine this:

def foo
var = 5
end

def bar
var = 6
end

Now you have two vars with the same name, but different values.
ok, but AFAIK there is no variable class in ruby :)

I have done an extension that boxes Variables into Objects, it uses some
deep trickery to accomplish that. I've attached it and a dependency of it.
I think in the kernel we have symbols attached to object-ids (do we?)
so why not have a method to show us the symbols to a corresponding
object_id?

The mapping is really [context, variable] => object -- it isn't even
designed to go from object => variable (that would be slow, because
you'd need to iterate over the variable table) and as I already
mentioned above you can have multiple variables with the same name in
different contexts.
but I thought we would have some: the class Object (since its a class its
also an object in ruby) or did I get you wrong (I must admit I have no idea
of the formal meaning / definition of »prototype-based language«)

Object itself is an instance of Class.
Classes are instances of Class.
Objects are instances of Object.
Class itself is an instance of Class.
Class is inherited from Object.

Class.new returns a Class. Class.new.new returns an instance of a new Class.
you mean Kernel#caller, right? :)
so its simply comfortable if you can use

name = MyClass.new(params)

instead of

name = MyClass.new(name, params)

the last one is doubled effort and if you accidently choose
different names for the object and the content of the name-attribut
you may later on have to remember 2 different names or fix it.
it may also be confusing.

(I like to iterate over all objects of a class and often I need the name of
the object in the iteration to identify the current thing.
in the iteration I like to invoke certain methods, so in the end they are
processed on every object of that class)

I was referring to my variable.rb. With it you could do the following
(but don't do it in this case, it's unnecessarily complicated and will
likely confuse you and others):

class MyClass
attr_reader :text

def initialize(name_var, params)
@text = name_var.value
@params = params
name_var.value = self
end
end

obj = "old text"
MyClass.new(Variable[:eek:bj], ["some", "params"])
obj.text # => "old text"
dito,
benny

More dito,
Florian Gross


begin
require 'simplecc'
rescue LoadError
def Continuation.create(*args, &block)
cc = nil; result = callcc {|c| cc = c; block.call(cc) if block and args.empty?}
result ||= args
return *[cc, *result]
end
end

# This method returns the binding of the method that called your
# method. It will raise an Exception when you're not inside a method.
#
# It's used like this:
# def inc_counter
# Binding.of_caller do |binding|
# eval("counter += 1", binding)
# end
# end
# counter = 0
# 2.times { inc_counter }
# counter # => 2
#
# You will have to put the whole rest of your method into the
# block that you pass into this method. If you don't do this
# an Exception will be raised. Because of the way that this is
# implemented it has to be done this way. If you don't do it
# like this it will raise an Exception.
def Binding.of_caller(&block)
old_critical = Thread.critical
Thread.critical = true
count = 0
cc, result, error = Continuation.create(nil, nil)
error.call if error

tracer = lambda do |*args|
type, context = args[0], args[4]
if type == "return"
count += 1
# First this method and then calling one will return --
# the trace event of the second event gets the context
# of the method which called the method that called this
# method.
if count == 2
# It would be nice if we could restore the trace_func
# that was set before we swapped in our own one, but
# this is impossible without overloading set_trace_func
# in current Ruby.
set_trace_func(nil)
cc.call(eval("binding", context), nil)
end
elsif type != "line"
set_trace_func(nil)
error_msg = "Binding.of_caller used in non-method context or " +
"trailing statements of method using it aren't in the block."
cc.call(nil, lambda { raise(ArgumentError, error_msg ) })
end
end

unless result
set_trace_func(tracer)
return nil
else
Thread.critical = old_critical
yield result
end
end

require 'binding_of_caller'

class Variable
def self.new(name, context = nil)
return super(name, context) unless context.nil?
Binding.of_caller do |context|
super(name, context)
end
end
class << self; alias :[] :new; end

attr_reader :context, :name

def initialize(name, context)
unless /^[\w_][\w\d_]*$/.match(name.to_s)
raise(NameError, "Illegal variable name: #{name.inspect}")
end

@name, @context = name, context
@setter = lambda do |value|
eval "#{@name} = ObjectSpace._id2ref(#{value.id})", context
end
exists = lambda do
eval "local_variables.include?(#{@name.to_s.inspect})", context
end
@getter = lambda do
eval("#{@name}", context) if exists.call
end
end

def []=(value); @setter.call(value); end
def []; @getter.call; end
alias :value= :[]=
alias :value :[]

def inspect
"Variable[#{@name.inspect}, #{@context.inspect}]"
end
end
 
F

Florian Gross

Benny said:
if they behave mostly the same way in ruby
it might be reflected behind the scenes.
are the differences in the abilities of Object and
Class so big that they legitimate hard distinction in the
interpreter? or are we loosing something if Object and Class
is based on the same fundamentals apart from syntactical restrictions
and the separated name spaces (constants vs. symbols)?

It is indeed possible to store Classes in regular variables, because
they are just regular objects:

foo = String
foo_obj = foo.new # => ""
foo_obj.class == foo # => true
foo_obj.class == String # => true

bar = Class.new(String)
bar_obj = bar.new # => ""
bar_obj.class == bar # => true
kind regards,
benny

More regards,
Florian Gross
 
R

Robert Klemme

Benny said:
Robert said:
That's not the name of the object but the name of a variable that
references the object. What would you expect to be the name in this case:

test = MyClass.new
t2 = test
# name?
ok, see my other posting:

"substitute Object#name with Object#names
in my first posting"
so it would be

test = MyClass.new
t2 = test
t2.names #=> ["t2", "test"]
test.names #=> ["t2", "test"]

No good either.
yes I know: class names are constants

I dont get you here :(

The message is "even an ordinary variable can reference a class instance".
I think as names of classes a constants and names of variables are symbols
they are a entirely different thing (in the way ruby handles it)

There's much less difference than you think. Both are references and with
respect to that they are totally interchangable. The one major difference
is that constants can only be assigned once - more precisely, Ruby warns
you if you try more assignments, but it doesn't prevent them:
(irb):2: warning: already initialized constant Foo
=> # said:
I only made the statement with the subclass to get no such answer from the
list ("use a subclass if you need names"). and as I didnt want to use
constants I also didnt want to use a subclass :)

from my other posting:

"I think in the kernel we have symbols attached to object-ids (do we?)
so why not have a method to show us the symbols to a corresponding
object_id?"

No, as we said already: it's a one way street. And it's not "in the
kernel" but in the current binding.
if they behave mostly the same way in ruby
it might be reflected behind the scenes.

They don't. Instances of Object and Class are totally differnt. Regard
this
NoMethodError: undefined method `new' for #<Object:0x10185b30>
from (irb):6

You can create instances of a class but not of an object.
are the differences in the abilities of Object and
Class so big that they legitimate hard distinction in the
interpreter?

Definitely! See above.
or are we loosing something if Object and Class
is based on the same fundamentals apart from syntactical restrictions
and the separated name spaces (constants vs. symbols)?


I think its not confusing me on the contrary: I even vote for narrowing the
differences.

IMHO you don't *see* the differences.
I read the whole pragmatic programmer (1st ver.) and "Programmieren mit
Ruby" /Röhrl/Schmiedl/Wyss several times and I thought it would be
sufficient. but perhaps you have a good recommendation for a pure OO
book.

Bertrand Meyers OOSC is regarded one of the standards:

http://www.amazon.com/exec/obidos/tg/detail/-/0136291554

But you shouldn't worry if OO is not immediately clear to you. Sometimes
it takes some time.

Regards

robert
 
B

Benny

Robert said:
No good. Benny, I seriously think you should get rid of the idea that
variable identifiers are an object's names.
ok, I'll have to clear my programming vocabulary :)
It's a one way street. You can only walk it in the direction of varible
to instance, not the other way. It's not needed and it would be a total
overhead to manage this at runtime.
ok, thats a satisfactory answer, thanks :)

No, you don't need the var name for that. You can always do

foo = Foo.new

ObjectSpace.each_object( Foo ) do |obj|
if obj.equal? foo
puts "found it"
else
puts "other instance"
end
end

no, I wanted to do some like this:

foo = Foo.new

ObjectSpace.each_object( Foo ) do |obj|
puts obj.names.to_s # was: obj.name
end

I need to output the name somewhere (in a console,
in a log file of the like)

You're making me curios why you need that and what you do.
it quite comfortable for lots of things.

Currently I use it for a simple backup-script, where each
configuration item has a name and attributes for src, dest, exclusion,
accessing programs (e.g. mysql) etc.

there are 2 iterations over the backup-objects:
the first one to check the configuration if its complete and the syntax
is ok. the second one processes the backup stops accessing programms and
restarts some of them etc.

but I really needed the ObjectSpace iteration when I made did parsing of
syntactical items (call it "tags") who are interdependend and
have different behavior. they all have some "stages" (the degree of the
completness) and could embed other tags. for the resolution of the
dependancies to the other "tags" their methods are called and one after
another resolv its dependencies mark itself as being in the next stage
and gives the requested properties to the calling "tag" back and so on.

there are some "meta-stages" in each of the an ObjectSpace iteration over
the tags is done with calling a specific method initializing the dependency
resolving worm.

while programing I find it quite useful to let the tags give me some output
about what they are doing in the ObjectSpace. and therefor I needed some
kind of "names" to identify them (I ended up in giving them numbers in a
gobal hash where the key was the number and the value was the instance of
the "tag"-object and additionally the number was saved as attribut of this
object.

(it was to convert some own musical syntax into a structure that might
someday be converted to csound-files)
Kind regards

robert
regards,

benny
 
B

Benny

<snip: everything other is discussed widely to my
full satisfaction :) >
Robert said:
NoMethodError: undefined method `new' for #<Object:0x10185b30>
from (irb):6

You can create instances of a class but not of an object.
class C1
include Singleton
end
p2 = C1.new #=> NoMethodError: private method `new' called...

You cannot create instances of some classes as well. Now is a singleton
class more like a class or more like an object?
I am not yet convinced that the differences are that big.
ok, its called in another manner but largely behaving the same way. why
should Object not just be another special class as C1 is?


btw. thanks for your patience

regards,

benny
 
B

Benny

Florian said:
The mapping is really [context, variable] => object --
and as I already
mentioned above you can have multiple variables with the same name in
different contexts.
ok, but it should be no problem since we are always in some context when
invoking a method (the same for Object#names ). so this method would just
look into variables of the actual context.
it isn't even
designed to go from object => variable (that would be slow, because
you'd need to iterate over the variable table)
this matters though :)
I have done an extension that boxes Variables into Objects, it uses some
deep trickery to accomplish that. I've attached it and a dependency of it.
perhaps it will help me at some places.
thank you anyway for making it available.


regards,

benny
 
V

Vincent Isambart

About the class name, the name of the class is not necessarily the name
of the constant that references the name. Example:
class Foo
end
Bar = Foo
Foo = 0

Then you cannot do Foo.new, but Bar.name returns "Foo".
I think in fact, when the class does not exist, Ruby creates the class,
and gives it the name that is after "class". It then gives to a
constant of the same name the value of the class.

If you try to add a method to Foo, it does not work :
class Foo
def a() end
end
-> TypeError: Foo is not a class

You can still add a method to the class created before :
class Bar
def a() end
end

and Bar.field still returns "Foo".
So the name field of class is just a name that does not necessarily
means anything.

I hope what I said was understandable ^o^

Regards,
Vincent Isambart
 
M

Mark Hubbart

Robert said:
That's not the name of the object but the name of a variable that
references the object. What would you expect to be the name in this
case:

test = MyClass.new
t2 = test
# name?
ok, see my other posting:

"substitute Object#name with Object#names
in my first posting"
so it would be

test = MyClass.new
t2 = test
t2.names #=> ["t2", "test"]
test.names #=> ["t2", "test"]

This isn't exactly what you want, but it's as close as you can come,
currently, in ruby. Without a whole bunch of ugliness, anyway.

def names(obj, bind)
vars = eval("local_variables", bind)
vars.select{|var| eval(var, bind).id == obj.id}
end
==>nil
a = 2.3
==>2.3
b = a
==>2.3
c = 2.3
==>2.3
names(a, binding)
==>["a", "b"]
names(c, binding)
==>["c"]
names(2.3, binding)
==>[]

Now I suppose it would be possible to do something like this (untested):

def add_binding(bind)
$stored_bindings ||= []
$stored_bindings << bind
end

def do_something
add_binding(bind)
#... do other stuff
end

then...

def find_names(obj)
variable_names = []
$stored_bindings.each do |bind|
vars = eval("local_variables", bind)
variable_names << vars.select{|v| eval(v, bind).id == obj.id}
end
end

Now, you can call find_names on any object that is in a binding that
you have indexed.

Still, though, for tis to be a complete solution, you woiuld have to
come up with a way to index the @vars and @@vars, $globals and
CONSTANT_VARS, as well. I have a feeling that all this infrastructure
would cause a considerable slowdown, though.

yes I know: class names are constants

I dont get you here :(
I think as names of classes a constants and names of variables are
symbols
they are a entirely different thing (in the way ruby handles it)
I only made the statement with the subclass to get no such answer from
the
list ("use a subclass if you need names"). and as I didnt want to use
constants I also didnt want to use a subclass :)

from my other posting:

"I think in the kernel we have symbols attached to object-ids (do we?)
so why not have a method to show us the symbols to a corresponding
object_id?"

If I understand correctly, they are stored that way in the internal
symbol table. That symbol table is inaccessible, though. Once you are
in the runtime, the name -> obj correlations are spread out in various
constructs. Some are easier to get at than others; it's easy to lookup
a constant, but local variables are truely a pain.

if they behave mostly the same way in ruby
it might be reflected behind the scenes.
are the differences in the abilities of Object and
Class so big that they legitimate hard distinction in the
interpreter? or are we loosing something if Object and Class
is based on the same fundamentals apart from syntactical restrictions
and the separated name spaces (constants vs. symbols)?

Class is a template for creating objects. Object is a subclass of
class. This is a fairly common OO topic, and there is a pretty good
description of classes and objects here:

http://www.visibleworkings.com/little-ruby/Chapter3.pdf
 
B

Benny

Vincent said:
About the class name, the name of the class is not necessarily the name
of the constant that references the name. Example:
class Foo
end
Bar = Foo
Foo = 0

Then you cannot do Foo.new, but Bar.name returns "Foo".
I think in fact, when the class does not exist, Ruby creates the class,
and gives it the name that is after "class". It then gives to a
constant of the same name the value of the class.

If you try to add a method to Foo, it does not work :
class Foo
def a() end
end
-> TypeError: Foo is not a class

You can still add a method to the class created before :
class Bar
def a() end
end

and Bar.field still returns "Foo".
So the name field of class is just a name that does not necessarily
means anything.
so if I get you right, when creating a new class three things happens:
1. creation of a new class-object
2. setting the attribute "name" of the class to the given class name
3. creation of a constance with the given class name as reference to the new
class-object

tant mieux!

then we could do the same thing everytime an object is created ( = set with
"=")!
1. creation of the object, registering its relation to its class...etc
2. setting the attribute "name" of the object to the given object name, if
not given: nil

4.name #=> nil
"test".name #=> nil
test = Test.new
test.name #=> "test"
Test.new.name #=> nil
test2 = test
test2.name #=> "test"
test2.name = "test3"
test2.name #=> "test3"

name would be just another attribut of Object just as is for Class
(and as I initially thought of)

I hope what I said was understandable ^o^ surely it was.

Regards,
Vincent Isambart
regards,
benny
 
H

Hal Fulton

Benny said:
so if I get you right, when creating a new class three things happens:
1. creation of a new class-object
2. setting the attribute "name" of the class to the given class name
3. creation of a constance with the given class name as reference to the new
class-object

tant mieux!

then we could do the same thing everytime an object is created ( = set with
"=")!

We *could* in theory do that.

But you already see that it does not work 100% with class names.
And nothing in Ruby actually *relies* on this working.

What if we have an array of 100 objects? Each has no other name
than foo[73] or whatever. Do we really want to store the string
"foo[73]" somewhere? What if we do a delete, or a sort? Now these
have changed. Do we really want to update all these in realtime?

What about Hashes?

What about Structs and class members that have no other names
except complex names like Foo::Bar::myclass.mymember ?

My opinion is: You would be better off abandoning this idea, or if
you really, really need this functionality, implement something
of your own in Ruby.


Hal
 
R

Robert Klemme

Benny said:
ok, I'll have to clear my programming vocabulary :)

ok, thats a satisfactory answer, thanks :)

You're welcome!
no, I wanted to do some like this:

foo = Foo.new

ObjectSpace.each_object( Foo ) do |obj|
puts obj.names.to_s # was: obj.name
end

I need to output the name somewhere (in a console,
in a log file of the like)


it quite comfortable for lots of things.

Currently I use it for a simple backup-script, where each
configuration item has a name and attributes for src, dest, exclusion,
accessing programs (e.g. mysql) etc.

there are 2 iterations over the backup-objects:
the first one to check the configuration if its complete and the syntax
is ok. the second one processes the backup stops accessing programms and
restarts some of them etc.

but I really needed the ObjectSpace iteration when I made did parsing of
syntactical items (call it "tags") who are interdependend and
have different behavior. they all have some "stages" (the degree of the
completness) and could embed other tags. for the resolution of the
dependancies to the other "tags" their methods are called and one after
another resolv its dependencies mark itself as being in the next stage
and gives the requested properties to the calling "tag" back and so on.

there are some "meta-stages" in each of the an ObjectSpace iteration over
the tags is done with calling a specific method initializing the dependency
resolving worm.

while programing I find it quite useful to let the tags give me some output
about what they are doing in the ObjectSpace. and therefor I needed some
kind of "names" to identify them (I ended up in giving them numbers in a
gobal hash where the key was the number and the value was the instance of
the "tag"-object and additionally the number was saved as attribut of this
object.

That's exactly what I was going to suggest. It's a better solution anyway
since the number of instances is most likely not known beforehand. So you
need some kind of collection anyway. As you figured, a hash comes in very
handy here and you can use any attribute of the instance you like as key.
You can even wrap the hash with little logic so as to retrieve the key on
insertion:

class Index < Hash
def initialize(key)
super()
@key = key
end

def index(obj)
self[ obj.send @key ]= obj
end
end

Of course you can add logic so the objects know their index automatically
etc.

Kind regards

robert
 
R

Robert Klemme

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,787
Messages
2,569,629
Members
45,329
Latest member
InezZ76898

Latest Threads

Top