This project is read-only.

Complying to the .NET Design Guidelines

Topics: User Forum
Oct 19, 2006 at 7:11 PM
Hi there!
This seems like a very good project and a solid foundation. However most of the classes are prefixed with a G for the name of the library. The classes are already contained in the library's namespace, so prefixing shouldn't be necessary and they are also disallowed for CLS compliance. I think a part of the project's succes would be to comply to the CLS standard in order to gain better acceptance. I'm working on a generic list wrapper constrained to reference types (class) that seeks to add references in constant time for real-time purposes, which might fit into this framework.
Oct 20, 2006 at 12:32 PM

Thanx a lot for your consideration and concern in Generics.Net. Yours is a very valid point to make library CLS compliant. Considered. However even though I personaly dont like putting any kind of prefixes to class names, I did in Generics.Net for a good reason. Reason is code maintenability. Suppose someone uses Generics.Net class, for example SinglyLinkedList. This class is not present in the current version of .net framework, however you can not guarantee that in the future verion of .Net it will remain absent. If people at microsoft think that it is required then they will incorporate this class. And during that time client code will stop functioning. Client code will have to be changed. Keeping this scenario in mind I have put G prefix for classes and IG prefix for interfaces. Apartfrom that I have not come accross any document which says putting such kind of prefix to class is non cls compliant.

I set CLSCompliant assebly level attribute to True. I got approx 5 warnings. None of the warning said G should be removed as prifix... So I think its okay... But yes. Thanx for your sugession to make it as CLS Compliant. Next buid will be complying to the design guidelines :) and will not throw warnning with CLSCompliant set to true.

And yes I would like to hear more from you and would surely like to see your list wrapper class...

Thanx a Lot
-- Aamir
Oct 21, 2006 at 3:11 PM
Thanks for your positive response to my query, I know it can be touchy.
Anyway, I'd still insist that omitting prefixes on public types won't arise the possibility of a possible compability break if Microsoft should decide to implement some or more of similarly named types - they'd be stored in the System namespace anyway, that's what the namespaces are for, the CIL code always refer types through fully qualified names. However you do as you feel best.

And my listwrapper, here's how it basically works:
The aim is to add new references regardless of current count of contained references. I believe a Remove method on a traditional list actually removes that item from a list, and that could be a performance issue - splitting the list and padding rightmost items one step left. Imagine a saturated list of various references and a reference is about to be removed. This list will set that item to null, and save the index of the newly empty item in a queue (which is at least as big as the internal array. The next time a reference is added, an index is fetched from the queue and the reference is placed at that item. A few problems arise if one tries to implement this with the IList interface, because the list can no longer support methods such as Insert, because it would break the queue's index information. Hence the list is only useful if adding and removing items in constant time (suitable for real-time), and items only need to be read, not set (setting a null item would break the validity again). I'll come back to this after I have had time to implement more of the code and done some profiling on it. It comes at the cost of almost the double memory allocation, but always manipulation in constant time.
Oct 21, 2006 at 3:12 PM
EDIT: The aim is to add new references * in constant time * regardless of current count of contained references.
Oct 27, 2006 at 8:19 AM
I doubt it would generate warnings just compiling. Run it through FxCop, and I'm sure it will generate warnings.
Oct 31, 2006 at 2:35 AM
Sorry I was on vacation so could not reply... I have got a rough idea about list wapper, it will clarify more if you share your code with me once its ready.

Thanx a lot
Oct 31, 2006 at 2:43 AM
Okay I will compile with FxCop and will change Generics.Net accordingly... Because project is at initial stage we can do it.

Thanx a lot for your concerns.
Nov 11, 2006 at 2:18 AM
Nope... Even FxCop didnt throw any warning for G prefix.... Okay, What I am going to do is I will start a discussion whether we need to put G prefix or not... Lets community decide this...

Sounds reasonable?
Nov 14, 2006 at 4:14 AM
I agree with the opinion to comply to .Net design guidelines. Idea of prefixing "G" before your types/interfaces goes against the type naming guidelines of .Net. And as mentioned earlier, this is one of the purpose that namespaces solve. If collision is the only issue that you are trying to solve, then I would suggest you drop "G" prefix.

My mantra in such scenario is to think from user's perspective. If I am using your library, I would like to do something like Generics.Algorithms.Sorting.BubbleSort and not Generics.Algorithms.Sorting.GBubbleSort. Imagine if every third-party libraries use prefixes for their types, how ugly the code would look and how difficult it would be to understand code written by someone else.

Just my two cents for what they are worth :-)


PS: I am yet to look at the code so you can choose to completely ignore what I said above
Nov 14, 2006 at 5:58 AM
It seems many of you are against putting "G" prefix. As I said even i dont like but I did it for a good reason. This is a people's library, if majority of you are not comfortable with that... It must be dropped. In the next version of Generics.Net 0.3.1 Alpha you will see the change....

Thanx a lot folks for all your valuable comments....

Do comments - Its your library and we all togather need to improve it...

- Aamir
Nov 14, 2006 at 6:01 AM
This discussion has been copied to Work Item 5622. You may wish to continue further discussion there.