On Mon, Aug 11, 2008 at 10:08 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> 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.
Where do you get the idea that I'm forcing clients to know the size of
objects???
> My preference for object API (s_basic_init_object aside) is along these
> lines:
>
> OBJECT *o_box_new (...);
> OBJECT *o_line_new (...);
Well my more elaborate factory pattern does almost exactly this. Have
you seen it? The more elaborat s_toplevel_new_object() has a switch
on object type, which then calls to sub-methods for each specific
State object. ("State" is the pattern libgeda uses to distinguish
object types; things like LINE and PICTURE are the states. See
http://c2.com/cgi/wiki?StatePattern for more info.)
> 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;
I prefer this approach to the State pattern we have now. We don't
need dynamic classification, hence we don't need the State pattern. I
think the original reason for doing it the way we do is that Ales
didn't like the idea of shoehorning different-sized data into one
struct definition. It seems ugly to me too.
>> 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.
Why "couldn't [you] apply this patch in good conscience" then?
>> 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.
WHEN such a client app appears we can add that abstraction. I'm all
for lazy evaluation here! Do you have a specific application in mind
that would like to stash its own data in OBJECT? Maintaining its own
mapping table doesn't seem to onerous a requirement to me.
>> 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.
Ok cool.
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
