# (get|set)_property_value OR

Andrew Bakun (abakun@scinc.com)
Thu, 22 Aug 1996 08:07:52 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >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.