Re: construct-time properties and constructor

[Tim Janik <timj gtk org>]

On 14 Nov 2001, Murray Cumming wrote:

> On Wed, 2001-11-14 at 01:47, Tim Janik wrote:
> > usually construct properties correspond to values set in an object structure.
> > i don't know about all the libgnomeui constructors, but that's what e.g.
> > clist does.
> 
> That's the problem. They don't correspond to values in the object structure. libgnomeui _new functions are more like utility functions than widget constructors.

then mapping them into CONSTRUCT properties is the wrong idea in the first place.

> > this is not an API break however (except for making the _construct() functions
> > finally private) if you mark those object fields private.
> 
> Those temp_hasprogress, temp_hasstatus, and temp_interactivity fields
> would be new fields so that would break the binary API.

binary compatibility you mean.
don't worry about that for anything that depends on glib/gtk HEAD at this
point. i'm breaking binary compatibility on a daily basis up to 2.0 (ok,
not without reason, but there's no point in maintaining binary compat
during active development for the sake of just doing so).

> GnomeDruidPageEdge would need 6 of these fields. I don't think that
> people will find that acceptable.

you _could_ still use object data and unset that, but i think you're on
the wrong path anyway.

> In theory it should be possible to set each of these individually, in
> any order, but that would cause a massive increase in code just to get
> around this gobject limitation.

you got that backwards, simple rule:
  if a property doesn't _have_ to be a CONSTRUCT property, it shouldn't be one.

that is, if the property can be changed during runtime, allow the user
to do it (the fact that that's currently not possible simply by existing
API, is an indication for bad design in the first place).
also, not everything a _new() function takes is automatically a construct
property, many widgets take arguments in their _new() functions as a
convenience, and that shouldn't at all be mapped into CONSTRUCT properties.
instead it should simply be runtime changable so language bindings and GUI
builders can sanely default construct widgets and set things up afterwards.

as for GObject limitations, it's just mildly inconvenient if you have pure
CONSTRUCT_ONLY and writeonly properties. it does support this, but you'll
need some additional storage if you got more than one and need post
construction setup.
i did accept that by design for two reasons:

a) more than one CONSTRUCT_ONLY property is rarely neccessary (CTree is a
   valid example)

b) writeonly construct properties are very seldom (i don't even know
   of a good example)

as a result, cases of more than one construct property and all of them writeonly
are highly unlikely.

if you have widgets that need like 6 writeonly & CONSTRUCT_ONLY properties, you
either got a widget at hand that is fundamentally screwed by design, or you're
using wrong judgement to decide for CONSTRUCT properties.

> 
> -- 
> Murray Cumming
> murrayc usa net
> www.murrayc.com
> 

---
ciaoTJ