On Fri, 8 Dec 2006, Tristan Van Berkom wrote:
> On Fri, 2006-12-08 at 16:27 +0100, Tim Janik wrote:
> [...]
>>>
>>> i.e.
>>> gtk_stock_appoint_type ("file-chooser",
>>> MYLIB_TYPE_SEXY_FILECHOOSER);
>>
>> this is simply not possible without introducing a seperate widget type
>> naming system which we aren't planning to do (e.g. because it'd be redundant
>> to the type names). it can also not be automated because type names are not
>> known before the first use of the corresponding _get_type function.
>
> I really don't intend to start a shouting match here, I just honestly
> think you misunderstood the reason for my proposal, so please let me try
> and clarify just once.
i hope you understood the part where i said that you can't refer to
types (by name or by reference) before their corresponding _get_type
function has been called. which, for many object types, my be *never*
during a programs runtime.
> A separate naming scheme is exactly what I propose, not a widget
> naming scheme but a "stock type" naming scheme, "GtkFileChooser" is a
> GType name, the GType name is only related to the stock name insofar as
> it happens to be the default implementation of the symbolic
> "file-chooser" identifier.
there is no point in having an extra naming scheme for widget types.
we have one already: widget type names.
there is also no point in having an extra naming scheme for interface
types (what you call "identifier" above).
we have one already: interface type names.
> This abstraction would ensure that there is no confusion at the GType
> level, if we start substituting types at the GType level then types
> will inevidably be substituted underneath unsuspecting code, that
> doesnt sound safe to me at all,
we will not do that. never ever. i've adressed that in another
email already:
http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00133.html
i.e. we guarantee that:
G_TYPE_FROM_INSTANCE (g_object_new (TYPE_FOO, NULL)) == TYPE_FOO.
holds, you may assert that in your code. we will not break that guarantee.
let me use your words: we will not substitute types at the GType level.
> ensuring that there is a proper
> abstraction will ensure that types will only be substituted for
> code that was suspecting that a dynamic implementation would be
> chosen for the given task.
in that same email, i did also suggest a proper abstraction.
it's just not a string, it's a factory API that you use to create
objects conforming to a certain type, but not necessarily exactly
of that type (g_object_new would be good for that):
/* craete instance conforming to prerequisite_type */
g_factory_create (GType prerequisite_type);
/* appoint an implementaiton_type for a prerequisite_type */
g_factory_appoint_type (GType prerequisite_type,
GType implementation_type);
> Maybe you can understand a little more what my concern is, if
> you do insist on aliasing types using actual types as aliases
> for other types, would you please elaborate on why my fears and
> concerns are unfounded ?
i don't quite understand that paragraph. but i hope the above
helped you with your fears. basically, my suggestion was to *not*
change (break) existing GType/GObject API, but to create objects
with g_factory_create() which creates instances conforming to the
type passed in, but not necessarily of exactly the same type.
> Best regards,
> -Tristan
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
