After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644330 - PostalAddressOwner should use FieldDetails instead of PostalAddress.types
PostalAddressOwner should use FieldDetails instead of PostalAddress.types
Status: RESOLVED WONTFIX
Product: folks
Classification: Platform
Component: libfolks
git master
Other Linux
: Normal normal
: folks-0.5.1
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2011-03-09 18:38 UTC by Travis Reitter
Modified: 2011-04-26 15:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Travis Reitter 2011-03-09 18:38:07 UTC 
It looks like we didn't quite update PostalAddressOwner to fit the conventions of our newer interfaces before merging.

We should change

-  public abstract List<PostalAddress> postal_addresses { get; set; }
+  public abstract List<FieldDetails> postal_addresses { get; set; }

and remove PostalAddress.types.
Comment 1 Travis Reitter 2011-03-09 18:58:13 UTC 
On the other hand, this will require that we change FieldDetails.value to a GLib.Value and make PostalAddress subclass GLib.Value, which will mean a whole lot of other breakage.
Comment 2 Philip Withnall 2011-04-23 21:09:35 UTC 
As suggested on IRC, I think a more elegant solution would be to make FieldDetails abstract and have things like PostalAddress be subclasses of FieldDetails which add their own value property (with the appropriate type). That's turning into quite a heavyweight API though.
Comment 3 Travis Reitter 2011-04-26 15:51:14 UTC 
(In reply to comment #2)
> As suggested on IRC, I think a more elegant solution would be to make
> FieldDetails abstract and have things like PostalAddress be subclasses of
> FieldDetails which add their own value property (with the appropriate type).
> That's turning into quite a heavyweight API though.

Yeah, I'm not sure it's worth it. GValue is a pain to use in C, so I'm fine with closing this.