On Tue, 2008-08-12 at 17:33 +0200, Bernd Jendrissek wrote:
> On Tue, Aug 12, 2008 at 3:40 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> 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?
Rings a bell
> > 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.
I've got your code pulled into a stgit branch at the moment, so it is no
bother for me to do this as I push it. There are lots of good changes in
this series, so I'll get on with that now.
I'll produce explicit patches where there remain differences between the
committed code and your patch series, such that it ought to be easy to
apply those and re-base your stuff without any conflicts.
I hope you won't object to me leaving the TOPLEVEL argument, and the
doxygen comments about factories for such a delta. These would naturally
make sense to be added in the context of your complete factory code.
> > 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.
Damn... caught out. Now the legal department will fire me!
Seriously though, I didn't mean to come across negatively, I was perhaps
just a little caught up in "not liking" that particular example of
subclassing in gschem.
--
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
