Re: StdProp overhaul: broken plug-ins

[Cyrille Chepelov <chepelov calixo net>]

Le ven, aoû 17, 2001, à 05:56:58 +0200, Hans Breuer a écrit:
> pdesc->ops->new_prop(pdesc->ops,pdtpp_true)
> Ah, here are the IMO most questionable additions to the Dia namespace
> of your whole restructuring. While make_new_property only is somewhat
> odd (not counting the fact, that I still don't think a copy is needed
> in my use case). pdtpp_true i a thing which should not only be
> more literal, but IMHO even than needs some explanation/documentation.
> 
> prop_desc_to_prop_true ? Not that speaking to me :)

Right. pdtpp is "Prop desc to prop predicate". pdtpp_true was for where
there isn't better to put (read: we need a more describing predicate). This
was what happened 

> >
> I see the Property itself as an object, or in 'C' notation: 
> 'Gimme the pointer'. The lifetime of an DiaObjects Properties
> is managed by the DiaObject. As long as it survives the Property
> will, too. Or is it i.e. looseing it's  bounding box somewhere
> on the way ?

No. The lifetime of a [current]Property is much, much shorter ; it's bounded 
by the lifetime of the property list which holds it, which typically is a
throw-away object (built from a prop_desc list just before doing "something"
(show property dialog, load, save, copy, etc.), used while doing the
"something", and thrown away just afterwards). And, as I previously said, a
Property really only holds a bit of information which has been related to an
Object at one point of the time, and can be applied to an Object (possibly
another instance, of the same or another class) later. See
object_copy_using_properties(), which makes this obvious.

The only thing that really links Properties with the data members of Objects
is the PropOffsets mechanism, where object_[sg]et_props_from_offsets() are
used as clearinghouses between a property list on one side, and a list of
fields in an object, identified by name and type.

Yes, it took me time to remove this confusion out of my mind.

> If you give me a reference to the parameter property and than delete
> the whole DiaObject I still would have a valid property object, though
> it's not connected to an object anymore ...

Ahh, I see here someone fond of refcounting (I'm neutral on this).


> >> Ok there is currently no ref counting, but the Python plug-in
> >> will crash on deleting whole Dia objects under it's feet
> >> anyway. But the object reference is needed.
> >
> >You already have it, since you pass it to object_prop_by_name().
> >
> But I don't really hold it because something else may delete the
> object, and what I have than (without ref counting) is a dangling
> pointer.

I see where your problem is. Basically, when you build a Python object out
of a property, you keep the property it was linked to. You return from
PyDia, and then later you try to reuse a Property * which most likely is a
dangling pointer. OK, you don't really have a dangling pointer, since you've
made a copy of the property. But you still have a problem with the deletion
of the object. 

I see a Dirty(tm) way out, but I now understand the problem you have, and
why you want (Dia)Objects to be refcounted.

> >> >lots of prototypes and braces, but less casts... And this trivial garbage
> >> >can easily be hidden in a separate compilation unit (that's the
> strategy of
> >> >all these lib/prop_*.c) 
> >> ... maybe it should provide the type conversion functions than, too ?
> >
> >Hmm. I'm not sure what the "it" in your last sentence refers to.
> >
> You are assuming right, though I would have called it 'Property
> Handling Facility' (Some advertising of GValue comes to mind :) ...

oh no ! :-)

> ><assuming referred="lib/prop_*.c">
> >It does, in the form of the GetFromOffsetsFunc. In the case of PyDia,
> >setting up a PropOffset structure and calling GFO on it (for each different
> >type) is probably much more hassle than peeking into a semi-public
> >structure.
> ></assuming>
> >
> ... what about a property method get_underlying_c_type

How do you return the type ? What do you do when the underlying C type is a
complex struct of things which must be kept in sync (think PROP_TYPE_LIST,
but this can be arbitrarily complicated) ? This can happen both with the
contents of a struct _Property subclass, and what's pointed by the offset
and offset2 fields of the PropertyOffset struct.

> Thinking a little more about the TYPE_ID_IS_INTEGRAL issue, if it keeps
> a direct string as you propose, how do you guarantee, that the type 
> names are unique and not two 'type identifiers' are named the same
> but have a completely different meaning ?

I can put a g_assert_not_reached() check in prop_type_register(). All
property types must be registered anyway. 
That should be more than enough to avoid conflicts, on the developer's machine
(this is basically what we do to avoid different object types having the
same type name, after all. We can also push a little further, and require
object_library-specific property types to have a "$LIBRARY - $TYPE" form,
like we do for object types). If that never happens after a few initial
compiles on a developer's machine, this won't happen on a user's. Mmmm. The
$LIBRARY - $TYPE form should indeed be documented and mandated. This works
well.

	-- Cyrille

-- 
Grumpf.