TeensyMud : Forum

Subject: Why properties?
Author: Massaria
Posted: 01/18/2006 04:09PM

I know you've made a long code example of how properties work, which may or may not be sufficient for me to use them... time will tell.

I must admit I'm rather unhappy about the whole deal. It seems to me that your're just introducing another, much more complicated, way of doing 'attr_accessor'. I can't see what it brings to the table in way of... well anything.
I'm particularly annoyed that my variables wont save unless I use them as properties.

Are they making life easier on you or me? (the destinction being developer and user).

Thanks.
Mass.

Subject: Why properties?
Author: Tyche
Posted: 01/18/2006 05:14PM

Massaria wrote:
>
> I know you've made a long code example of how properties work, which may or may not be sufficient for me to use them... time will tell.
>
> I must admit I'm rather unhappy about the whole deal. It seems to me that your're just introducing another, much more complicated, way of doing 'attr_accessor'. I can't see what it brings to the table in way of... well anything.
> I'm particularly annoyed that my variables wont save unless I use them as properties.
>

That's easily fixed. Don't use the properties module. If you don't specify 'property :foo, :bar, :baz' in a class, nothing gets in the way of you using attr accessors, and using and saving all the the instance variables on your class.

You will have to fix up a couple lines in the Root object as well.

$ svn diff lib/db/root.rb 
Index: lib/db/root.rb
===================================================================
--- lib/db/root.rb      (revision 112)
+++ lib/db/root.rb      (working copy)
@@ -16,7 +16,7 @@
 #
 class Root
   configuration
-  property :name, :owner, :desc
+  attr_accessor :id, :name, :owner, :desc
   logger 'DEBUG'
 
   # Create a new Root
@@ -24,7 +24,7 @@
   # [+owner+]    The owner id of this object
   # [+return+]   A handle to the new Object
   def initialize(name, owner)
-    self.id                     # The database id of the object
+    self.id = $engine.world.db.getid    # The database id of the object
     self.name = name            # The displayed name of the object
     self.owner = owner || id    # The owner of the object or itself.
     self.desc = ""              # The description of the object

> Are they making life easier on you or me? (the destinction being developer and user).

Well there are a couple of reasons behind it:
1) I don't want to save every attribute on my objects to storage. I need an easy way to distinguishing persistent versus non-persistent attributes.
2) I am going to be using an rdbms myself. There are a number of ways I can implement the structure of the tables. No matter how I do it, I will want to know the column names of the attributes that will be saved. I will also want to know if columns (attributes) as the database schema defines them are different from the way the code defines them (auto-migration).
3) I am thinking I want to automatically add accessors and attributes from inside the game (via a builder command or a script). Which is not necessarily compatible with 1) or 2) either.

If there's a way to make the choice of using properties a configration option I will do that.

Subject: Why properties?
Author: Tyche
Posted: 01/18/2006 05:20PM

Tyche wrote:
>
> You will have to fix up a couple lines in the Root object as well.
>

There's another way... in properties.rb comment out the following:

#   def to_yaml_properties
#      ['@props']
#    end

That way everything saves. Of course it doesn't change the restrictions on using the @instance vars to refer to them which the previous method gets around.

Subject: Why properties?
Author: Massaria
Posted: 01/19/2006 12:42PM

I guess this has nothing to do with properties as such, but my problem is a result of their introduction, so I'll continue this thread.

I'm quite simply having problems extracting the properties of the room. Before I could do something like:

r = $engine.world.db.get(@location)
r.each do |x|
...

But now 'r' isn't an array anymore, and Room can't find the 'each' method - but much to my amasement it can still find something like 'to_a'. That just doesn't make sense. If this matz guy is so smart, why the hell doesn't he just make all those methods 'standard' to all classes. People who need them to do something else can just redefine them to their hearts contend.

At the very least he could make the methods consistent; either they're all there or none of them are.

Massaira,
sulks

Subject: Why properties?
Author: Tyche
Posted: 01/19/2006 01:55PM

Massaria wrote:
> I'm quite simply having problems extracting the properties of the room. Before I could do something like:
>

> r = $engine.world.db.get(@location)
> r.each do |x|
> ...
>

>
> But now 'r' isn't an array anymore, and Room can't find the 'each' method -

Room was never an array. It does contain two arrays, contents and exits. So you probably mean one of these:

r = $engine.world.db.get(@location)
r.contents.each do |x|
or
r.exits.each do |x|

> but much to my amasement it can still find something like 'to_a'. That just doesn't make sense. If this matz guy is so smart, why the hell doesn't he just make all those methods 'standard' to all classes. People who need them to do something else can just redefine them to their hearts contend.
>
> At the very least he could make the methods consistent; either they're all there or none of them are.

While to_a is defined on Object, it's also been deprecated. The default to_a simply wraps the Object as a one element array. I suspect the intent of that was to allow one pass Objects to methods which expect arrays, or variable lists of arguments. It likely precedes this notation which may not have existed in Ruby 1.4 or 1.6...

def mymethod(*args)

I bet one had to do something like this before...

def mymethod(args)
..do something that expects array
end
mymethod(myarg.to_a)