On Tue, Aug 12, 2008 at 3:40 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> In that specific inheritance example, libgeda would have to divulge how
> big its own OBJECT structure is, which is somewhat contrary to the type
> being opaque. If the OBJECT type were to be made opaque outside of
> libgeda, gschem couldn't subclass it in that way, it would have to:
I agree that knowing the size breaks the opacity somewhat. The size
doesn't need to be exported by making the struct definition visible to
the client code though; it could be size_t
s_basic_get_object_size(void) { return sizeof (OBJECT); }. I'm trying
to remember how GObject does it... I think the size of class instances
is recorded in the GType structure?
>> > 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.
>
> You mean using union types, or just providing every field for every type
> of object within OBJECT?
Both. I think the latter is even uglier. Unions at least have
pragmatism in their favour.
> s_toplevel_new_object () probably isn't the best name. It doesn't
> operate on a TOPLEVEL, so it shouldn't be s_toplevel_..., and should not
> live in s_toplevel.c. Why not call it s_basic_new_object () and place in
> s_basic.c, for consistency with the old code.
>
> I see TOPLEVEL was added as a parameter to s_toplevel_new_object ()
> either. Is that just for consistency with other API calls? Why not leave
> it off, since it isn't used. It keeps down the delta against how
> s_basic_init_object() used to be called.
The signature is exactly what it is in my more complete factory. You
need access to the factory to create its products, and I could have
either used a global variable (yuck) or kept a pointer to it in
TOPLEVEL. Having the same signature reduces the delta between the
opaque objects branch and the abstract symbols branch.
Unless you're doing wdiff, the delta is +1-1 either way... the name of
the called function is already changed.
> Talk of object factories, and [...] comment is only serve to obfuscate
> what the patch does with "compsci" terms which not everyone (myself
> included) will always grok.
Well I like the pattern-ish language: it's concise and unambiguous.
I'll see what I can do when I next have some time for historical
revisionism.
>> The holy grail is opaque objects. The first non-trivial use of an
>> abstract factory might be to sequester knowledge of GdkPixbuf into gschem
>> and out of libgeda. Conceptually, gschem would override the abstract
>> factory's ::new_picture() method, returning a bigger structure than just
>> PICTURE:
>
>> typedef struct st_gschem_picture GSCHEM_PICTURE;
>> struct st_gschem_picture {
>> PICTURE base;
>> GdkPixbuf *original_picture;
>> GdkPixbuf *displayed_picture;
>> /* Maybe some other stuff too. */
>> };
>>
> Moving GdkPixbuf into gschem is a laudible goal, but more related to
> abstraction / delegation / clear separation of code. It doesn't rely on
> anything being opaque at all. Can we drop that comment?
Geez, is this a big impersonal corporation where a more conversational
style in commit messages is verboten and only what the legal
department approves can be checked into the intellectual property? I
thought I was illustrating by example *why* I was making the change.
> PS.. unless we can come up with a solution for printing, GdkPixbuf will
> have to stay in libgeda, since that is where the postscript output code
> lives. :(
Oh right, I forgot about that. Bummer.
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
