[Geany-devel] geany-plugins depends on GIO - plugin API
elextr at xxxxx
Tue Nov 23 22:09:57 UTC 2010
On 23 November 2010 23:30, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On Tue, 23 Nov 2010 09:20:35 +1100
> Lex Trotman <elextr at gmail.com> wrote:
>> >> , but I don't really think we should add accessors for
>> >> >> all fields.
>> >> @Nick,
>> >> Well you have in the past commented negatively about making structures
>> >> visible. As you sagely said either you constrain your implementation
>> >> or yuo have to spend the effort "faking" the structure for plugin
>> >> purposes.
>> > It depends on what fields we're talking about. For a getter function
>> > for a pref, there's not much you can do if the behaviour of the pref
>> > changes or the pref is removed, the function will be no better than
>> > the field.
>> Yes semantic changes breaks the item, but ATM all you can do is break
>> the whole ABI.
>> If a field is removed from a structure the getter function may still
>> be able to compute it or get it from the new location instead of
>> another structure needing to be exposed.
> True, but we have a lot of fields in the API,
But you only need getter and setters for ones that are used, the
sooner its started the less plugins there will be, the less fields
used and the less effort involved to change things. Leave it too late
and it will be logistically impossible :-(
it seems a bit ugly to
> have tons of getter functions.
True but they can be logically grouped with one function handling
multiple fields of the same type. Or where several fields are
logically used together, one function may return multiple fields at
once. In other words the API can be tailored for the users, not
reflect the current internal implementation.
Also getters can return copies of data so that accidental (or
deliberate) sets are not possible. This is of course in line with the
direction of GTK.
>> > Getting groups of prefs is different. One solution for overridden prefs
>> > is editor_get_indent_prefs():
>> > http://www.geany.org/manual/reference/editor_8h.html#db89e1ea679531fb35ba13efa2c93eda
>> > Perhaps this would be a good approach for other pref groups.
>> Yes, as time and inclination permits.
> I have been meaning to add editor_get_prefs() as a future-proofing
> function. It would be much tidier than core functions like
> editor_get_long_line_*() which are specialized and just check whether
> to use project or global prefs.
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel