On Mon, Aug 11, 2008 at 8:51 AM, Peter TB Brett <[EMAIL PROTECTED]> wrote:
> On Sunday 10 August 2008 01:25:31 Bernd Jendrissek wrote:
>> commit d1122778e91a7bbe114692a2e40c9bd539763948
>> Author: Bernd Jendrissek <[EMAIL PROTECTED]>
>> Date: Sun Aug 10 00:54:07 2008 +0200
>>
>> Split object allocation from its initialization.
>
> 1. This is in no way a "general cleanup".
All it does is make s_basic_init_object *initialize* an object as the
name suggests, without also allocating memory for it. That is left to
s_toplevel_new_object(), which just does a g_malloc(sizeof(OBJECT))
and passes that pointer on to s_basic_init_object().
> 2. I cannot in good conscience commit this patch, sorry. If we want to use
> classes, we should either use a language which supports OO methods directly
> (e.g. C++), or let someone else maintain our class system (e.g. DataDraw or
> GObject). I have no intention of helping to maintain Yet Another C-based
> class system when there are already enough out there. Ales?
I don't agree that this patch introduces any more OO-ness than we
already have. As stated above, it's only splitting existing
functionality that's all coupled together in s_basic_init_object at
the moment.
> 3. I don't see why this change is needed for opaque objects, unless what you
> mean by "opaque objects" is totally different from what I do.
typedef struct st_gschem_text_object GSCHEM_TEXT_OBJECT;
struct st_gschem_text_object {
OBJECT base;
PangoLayout *layout;
};
OBJECT *gschem_new_text(TOPLEVEL *toplevel, ...)
{
GSCHEM_TEXT_OBJECT *retval;
[snip]
retval = g_malloc(sizeof (GSCHEM_TEXT));
s_basic_init_object(retval, OBJ_TEXT);
retval->layout = pango_layout_new(gschem_pango_context);
return (&retval->base);
}
(I haven't even begun on this level of information hiding yet.)
> What you're doing here actually looks to me to make it much, *much* harder for
> us to eventually change to using an OO toolkit or C++ in the end, by *adding*
> to the huge pile of class-system-unfriendly legacy code we already would have
> to plough through. Hiding definitions/adding accessors has quite the opposite
> effect.
I don't see how that conclusion follows from the premises. This patch
splits the responsibilities of allocator and constructor, which to me
seems to make it *easier* to change to a real OO toolkit / C++. Right
now you *can't* have a statically allocated OBJECT. With this patch,
you can. [I'm NOT saying that doing so is necessarily a good idea.]
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
