Re: [RFC][PATCH] Small enhancement for Glib::Object::Subclass

["muppet" <scott asofyet org>]

A. Pagaltzis said:
> I don't particularly like it either. Magic names are almost never
> an optimal interface.

we have more than enough magic names as it is, what with all the vfunc and
interface implementations --- having essentially random namespace pollution
like seems really unattractive.


> I'd prefer having a method to register
> coderef callbacks for accesses to given property names; the
> $self->can() check would then be replaced by a simple hash lookup
> on the property name. Much cleaner, barely any extra overhead.

this sounds promising, actually.  to do it right, it could be wired into
Glib::Type::register_object() itself, instead of Subclass.pm, so that you'd
always have the functionality, and also so we could short-circuit some things:

  use Glib::Object::Subclass
     'SomeParent',
     properties => [
        # follow the default path
        Glib::ParamSpec->int (...),
        {
            pspec => Glib::ParamSpec->double (...),
            getter => sub {...},  # explicit getter
            setter => sub {...},  # explicit setter
        }
        {
            pspec => Glib::ParamSpec->double (...),
            # unspecified getter uses the default path
            setter => sub {}, # explicit setter
        }
     ],
     ;

and then in the bindings we have the get_property and set_property overrides
(At the C level) do this sort of thing:

   if there's an explicit callback
      marshal and invoke it.
   else if there's a GET/SET_PROPERTY function defined
      marshal and invoke it.
   else if the object wrapper hash contains a key named for this property
      use that value.
   else
      do nothing.

that would provide a "reasonable" default behavior without breaking
compatibility, without clogging the namespace, and with a fair chance for
performance enhancement in the default case (since no marshaling is needed).

other baroque magic springs to mind (if the hash key is a CODE ref, invoke it)
but that sort of stuff is going to add to complexity without really improving
things, so i'd steer away from them.


-- 
muppet <scott at asofyet dot org>