06 Jul, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
ok, in ruby i'm going to create a singleton object called world, this will contain lists of all the in game
objects (rooms, items, mobs, etc) the reason i'm going to do it this way is because there is going to be one 'world'
and it just seems like a good idea. Now, i noticed something similar in Tyche's TeensyMud base, but i cant figure it
how it works, as far as calling the singleton object.

see, if i want to access on of the worlds lists i would have to do this:
World.instance.room_list


now, is there any other way of access the info without having to type in "instance" everytime?
I know it sounds dumb, but it bothers me.
06 Jul, 2009, Stormy wrote in the 2nd comment:
Votes: 0
If you access it directly then yes, you need to use instance. What you're probably referring to in TeensyMud is the Object#world method, which returns World.instance. To do that, just define the method outside of a class, or in the Object class.

def world
World.instance
end
06 Jul, 2009, Chris Bailey wrote in the 3rd comment:
Votes: 0
To be honest, I don't see the need to use a singleton. Just defining your "World" as a class that stores your information as instance variables would suffice without any extra overhead. You just make one instance of it for access.

class World
attr_accessor :room_list, :item_list
def initialize
@room_list = []
@item_list = []
end
end

world = World.new
world.room_list.push Room.new
world.item_list.push Item.new
world.room_list.each {|room| puts room.name}

Is there any particular reason not to do it that way?
06 Jul, 2009, JohnnyStarr wrote in the 4th comment:
Votes: 0
wouldn't world be a stack variable? so if i wanted to access the world
instance throughout the mud, i would either have to make it global or
pass it? - just wondering.
06 Jul, 2009, Runter wrote in the 5th comment:
Votes: 0
staryavsky said:
wouldn't world be a stack variable? so if i wanted to access the world
instance throughout the mud, i would either have to make it global or
pass it? - just wondering.


Short answer is everything is a reference in Ruby. There is no pointers and all function calls pass by referencehave references as parameters.
Assignment is a reference assignment.
So yes, you would have to have access to the reference within scope of any code using it. When no variables reference any instance of any class the memory will automatically be freed by the GC.
s = "meh"
s2 = s

s.slice!(0)
### slices off the first character
### s2 still refers to s and thus both variables refer to "eh"


To copy an assignment you would use .dup or .clone

s2 = s.dup
06 Jul, 2009, JohnnyStarr wrote in the 6th comment:
Votes: 0
ok, well thanks. But that dosn't really get me any further.
When i say:
World.instance.blahblah

that gives me the ability to access it without having to pass it or dup it or whatever, i was just wondering if there was a way around that.
06 Jul, 2009, Stormy wrote in the 7th comment:
Votes: 0
You'd just assign the World object to another object's attribute.

class Whatever
def initialize
@world = World.new
end
end


There's nothing wrong with using a Singleton class for this and it'll keep a bit cleaner, as you can see.
06 Jul, 2009, David Haley wrote in the 8th comment:
Votes: 0
Is that actually true – that all function calls are by reference? My understanding was that things are passed around by value, but that most (all?) values are references to things.

$ cat test.rb

def foo(a)
a = 2
end

bla = 1

print("Before foo: ")
print(bla)
print("\n")
foo(bla)
print("After foo: ")
print(bla)
print("\n")


$ ruby test.rb
Before foo: 1
After foo: 1


If 'a' were passed by reference, then the assignment would modify 'bla' and the second statement would print 2.
06 Jul, 2009, JohnnyStarr wrote in the 9th comment:
Votes: 0
so stormy, what would this look like througout the mud?

Whatever.world.roomlist ?

i mean, how does that help?
06 Jul, 2009, Runter wrote in the 10th comment:
Votes: 0
David Haley said:
Is that actually true – that all function calls are by reference? My understanding was that things are passed around by value, but that most (all?) values are references to things.


I misspoke. I meant the values are references. Not copies of the data.
06 Jul, 2009, quixadhal wrote in the 11th comment:
Votes: 0
Global variables are not ALWAYS evil, despite what your OO taskmaster might have chanted while whipping you with the lash of over-engineering. :)

If you have a world structure that just about everything in the game will access, making it global would probably make things much easier to work with. If you need security for some parts, pass in a subset of your world data to control access where it's needed.
06 Jul, 2009, David Haley wrote in the 12th comment:
Votes: 0
A place where "singletons" are appropriate as opposed to global variables is if each thread of execution has its own copy, in which case the singleton-obtainer function returns the thread's copy.

Global variables are usually fine for this kind of thing in a single-threaded environment, though.
06 Jul, 2009, Stormy wrote in the 13th comment:
Votes: 0
staryavsky said:
so stormy, what would this look like througout the mud?

Whatever.world.roomlist ?

i mean, how does that help?


I think I already answered what you're looking for in #2 – was that not it?
06 Jul, 2009, Chris Bailey wrote in the 14th comment:
Votes: 0
Yeah I'm pretty sure your first post summed it up Stormy.
06 Jul, 2009, JohnnyStarr wrote in the 15th comment:
Votes: 0
Stormy said:
staryavsky said:
so stormy, what would this look like througout the mud?

Whatever.world.roomlist ?

i mean, how does that help?


I think I already answered what you're looking for in #2 – was that not it?


OMG, i missed post #2, sorry!
06 Jul, 2009, Chris Bailey wrote in the 16th comment:
Votes: 0
lol @ Staryavsky, I'm really just trying to figure out why you need to do it in the first place, it seemed to me that it could be a lot simpler. Singletons do have their uses though, just realise that just because you only have one instance at any given time doesn't mean that it HAS to be a singleton.

$world = World.new # Only one at a time folks! =)
06 Jul, 2009, JohnnyStarr wrote in the 17th comment:
Votes: 0
Chris, i do know about globals ;)

Here's the thing, i dont like using them if can help it. But your right, i mean, i think David was bringing out a use for
them as far as threading goes. I just was curious how Tyche pulled it off, but stormy made it make sense, but then again
he said "put it in the Object class" so would that go like this:

class Object
def world
World.instance
end
end
06 Jul, 2009, Runter wrote in the 18th comment:
Votes: 0
There's little reason to avoid using global variables when they are actually a true object that merits global scope. This sounds like an example where it is legitimately not poor design to do so.
06 Jul, 2009, Chris Bailey wrote in the 19th comment:
Votes: 0
He did say you could put it in the object class but you don't have too.

def world
World.instance
end

would work just as well. Of course it seems to me you could just add room_list and item_list as class methods to World as well, and not have to worry about this?

class World
@@room_list = []
def self.room_list
@@room_list
end
end
07 Jul, 2009, Tyche wrote in the 20th comment:
Votes: 0
World isn't a singleton in TeensyMud.

There is a world method on the root object…
def world
Engine.instance.db.get(0)
end

And since almost everything in the game is subclassed from Root, it is inherited.

World is a non-swappable object in the Store, so it'll always live in the cache.
0.0/28