(get|set)_property_value OR

• Date: Thu, 22 Aug 1996 08:07:52 PDT
• From:
  Andrew Bakun <abakun@scinc.com>
• Content-Type: text/plain; charset="us-ascii"

>From: Bill Drury <bild@io.com>
>One really useful thing that allowing foo.bar="burfle" to implicitly call
>set_property_value(foo, "bar", "burfle") and foo.bar to implicitly call
>get_property_value(foo, "bar") (and thus to allow for wrappers) would be
>the ability to easily implement 'inflatable' objects, i.e. objects whose
>data is stored out of the MOO database somewhere until it is actually
>needed.

In what way?  Disk basing the server in-db?  Semi-distributed databases?
Doing this will add even more overhead to something that you can do by
yourself by forcing yourself to program in an abstract and OO way.
Admittedly, this will make the interface seem "cleaner", but it still looks
like a direct property access, which it isn't.  You won't be able to tell if
your direct property accessing code is going to suspend or take a long time
(depending on what exactly (get|set)_property_value does, writing to disk
and handling network connections can take a while, and/or suspend).  The
builtins could be provided, but I don't think it would be ideal to overload
the property access operator to call them.  You can then call
(get|set)_property_value whenever you want to do the things you describe --
but in that case you might as well program with accessor methods anyway
(even the convoluted naming of this:_set_foo(value) and this:_foo() is
easier to read and understand than set_property_value(this, "foo", value),
and it's OO to boot).

From: ninoles.fabien@ic.gc.ca (Ninoles, Fabien: DGSE)
>I have to agree with him... This just let the MOO
>be more Object Oriented let us override some
>operator... 

People have been complaining since I found LambdaMOO that MOO is not well
documented, that the programmer's manual is hard to understand and that the
standare core database is illarranged (I only partly agree with one of
these).  And you want to add operator overloading?  This would make more
sense if (and when) we get user defined data types, until then, it has a
very small scope.

>More of that, this let us add some security
>check (or anything else) on a propriety without having
>it to be -c... 

If you want a security check, it should be -c anyway, since if it's +c, then
the owner can do anything they want with it, no matter if you overload
(get|set)_property_value.

>But keep in mind to leave it simple.  

It already is.  You just have to force yourself to do it "properly".  I view
adding (get|set)_property_value for the reasons listed above to be anti-simple.

What is needed is a way to declare properties as public or private, or make
them all private and not allow outside access, thereby forcing people to
write accessor methods -- forcing them to use accessor methods within the
allowed scope is another story though.

Andy.

• Prev: Re: $verb_editor:"comment uncom*ment"
• Next: [Server] Wish list entries...
• Index: MOO-cows
• Thread: MOO-cows