Re: Properties as hash keys, damn perl is cool!

[Ross McFarland <rwmcfa1 neces com>]

On Wed, 2003-10-29 at 17:14, Emmanuele Bassi wrote:

> I've even thought about implementing something myself, but I'm not
> a Perl hacker half as good as you or muppet are. ;-)

don't know about that, but thanks.

> That was the over-enthusiastic part.  Now, I'll have to state the cons
> that I came up with when I was thinking about exposing properties as
> keys of the object's hashref: first of all, and major annoyance, this
> feature could end up breaking existing code (that is also the reason
> why, in PyGTK, this exposure of properties wasn't done).  The other
> major issue regards memory use: a button has a few properties, but a
> thing like a CellRendererText has some 30+ properties, some of them bound
> to other objects and not to simple scalar values; exposing all of those
> properties could result in a memory hog in, for instance, a cell-data
> function (where, according to my personal experience, you'll end up
> modifing most of the cell rendererer's properties).

exactly why it is not 'on' by default. there are several scenarios in my
mind now, but as far as i'm concerned none of them involved being on by
default. as it stands now, the code sent out a while ago, there is no
overhead, memory usage and/or processing time, unless you call
$object->tie_properties. (obviously there's the code to implement the
stuff that will take up a couple of k, but that's insignificant and
would never be executed unless you tie_properties)

the other possibility is there being some setting that would cause the
new method of Glib::Object to tie_properties if turned on (off by
default again for same reasons.) so for new code written you could do
something like. (this is totally brainstorming, so i haven't thought it
through)

use Gtk2 '-init';
Glib::Objects->tied_objects = TRUE;

there's obvious overhead involved here, but it's an opt in so you it's
your own fault if you ask for it.

point by point:

* break existing code - no,  off by default, you turn it on you deal
with what it breaks.

* memory usage - not really issue, none used unless you ask for it, if
you ask for it then it's assumed that you know it's going to take up
some memory and you want it to.

-rm

> +++
>
> In the end, I strongly suggest of keeping this feature to be explicitely
> called by the programmer, or to implement a pragmatic module that does
> this on developer's behalf, and not trying to be "smart", and doing this
> "under the hood" of gtk2-perl.

that was muppet's thoughts, separate module, but after we saw how little
code it was it just makes sense for it to be in Glib by default, but as
you suggest and we think, off by default. (with lots of documentation
showing you how to use it)

-rm