Re: Abstract string properties with getter/setter functions

On Thu, 2007-09-20 at 08:15 +0200, Raffaele Sandrini wrote:
> On Wed, 2007-09-19 at 19:20 +0200, David Nečas (Yeti) wrote:
> > On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote:
> > > > > Since we do not see a way around this (yet) and we could not find an
> > > > > example with strings in another project. I'm asking here if there is a
> > > > > nice way around this.
> > > > 
> > > > i'm really not sure i understand your problem here...
> > > 
> > > We need a way to steal the string from the property i.e. to make sure
> > > its not a copy of the original.
> > 
> > The property does not need to be actually backed by
> > a string.  It just has to accept a string in the setter and
> > produce a string -- a new string -- in the getter.  For
> > instance GtkCellRendererText has properties "background"
> > wich is a string (write-only though) and "background-gdk"
> > which is a GdkColor. They are views of same thing and
> > what is this actual internal representation is none of your
> > business.
> > 
> > To sum it up, you cannot steal something that is owned by
> > you from the begining.
> Properties "generating" things are a complete different story. We have
> to treat them separately. Properties transferring ownership will need to
> be specially marked in Vala.

Given that you're talking about "abstract" properties, marking a string
property as "steal on get" seems to be problematic, as you have
instantly made it impossible to write an implementation which doesn't
keep the string around itself. If any implementation wanted to construct
the string when it's called, it can't without leaking.

If you wanted to have getters which don't strdup() the string every
time, maybe you want to look into using reference-counted strings.


"You couldn't get a clue during the clue mating season in a field full
of horny clues if you smeared your body with clue musk and did the clue
mating dance." -- Edward Flaherty

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]