This project is read-only.


Static class vs Namespace


There's a question for me.
Why did you define EnumerableContractBase and EnumerableComparingContractBase as static classes which contain several many abstract classes instead of namespace?
Closed Sep 10, 2010 at 1:22 PM by arcane_master
I think this question was fairly answered.


arcane_master wrote Sep 5, 2010 at 8:40 PM

It's because namespaces are wide open and extensible. Which these 2 classes, have subclasses that, There is no further implementation that I want for the time being. They are just helper classes to deal with a wide range of contracts, which operate in collections. :)

arcane_master wrote Sep 5, 2010 at 8:41 PM

Codeplex mails me, but it's not instant, it takes a while before a notification mail is sent ;)

digitsm wrote Sep 6, 2010 at 8:03 AM

But many other namespaces we made are small and not wide open. For example Argument.Is.Lower namespace is a very small namespace.
And about extensibility I can say those helper classes may need to be changed in the future.

I'm not satisfied with that reason, specially I've not seen any helper class used before.

arcane_master wrote Sep 6, 2010 at 3:29 PM

probably until the end of version 0.3 there will be no need for their expansion.
But as for the small namespaces we have developed. This design directly follows a pure-functional paradigm design. I have intended it to be very close to a natural language.
1) they are more readable and more writable.
2) I really mean lot's of expansion for them
3) It should be possible for to build extensions(see homepage) if we develop them as classes, how can someone add extensions to the framework?
4) these namespaces provide much better intellisense convenience.

But non of these things, are needed for just 4 classes that perform universal or existential quantification, yet.

wrote Sep 10, 2010 at 1:22 PM

wrote Feb 2, 2013 at 4:16 AM

wrote May 15, 2013 at 12:29 AM