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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
