On 23 November 2010 23:30, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 23 Nov 2010 09:20:35 +1100 Lex Trotman elextr@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#db89e1ea679531fb35ba13e...
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.
Agree.
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel