Re: StdProp overhaul: broken plug-ins

[Hans Breuer <hans breuer org>]

At 00:47 16.08.01 +0200, Cyrille Chepelov wrote:
> Le jeu, aoû 16, 2001, à 12:00:47 +0200, Hans Breuer a écrit:
>
> [advertisement for GObject]
It was not really advertisement. For your reading pleasure you may
want to replace every occurence of GObject with GtkObject (without
the GUI dependence) and read it again :-)
 
> I'm a bit wary of GObject.... Given the effort which will be required to
> convert to GObject anyway, shouldn't we just convert (rewrite) in C++ ? Or
> maybe in Python.
This isn't the point. IMO the DiaObject systems is already quite similar
to GObject. And we are using Gtk Objects all over the place.
In contrast to simply switch to a really object orientated language
we would get all the benefits of a well thought object system.

There is neither reference counting (=object lifetime management) nor a 
signal system built-in in C++. Python has at least the first, but
IMHO the core should still consist of a compile language not only
for performance reasons.

> Oh well. As I've already said, I'm not developing for an unstable platform
> (no, I mean GTK2 <grin/>). So I'll look at GObject, but when it's about to
> be mainstream, not sooner  
And until this happens re-invent everything which it would give you for
free ? From my experience it is even useful to look into something
which tries to address the same problem, even if it never becomes 
mainstream.

> (but this "let's make Pythonic objects in C"
> thing sure looks strange, and perhaps a bit awkward !)
I'm not concerned about it looking strange, but if it doesn't allow
fundamental functionallity by design, it's not that promising to further
work on it. (No I don't mean Python, but part of the current Dia 
Object system, respectively it's Python 'wrapability'.)

> Whoops, of course not. I mean, list of a single element (I think I used a
> lowercase "s" letter, though). This routine will have to be renamed, I
> don't want to cause any confusion on this particular topic. Mmmm... Is
> prop_list_of_single(prop) clear enough ?
The common semantic at least with COM is attaching an 's'. A Property
or many Properties (ok bad example :-). Either a collection with 0..n
objects (a list) or a single instance of an object.

[...]
> No. It's not for future unknown additions, it's because the name (type) and
> flags parameters are used by make_new_property(), which will synthetise a
> property descriptor. Some plug-ins will want to make synthetic visible
> properties, some won't. Hmmm. In this function, we can get rid of it, and
> instanciate the property through its
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 :)

> class method rather than rebuild a dynamic propdesc.
>
> If you're working on this before I remove the flags parameter, please do,
> just pass a 0 as the last argument of make_new_property() in
> object_prop_from_name_type().
>
> > > You'll have noted that object_prop_by_name is almost
object_find_prop(). If 
> > > it can't find a matching property name in the object's description, it'll 
> > > return NULL. If it can, it will (as you assumed) ask the object to fill
the 
> > > property. 
> > Why mot simply return the (ref counted) pointer of the object. 
>
> What object ? If it's the first argument of object_prop_by_name(), I don't
> see the point....
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 ?

With a real object orientated approach even ints are objects. Given the
following hierachy

DiaObject
   Property[bounding box]
  UMLObject
   Property[function list]
     Property[function]
       Property[name]
       Property[parameter list]
         Property[paramater]
           ...

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

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

> > > In this case, it's almost trivial. Simply define a set routines matching
> > >   PYTHONTYPE (*PythonFromPropFunc) (const Property *prop);
> > >
> > > (actually, something like:
> > > static PYTHONTYPE pyint_from_charprop(const CharProperty *prop);
> > > static PYTHONTYPE pyint_from_intprop(const IntProperty *prop); 
> > >   etc...)
> > Can't see how this would help clarifing the code. In the whole
> > Python plug-in there is exactly one place where the de-marshalling
> > is needed ...
>
> Simple. The demarshaling code itself (the contents of the switch) is
> garbage. And, having a switch requires you an integral type. Solution is to
> hide the garbage an replace the non-integral type by a pointer to a function
> (which is integral). Oh well, you saw my point, anyway. And there's always
> the solution of a (string)PropertyType to
> (integral)PyDiaPropTypeSwitchCookie mapping through a GHash. Probably less
> trouble, indeed.
>
> > > 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 :) ...

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

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 ?

        Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert