28 Oct, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
I love, love, love RUBY!
I came up with this in like 5 minutes, sometimes the best solution is the simplest:
# First create your hash tables for each mode:
server.aedit_hash = {"name" => :@name, "description" => :@description}

# Then call the editor through an alternate menu routine
def alternate_menu(data)
case @altmenu
when :am_aedit
edit(data, "Aedit", server.aedit_hash)
end
end

module Olc
def edit(arg, mode, hash)
if arg == "done"
done "Exited #{mode} mode"
return
end

unless arg.empty?
com = ''
one_argument!(arg, com)

hash.each {|key, value|
if com.is_prefix?(key)
@olc_obj.instance_variable_set(value, arg)
to_buffer "Set #{key} to: #{arg}" << ELL
return
end
}
to_buffer "What?" << ELL
else
buf = mode << EL
hash.each {|key, value| buf << key << ": " << @olc_obj.instance_variable_get(value) << EL}
to_buffer buf << EL
end
end

def done(txt)
@altmenu = :am_none
to_buffer txt << ELL
end
end


So, you can create a editor mode for each object you want to edit.
This way, you can add as many fields as you want without having to add any code.
BTW, I Mixin the Olc module to my Descriptor class.
28 Oct, 2009, Igabod wrote in the 2nd comment:
Votes: 0
how does this remove the need to add in code? I'm not quite proficient at reading ruby yet to know exactly what this is doing, but it doesn't look like it removes the need to do coding if you want to add a new field to an item or room or whatever.
28 Oct, 2009, JohnnyStarr wrote in the 3rd comment:
Votes: 0
The only 'code' you add are the object properties to the hash table.
I use a Singleton object as the "server", so when I say server.aedit_hash = foo, when I call the editor
I include 3 arguments, (arg) user input, (mode) the edit mode, (hash) the hash table that contains each
property that you want to get / set. Because of Ruby's duck typing, you can set the Descriptor's @olc_obj to
any object that you want.

You can also load new properties to the hash on-the-fly. And if you wanted to, you could load each olc objects
edit-properties from a YAML file, thus not writing any Ruby code.

Now, there are to be some exceptions such as adding a "dig" command Etc. But I wanted to give a quick example
of how you can easily create a dynamic olc in Ruby.
29 Oct, 2009, Igabod wrote in the 4th comment:
Votes: 0
hmmm sounds pretty interesting. I'd like to see it at work, could you possibly post a copy/paste of you editing an object or something?
29 Oct, 2009, Runter wrote in the 5th comment:
Votes: 0
Little random, but what version of Ruby are you using? Also which platform?
29 Oct, 2009, JohnnyStarr wrote in the 6th comment:
Votes: 0
Ruby 1.8.6
Win32

Why?
30 Oct, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
Igabod said:
hmmm sounds pretty interesting. I'd like to see it at work, could you possibly post a copy/paste of you editing an object or something?

Sure.

So, here's an example of the hash tables:
world.aedit_hash = { "name"        => :@name,
"description" => :@description,
"vnum" => :@vnum
}

world.oedit_hash = { "vnum" => :@vnum,
"name" => :@name,
"description" => :@description
}


Example:

hp4000 ap1350 mp2000>olcnew obj standard issue cloak
O-Edit
name: standard.issue.cloak
description:
vnum: shire/obj/standard.issue.cloak

hp4000 ap1350 mp2000>descr this is a standard cloak!
Set description to: this is a standard cloak!

hp4000 ap1350 mp2000>
O-edit
name: standard.issue.cloak
description: this is a standard cloak!
vnum: shire/obj/standard.issue.cloak

hp4000 ap1350 mp2000>done
Exited O-edit mode

hp4000 ap1350 mp2000>olcnew area midgaard
A-Edit
name: midgaard
description:
vnum: area/midgaard

hp4000 ap1350 mp2000>descr Diku standard Midgaard
Set description to: Diku standard Midgaard

hp4000 ap1350 mp2000>
A-Edit
name: midgaard
description: Diku standard Midgaard
vnum: area/midgaard

hp4000 ap1350 mp2000>save
midgaard Saved.

hp4000 ap1350 mp2000>
30 Oct, 2009, Runter wrote in the 8th comment:
Votes: 0
staryavsky said:
Ruby 1.8.6
Win32

Why?


Was curious how it was working out for someone on windows. I've had trouble dealing with gems in windows. Also, you should be using 1.9 :P
30 Oct, 2009, Igabod wrote in the 9th comment:
Votes: 0
hmm looks very neat. only thing I see that I have a question about is the item name for the cloak. would the player still be able to type get cloak considering the item name is standard.issue.cloak without spaces? Or is the name really "standard issue cloak" considering the fact that that's how you typed it when you created it? I'm just a little confused by the .'s in there.
30 Oct, 2009, Koron wrote in the 10th comment:
Votes: 0
I would wager that the object is saved in the shell with periods instead of spaces to avoid the headache of dealing with thost aforementioned spaces, but those '.'s are converted into ' 's in game.
30 Oct, 2009, Igabod wrote in the 11th comment:
Votes: 0
Is that being done in the ruby code provided in the OP or is that done elsewhere in the mud already? I really gotta get better at reading ruby code that isn't my own work.
30 Oct, 2009, Runter wrote in the 12th comment:
Votes: 0
Not sure what you mean but it looks like their input is directed to #alternative_menu when they are indeed in editor mode.
30 Oct, 2009, Igabod wrote in the 13th comment:
Votes: 0
I'm talking about the spaces being converted to .'s. Is that done within the ruby code or is that a feature that exists elsewhere in the mud's codebase? And if that is handled within the ruby code could someone point me to the line(s) that does it?
30 Oct, 2009, JohnnyStarr wrote in the 14th comment:
Votes: 0
Koron said:
I would wager that the object is saved in the shell with periods instead of spaces to avoid the headache of dealing with thost aforementioned spaces, but those '.'s are converted into ' 's in game.

Exactly, the '.'s are just for file / vnum naming conventions. On $>olcnew obj standard issue sword: I
store these into a field as "keywords"


Igabod said:
I'm talking about the spaces being converted to .'s. Is that done within the ruby code or is that a feature that exists elsewhere in the mud's codebase? And if that is handled within the ruby code could someone point me to the line(s) that does it?


Ruby is full of 'factory' methods. So, class String has a ton of cool features. I used gsub:

From ruby-doc.org

str.gsub(pattern, replacement) => new_str
str.gsub(pattern) {|match| block } => new_str

Returns a copy of str with all occurrences of pattern replaced with either replacement or the value of the block. The pattern will typically be a Regexp; if it is a String then no regular expression metacharacters will be interpreted (that is /\d/ will match a digit, but \d will match a backslash followed by a d).

If a string is used as the replacement, special variables from the match (such as $& and $1) cannot be substituted into it, as substitution into the string occurs before the pattern match starts. However, the sequences \1, \2, and so on may be used to interpolate successive groups in the match.

In the block form, the current match string is passed in as a parameter, and variables such as $1, $2, $`, $&, and $ will be set appropriately. The value returned by the block will be substituted for the match on each call.

The result inherits any tainting in the original string or any supplied replacement string.

"hello".gsub(/[aeiou]/, '*') #=> "h*ll*"
"hello".gsub(/([aeiou])/, '<\1>') #=> "h<e>ll<o>"
"hello".gsub(/./) {|s| s[0].to_s + ' '} #=> "104 101 108 108 111 "


Google: Ruby String Class for more

Runter said:
You should be using 1.9

Yeah, I know :p, I picked up "The Ruby Programming Language 1.8 / 1.9" for that very
reason. I have the interp installed, I just need to give it a try.
30 Oct, 2009, JohnnyStarr wrote in the 15th comment:
Votes: 0
After giving it some thought, I have to admit my code wasn't 100% clear. I

literally copied and pasted from my project.

For the most part, I wanted to share the flexibility of Ruby's dynamic typing
and Ruby's relationship between Symbols and Strings. One of the hardest
things for me to get through my head (coming from a C background) was that
so much can be done on the fly. In fact, you can use my hash example to add
instance variables that aren't already defined anywhere else. Also using
"Reflection" you can introspectively analyze an object to see what Type it is:

obj.is_a?(Type)


I think that Symbols are worth studying as well. It opens up a ton of
possibilities. With all this freedom does come some responsibility as discussed

on a few other threads here.

BTW, as stated on the original post, I wrote the example very quickly. I've
already refined a few things. I'll be uploading a complete OLC once I'm done
so maybe that will be more helpful.
30 Oct, 2009, David Haley wrote in the 16th comment:
Votes: 0
I think it's always nice to see somebody discover all the niceties of dynamic languages (introspection, runtime control of classes, etc.). :smile:

If you like some of the static typing you get in C++ but still like introspection, you might like Java as you get a little bit from both worlds. Some love it and others hate it; detractors say that you get the worst of both worlds and fans say you get the best from both. :wink:
30 Oct, 2009, Tyche wrote in the 17th comment:
Votes: 0
staryavsky said:
I love, love, love RUBY!

David Haley said:
If you like some of the static typing you get in C++ but still like introspection, you might like Java as you get a little bit from both worlds. Some love it and others hate it; detractors say that you get the worst of both worlds and fans say you get the best from both. :wink:


I completely missed the part where the poster was asking for static typing and or less reflection capabilities.
Any particular reason for the completely off-topic post?
30 Oct, 2009, David Haley wrote in the 18th comment:
Votes: 0
Geez, somebody's feeling kind of grumpy today.
I mentioned it because he has a C background, and therefore is likely to be more familiar with static typing, and perhaps more comfortable with it in some circumstances. I didn't realize it was such a terrible thing to say; please forgive me oh great Tyche. :rolleyes:
30 Oct, 2009, Tyche wrote in the 19th comment:
Votes: 0
David Haley said:
Geez, somebody's feeling kind of grumpy today.
I mentioned it because he has a C background, and therefore is likely to be more familiar with static typing, and perhaps more comfortable with it in some circumstances. I didn't realize it was such a terrible thing to say; please forgive me oh great Tyche. :rolleyes:


http://www.mudbytes.net/index.php?a=topi...

How many times are you going to remind this poster that they ought not be using Ruby?
Frankly, several posters contacted me about starting a Ruby forum on muds, because they were sick and tired of threads being derailed by language bigots.
But not long after that, language specific discussion fora were created here. You don't see me posting in the LUA, Python, C++, Java boards advocating dynamic typing and switching to Ruby do you?
Yes I'm grumpy.
Enough already. Please kindly knock it the fuck off.
Or go start a language war in the Controversial topics forum…
30 Oct, 2009, David Haley wrote in the 20th comment:
Votes: 0
Wait… what? Dude, what is your problem? I didn't say he shouldn't use Ruby. In fact, I very explicitly said that it's "always nice to see somebody discover all the niceties of dynamic languages". In the other thread you refer to, I merely said that duck typing has its ups and downs, and later stated in no uncertain terms that "I absolutely agree that you should not shy away from these techniques". I most absolutely did not say "don't use Ruby" – there, here or anywhere else.

In fact, while I discussed the issues, your only contribution to the thread after that was some childish repetition that added nothing. I'm not sure why you feel that kind of post is appropriate, but that even daring to mention other languages as interesting comparisons is a crime.

Did I mention Java here? Why, yes, I did. I think it's interesting to learn about languages that explore various techniques, and in the past Stary and I have discussed these questions and he seems to enjoy it, and therefore I felt it appropriate to make that (very brief!) remark.

Did I say "you must use Java instead of Ruby"? No, I did not. Did I say "you should use something other than Ruby"? No, I did not. Did I say "Ruby is bad"? No, I did not. I don't think I need to elaborate further on this point.

- If you have a problem with discussing ups and downs of any language technique, I don't know what to say, other than to point out some amount of irony at your usage of the term "language bigot".
- If you think that discussing ups and downs of dynamic language features is specific to Ruby, you need to broaden your spectrum a little bit.
- If you have a problem with side remarks meant to enlarge somebody's knowledge of computer science, while at the same time praising their willingness to explore and being happy at what they're learning, then I think your attitude is completely unsuited to this environment.
- If you saw a thread about some other language that was doing something shady, I would most certainly expect you to share your knowledge with people as to why that technique is shady, or potentially dangerous at least, and how to avoid problems with it.
- If you're so sensitive about Ruby that passing remarks are enough to provoke this temper, maybe you need to calm down a little bit and realize that this is about sharing ideas, not starting a "language war" (why you are so keen to turn it into one is a mystery to me).

I'm sorry Tyche, but I think you are being entirely unreasonable and I will have to decline your request. I guess that you could try talking to the moderators if you still feel that my behavior is completely out of line.
0.0/33