[Mono-bugs] [Bug 79124][Wis] Changed - Mono.Unix.UnixGroupInfo cannot be serialized because it does not have a default public constructor

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jonpryor at vt.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=79124

--- shadow/79124	2006-08-20 17:53:58.000000000 -0400
+++ shadow/79124.tmp.9476	2006-08-20 20:19:29.000000000 -0400
@@ -1,14 +1,14 @@
 Bug#: 79124
 Product: Mono: Class Libraries
 Version: unspecified
-OS: 
+OS: unknown
 OS Details: 
-Status: NEW   
-Resolution: 
-Severity: 
+Status: RESOLVED   
+Resolution: NOTABUG
+Severity: Unknown
 Priority: Wishlist
 Component: Mono.POSIX
 AssignedTo: miguel at ximian.com                            
 ReportedBy: samjie at gmail.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -25,6 +25,48 @@
     {
         return UnixGroupInfo.GetLocalGroups();
     }
 
 This is likely by design, but I thought I'd raise the issue for
 consideration nonetheless.
+
+------- Additional Comments From jonpryor at vt.edu  2006-08-20 20:19 -------
+I'm not sure how XML Serialization would cope with
+UnixUserInfo/UnixGroupInfo/etc, given that for those types all the
+properties are read-only, not read-write, so even if there were a
+default public constructor it wouldn't help until all the properties
+were read/write as well.
+
+I suppose all this could be done, but I'm not sure what the use-case
+would be.  You can't use UnixGroupInfo/etc. to modify /etc/group, so
+being able to change these properties doesn't seem entirely useful
+(except perhaps in the XML Serialization case), and making them
+read/write doesn't seem entirely sensible if modifying them is
+effectively a useless operation.  (Says someone reading the docs: "I
+can change this value, but what does that _mean_?  Where can I use a
+modified instance?  How useful is it?")
+
+In this case, something more useful would likely be
+Mono.Unix.Native.Group, since this type publically exposes all of its
+members and has a default constructor, so this should work:
+
+    [WebMethod]
+    public Group[] GetRealGroups()
+    {
+        UnixGroupInfo[] _groups = UnixGroupInfo.GetLocalGroups();
+        Group[] groups = new Group[_groups.Length];
+        for (int i = 0; i < groups.Length; ++i)
+            groups [i] = _groups [i].ToGroup ();
+        return groups;
+    }
+
+Furthermore, since there's a public UnixGroupInfo(Group) constructor,
+you can trivially create a UnixGroupInfo object on the other end of
+the call.
+
+(As for the immediate sub-question, "why doesn't the above logic about
+read/write members apply to Group", it's because Group is within
+Mono.Unix.Native, which tries to conform as much as possible to POSIX
+conventions, and `struct group' has all members changable.)
+
+Now, if you can think of a useful usecase for read/write properties on
+UnixUserInfo/UnixGroupInfo, I'd love to see them.