Miguel noticed yesterday that Mono.Unix currently has over 270 [Obsolete] declarations. Things will be changing soon, so here is the what, why, and questions about possible future changes (see the end for questions under consideration -- feedback is appreciated).
Mono.Unix was originally conceived as a "proper" wrapping over POSIX, correcting many of the issues that Mono.Posix had regarding enumeration handling (i.e. it only had a unidirectional mapping but was using it as if it were bidirectional), providing a stable ABI (use "ulong" for size_t instead of "uint" or "UIntPtr" to be portable between ILP32 and LP64 systems), and being closer in spirit to POSIX (Mono.Posix.Syscall.GetHostName?). Mono.Unix then provided high-level wrapper classes such as UnixStream for better integration with the rest of the .NET framework. Unfortunately, both of these were placed into the same namespace, so if you just have a `using Mono.Unix;' statement, there are over 100 types available, and from browsing Monodoc the most "interesting" types don't show up until the 36th entry in Monodoc (because lots of helper structs and enumerations show up first alphabetically). For this and other reasons, I'm splitting Mono.Unix up into two namespaces: Mono.Unix for the high-level types, and Mono.Unix.Native for the low-level types. See this for more information: http://www.jprl.com/Blog/archive/mono/2005/Sep-20.html The namespace split isn't the only change. I've been reviewing the current Mono.Unix API, and will be making a number of changes after the next release, for the following reasons: - CLS Compliance: CLS compliance is now a goal for Mono.Unix, which requires that a number of types change. For example, User IDs (uid) and Group IDs (gid) will become `long' (currently they're uint). Not all members will be CLS compliant -- there will be a number of members explicitly present to provide a bridge to Mono.Unix.Native, so 100% CLS compliance isn't possible -- but it will be better than today. - Consistency: members returning ID types (pids, uids, gids, etc.) aren't always immediately apparent. For example, what's the type of UnixEnvironment.User? Previously it was uint, which isn't particularly helpful. It's been [Obsoleted] by RealUserId, which makes it clear that it's a uid, and a RealUser property will be added which returns a UnixUser instance. The same will be done for UnixFileSystemInfo.OwnerUser (added OwnerUserId for the uid, and after the next release OwnerUser will return a UnixUser instance, not a uid). - Complexity: I was apparently on crack for some things, like the 36 methods in UnixFile for AdviseNormalAccess(), AdviseSequentialAccess(), AdviseRandomAccess(), AdviseNeedAccess(), AdviseNoAccess(), AdviseOnceAccess(), and their overloads. These have been replaced with methods taking an enumeration. Originally I was trying to avoid adding new enumeration types, but I now view avoiding them as a mistake. After release 1.1.10, I will be changing any [Obsolete] members which need to have their return/property type changed. Anything that exists purely as overloads may live longer, but most [Obsolete]s should be removed by 1.2. The types in Mono.Unix/Syscall.cs and Mono.Unix/Stdlib.cs will be stay for 1.1.11 (if it exists), but will be removed for 1.1.12 or 1.2 (whichever comes first). Questions: 1. For UnixFileSystemInfo, I "split up" FilePermissions (Unix mode_t) into 3 sub-parts: FileTypes (directory, regular file, etc.), FileAccessPermissions (UserRead, GroupRead, etc.), and FileSpecialAttributes (SetUserId, SetGroupId, Sticky). Should FileSpecialAttributes be separate, or should it be part of FileAccessPermissions? 2. Do I really need so many wrapper classes? UnixFile, UnixDirectory, UnixGroup, and UnixUser are all wrappers over their associated XxxInfo types, and most of their methods are effectively: public static RetType GetSomething (Foo foo) { return new XxxInfo (foo).Something; } I did this because that's what System.IO does, but (1) it's a lot of duplication, and (2) I see that Microsoft didn't continue this practice for System.IO.DriveInfo (there is no System.IO.Drive, at least not the last time I checked). Would anyone object to my removing these wrapper types, and move the useful static methods into the associated XxxInfo classes? I think this would help with the API cleanup, as there'd be fewer classes to look at (and document!). - Jon _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list