On Mon, 2008-08-11 at 17:58 +0200, Bernd Jendrissek wrote:
> On Mon, Aug 11, 2008 at 3:34 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> > On Mon, 2008-08-11 at 13:59 +0200, Bernd Jendrissek wrote:
[snip]
> You're right, I do have a more complete factory pattern in another of
> my branches, but it met with the same resistance as the objections
> you're raising here, so for now I just made s_toplevel_new_object() a
> shorthand for g_malloc + s_basic_init_object() without smuggling in
> the rest of factory.
>
> I can follow your reasoning about the potential desireability of a
> many-to-one association between view and model objects, but I fail to
> see how this patch you're objecting to makes that any harder. You
> can't do what you want to do with a monolithic s_basic_init_object()
> either!
I don't really object, but forcing clients to know the size of objects
to allocate them isn't making things opaque either, which was the
"title" of the patch series.
My preference for object API (s_basic_init_object aside) is along these
lines:
OBJECT *o_box_new (...);
OBJECT *o_line_new (...);
those would, in the present code climate, call:
OBJCET *o_object_new (...);
to obtain their OBJECT (including allocation of memory), and could then
fill in the specific parts.
I'd not object to something like you proposed, a bit more GObject
subclassing like, e.g.:
typedef struct {
OBJECT object;
int x[2], y[2];
} LINE;
LINE *o_new_line (...);
int id;
l = o_new_line (x1, y1, x2, y2);
id = o_object_get_id ((OBJECT *)l);
I concede that you'd need to be able to manipulate / initialise an
object with pre-existing memory if you were to take this approach. This
is why g_type_create_instance() allocates memory for class instances,
then passes that to the various instance initialisers for the hierarchy
of classes this object has. Unfortunately, the code for GObject / GType
class instance construction is rather mind bending
The current libgeda way of having
typedef struct {
int id;
LINE line;
CIRCLE circle;
....
} OBJECT;
Allows a poor-man's multiple inheritance, where (for example) NET
segments can reuse the LINE object's fields. OTOH, perhaps
typedef struct {
LINE line;
char *netname;
} NET;
would be another way to cut that.
> Well let's get there first. This patch only adds options, not
> restrictions. You don't HAVE to use the now-available potential to
> specialize OBJECT.
I didn't say I was against the patch, only that I didn't like the idea
of gschem sub-classing libgeda types due to concerns over object
ownership.
[snip]
> > Some options, all ugly in some way or other:
> >
> > 1.
> > libgeda OBJECTs could provide one or more slots to stash arbitrary data
> > associated with objects. (void * / gpointer). If we allow multiple
> > "frontends", these will have to be associated by string / key / atom.
>
> I think GObject would make this easy, but from previous iterations of
> this discussion I know that idea doesn't have much traction here.
I was uneasy about libgeda use of GObject, certainly I think it's signal
mechanism might be wrong for some types notifications. There is nothing
to say we would have to use that though, we could still provide
aggregated callbacks to clients, rather than have them forced to attach
signal handlers to every object on the schematic page.
[snip]
> Heck, I wouldn't even mind if libgeda's OBJECT definition had extra
> void * members specifically for gattrib / gschem / etc. It's not like
> libgeda is the system C library with 10000 dependent packages!
True, but it would only take one client app wanting to stash data to
break this. It would have to stash it's own mapping table, or take a
guess abuse (re-use) one of the other void * pointers.
[snip]
> I guess I just don't grok why you're objecting to the separation of
> allocation + initialization, which is all that this one patch is. How
> about another (admittedly unlikely) use case: what if you want to
> initialize a statically allocated OBJECT? How would you do that now,
> *with current libgeda*?
Not sure I objected to that, more the inheritance example.
[snip]
> Current libgeda doesn't deal with these issues either (IIRC) so I
> wouldn't want to hold a patch to the higher standard of having new
> feature X (tracking changes to the image file).
No, I was just shooting off ideas.
> > Even if you had a 1:1 stash between the picture OBJECT and gschem local
> > data, you still need to solve the above problems, such as recomputing
> > the scaled pixmap to render if the picture size changes, or the filename
> > is changed.
>
> This is all doable while maintaining current behaviour. An object
> notification system might make it easier to decouple the OBJECT from
> the GdkPixbuf, but isn't strictly necessary.
So long as something gets a poke when the picture needs to be
recalculated, it should work. In current gschem / geda code, that would
traditionally be triggered from within gschem "because it knew it just
touched something which might cause the picture to change...". Object
notifications could be used later, the only concern is that whatever
code used works at least as well as what we have now with GdkPix??? in
libgeda.
Best wishes,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
