Method Name Suggestion: Validate a Poor Choice?
Mike Hofer
intentionally, but I *think* it was appropriate given the nature of my
question.
I'm working on an open source code library to help automate and clean
up parameter validation code. It's almost ready to go into open beta.
But one last little glitch is holding me up, and that would be the
name of the factory class that serves as the entry point into the
library: Validate.
Essentially, when you invoke the methods in this thing, your code
looks like this:
Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz")
This works beautifully so far, but it becomes problematic when you use
it from ASP.NET pages, where a Validate method is already defined. As
you can imagine, the compiler thinks you're trying to invoke the
Validate method on the page; so invoking one of the That methods on
the Validate class (a factory) makes no sense.
You can get around it by using an alias with the namespace and change
to Verify or something:
using NValidate.Framework.Validate = Verify;
However, this creates a lot of manual work for the developer. It would
seem that the onus is on *me* as the publisher of the library to come
up with a solution. I mean, the whole POINT of this thing is to make
our lives easier.
So here's what I'm thinking: I could change the name of the Validate
class to Verify. That gets around the whole problem with ASP.NET
pages. That leaves only the following real concerns:
1.) Verify, like Validate before it, is a *very* common word. It's
likely that it will conflict with existing method names.
2.) The product name is NValidate. (Yep, just like NUnit, NCover,
NAnt, etc.) There might be a perceived disconnect between the product
name and the primary entry point into the library itself. (Validate
vs. Verify.)
3.) The classes that validate parameters are called validators. Again,
it's the same disconnect.
My questions for you folks with far greater experience than myself
are:
1.) Is the difference between the product name and the method name
that critical?
2.) Is there a better way to name the factory class?
I'm pretty desperate for input here as this is a one-man project so
far. Any help you big brained-folks can provide will be greatly
appreciated. For those who are interested, I can provide links to the
materials and the source code under development. (I won't spam the
boards--I'm not marketing something here. I'm trying to solve a
problem, and I don't know the best way to do it.)
Again, thanks for your help.
IfThenElse
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192125581.7...@v3g2000hsg.googlegroups.com...
clintonG
CleanMyRoomValidation etc... its a judgment call to avoid becoming verbose
but the other extreme is terse naming which does not communicate or implies
unintended meanings.
Explicit Naming = Elegant Code
-
<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192125581.7...@v3g2000hsg.googlegroups.com...
![Nicholas Paldino [.NET/C# MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Nicholas Paldino [.NET/C# MVP]
Personally, I think that you should name Validate Validator. Generally,
for my objects, I like the type names to be nouns (not verbs) and the
methods to be verbs.
I know it kind of breaks the flow you are trying to achieve, but it
would work.
--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192125581.7...@v3g2000hsg.googlegroups.com...
Mike Hofer
> Be more explicit with your naming, FactoryClassValidation,
> CleanMyRoomValidation etc... its a judgment call to avoid becoming verbose
> but the other extreme is terse naming which does not communicate or implies
> unintended meanings.
>
> Explicit Naming = Elegant Code
>
> -
> <%= Clinton Gallagher
> NET csgallagher AT metromilwaukee.com
> URLhttp://clintongallagher.metromilwaukee.com/
>
>
> - Show quoted text -
Actually, the source code itself is pretty explicit. The API, however,
provides an implementation of fluent interfaces.
For example, here are some of the class names in the
NValidate.Framework namespace:
ValidatorBase
ValueTypeValidatorBase (derives from ValidatorBase)
ObjectValidatorBase (derives from ValidatorBase)
BooleanValidator (derives from ValueTypeValidatorBase)
StringValidator (derives from ObjectValidatorBase)
ArrayValidator (derives from ObjectValidatorBase)
ConnectionValidator (derives from ObjectValidatorBase)
The method names on the validator classes are designed to help you
validate parameters using a clean, simple interface. The idea was born
out of refactoring and unit testing. (In other words, I ripped off
NUnit's Assert.That interface to refactor my parameter validation
code.)
The idea is that you write this:
Validate.That(foo, "foo").IsNotNullOrEmpty();
Instead of this:
if (null == foo)
throw new ArgumentNullException("foo");
if (string.Empty == foo)
throw new ArgumentException("Empty strings not permitted.", "foo");
Samuel R. Neff
Validate and Verify are both very common words and could easily cause
conflicts (as you noticed) and also don't really portray exactly what
is being validated.
I think NValidate would be a good choice (especially since "nv" is
very unique in intellisense and easy to type).
Normally I believe that classes should be nouns but I see where you're
going with the constraint type language, similar to the new NUnit
stuff, so using a verb here is fine in my opinion.
Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Thu, 11 Oct 2007 17:59:41 -0000, Mike Hofer <kchig...@gmail.com>
wrote:
>Please forgive the cross-post to multiple forums. I did it
>intentionally, but I *think* it was appropriate given the nature of my
>question.
>
>
Mike Hofer
> Validate and Verify are both very common words and could easily cause
> conflicts (as you noticed) and also don't really portray exactly what
> is being validated.
Agreed.
However, the library is well documented (both internally and
externally) so that it shouldn't be difficult to understand. Anyone
familiar with NUnit should be able to figure out what NValidate code
is doing relatively quickly.
> > I think NValidate would be a good choice (especially since "nv" is
> very unique in intellisense and easy to type).
It would, indeed, except that it would require an intentional
deviation from a naming standard. Then again, if that deviation is
well-documented, and for a well-thought out reason, it's acceptable.
> Normally I believe that classes should be nouns but I see where you're
> going with the constraint type language, similar to the new NUnit
> stuff, so using a verb here is fine in my opinion.
There is a precedent: the Assert class in NUnit. The big difference
between NUnit and NValidate, I think, is that NValidate implements
fluent interfaces to optimize its performance. Since NValidate might
perform multiple tests on a single parameter, and the tests are
encapsulated in a validator object, I didn't want to have to recreate
the validator object over and over again; so the validation methods
return a reference to the validator itself (unless, of course, one of
them fails, in which case it throws an exception).
> Sam
Thank you for your input!
Nicholas Paldino [.NET/C# MVP]
Here is another thought. Why not use a class with a static member
Validate and then have an internal class, or singleton hanging off the
parent class, like so:
NValidate.Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");
It would require one level of indirection, but it could be seen as an
entry point into the syntax you want.
--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192130388.5...@57g2000hsv.googlegroups.com...
Mike Hofer
<m...@spam.guard.caspershouse.com> wrote:
> Mike,
>
> Here is another thought. Why not use a class with a static member
> Validate and then have an internal class, or singleton hanging off the
> parent class, like so:
>
> NValidate.Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz");
>
> It would require one level of indirection, but it could be seen as an
> entry point into the syntax you want.
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - m...@spam.guard.caspershouse.com
>
>
> - Show quoted text -
I'm thinking about this suggestion, because it has merit. But I'm
wondering if this isn't possible just using namespace resolution.
Thoughts?
Brian Gideon
Neat concept by the way.
I agree that this is a case where a verb name actually makes more
sense. But, along the same lines as Nicholas' suggestion and using a
noun-verb combination...
Validator.Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");
or
Validator.Demand.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz");
...where Validator is a static class and Validate or Demand is a
singleton.
Nicholas Paldino [.NET/C# MVP]
I don't think that there is a good solution using namespaces, as you can
always put a using statement in the top of the code which will end up
causing the ambiguity that you indicated in your initial email. With a
static property/class/method, you will always need the type name as an
"anchor" from which you can hang anything off that you like.
--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192133081....@o80g2000hse.googlegroups.com...
Mike Hofer
Thanks. :)
> I agree that this is a case where a verb name actually makes more
> sense. But, along the same lines as Nicholas' suggestion and using a
> noun-verb combination...
>
> Validator.Validate.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz");
>
> or
>
> Validator.Demand.That(foo,
> "foo").IsNotNull().StartsWith("bar").EndsWith("baz");
>
> ...where Validator is a static class and Validate or Demand is a
> singleton.- Hide quoted text -
I *really* like Demand as a method name. If I had to change the verb,
Demand.That() is really nice. It's nominally shorter, and it's a stong
word (stronger than Validate, in my opinion). (I'm always looking for
ways to write less code, not more. Fewer characters is a good thing,
so long as it doesn't sacrifice code clarity or quality.)
If I had to choose a noun to prefix it with, I think I'd want
something equally as strong. What about ParamRule?
ParamRule.Demand.That()
This has the advantage of making it clear that we're working with
parameters. So we end up with this:
ParamRule.Demand.That(foo, "foo")
.IsNotNull()
.StartsWith("bar")
.EndsWith("baz");
instead of this:
Validate.That(foo, "foo")
.IsNotNull()
.StartsWith("bar")
.EndsWith("baz");
>From a C# perspective, that's fine; VB developers might balk at it.
Thoughts? Suggestions?
Mike Hofer
<m...@spam.guard.caspershouse.com> wrote:
> Mike,
>
> I don't think that there is a good solution using namespaces, as you can
> always put a using statement in the top of the code which will end up
> causing the ambiguity that you indicated in your initial email. With a
> static property/class/method, you will always need the type name as an
> "anchor" from which you can hang anything off that you like.
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - m...@spam.guard.caspershouse.com
>
>
> - Show quoted text -
Good point; I hadn't thought of that.
The current class library uses the class factory (Validate) as the
very anchor point you mention. It just has that unfortunate name, and
needs something to distinguish it from the Validate method on the Page
class. Brian Gideon may have handily solved the problem by suggesting
the *very* attractive "Demand" as an alternative name for it. But I
may still offer the intervening container class as a way to get to it
for those odd scenarios where you run into naming conflicts.
It would be nice if you could omit the container class in the
resolution if you didn't need to use it. For instance, in an ASP.NET
page, you could say ParamRule.Demand.That(), but outside of pages, you
could just say Demand.That(). Having said that, I'm all for brevity in
the code, but not at the expense of clarity; if having two different
ways to access the validators would generate confusion, I'd likely
just enforce a universal interface and be done with it.
Keep that feedback coming! It's truly appreciated!
IfThenElse
ThouShell.beEqualTo().NotBeNull().StartsWith("bar").EndsWith("baz");
"Mike Hofer" <kchig...@gmail.com> wrote in message
news:1192135295.0...@o80g2000hse.googlegroups.com...
Scott M.
"Nicholas Paldino [.NET/C# MVP]" <m...@spam.guard.caspershouse.com> wrote in
message news:umyDzSDD...@TK2MSFTNGP02.phx.gbl...
> Mike,
>
> Personally, I think that you should name Validate Validator.
> Generally, for my objects, I like the type names to be nouns (not verbs)
> and the methods to be verbs.
I agree and I believe it's better OO to do so. Classes get noun names,
methods get verb names, properties get adjective names, and events get
verb/tense names (ie. Validated, Validating).
Ultimately, someone has to use your API and the more intuitive your
classes/class member names are the less chance the API will be used
incorrectly.
-Scott M.
Mike Hofer
> "Nicholas Paldino [.NET/C# MVP]" <m...@spam.guard.caspershouse.com> wrote in
>
> > Mike,
>
> > Personally, I think that you should name Validate Validator.
> > Generally, for my objects, I like the type names to be nouns (not verbs)
> > and the methods to be verbs.
>
> I agree and I believe it's better OO to do so. Classes get noun names,
> methods get verb names, properties get adjective names, and events get
> verb/tense names (ie. Validated, Validating).
>
> Ultimately, someone has to use your API and the more intuitive your
> classes/class member names are the less chance the API will be used
> incorrectly.
>
> -Scott M.
I both agree and disagree with you.
On the one hand, yes, OO principles should be adhered to whenever
possible, *when it makes sense to do so.*
However, I also believe that when it makes sense to deviate from rigid
practices, you should pick up that hammer and shatter that crystal
goblet with gusto provided that you can be reasonably sure that you
can explain your reasoning and justify yourself.
If I thought for one minute that my users wouldn't be able to
comprehend the use of this API, or its proper application, I wouldn't
be writing it this way. But my target audience is users of NUnit and
folks familiar with that particular paradigm. They're use to seeing
code like this:
Assert.AreEqual(250.00F, destination.Balance);
Consequently, parameter validation code like that provided by
NValidate shouldn't be difficult to grasp, understand, or debug:
Validate.That(balance, "balance").IsEqualTo(250.00F)
In this case, both frameworks use a *verb* as the entry point because
it simply makes sense to do so, rigid OO practices be damned. A
careful scrutiny of the source code, however, shows that in all other
respects, I've worked very hard to respect OO practices and haven't
violated them. The use of a verb as the entry point in this case is
entirely in supportof fluent interfaces; and was chosen specifically
for that reason. It's well documented, and I believe the appropriate
choice in this case.
Cor Ligthert[MVP]
In my idea is this not validating
Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz")
Maybe it is my poor Dutch English dialect, however I should call this
"Check".
Cor
Brian Gideon
> I agree and I believe it's better OO to do so. Classes get noun names,
> methods get verb names, properties get adjective names, and events get
> verb/tense names (ie. Validated, Validating).
>
> Ultimately, someone has to use your API and the more intuitive your
> classes/class member names are the less chance the API will be used
> incorrectly.
>
> -Scott M.
Typically I would agree, but I think this is an exceptional case.
There's no sense it forcing something if doesn't "feel right".
Brian Gideon
> If I had to choose a noun to prefix it with, I think I'd want
> something equally as strong. What about ParamRule?
>
> ParamRule.Demand.That()
>
> This has the advantage of making it clear that we're working with
> parameters. So we end up with this:
>
> ParamRule.Demand.That(foo, "foo")
> .IsNotNull()
> .StartsWith("bar")
> .EndsWith("baz");
>
I like it. It's better. What about Parameter instead of ParamRule?
Also, other than Demand what other properties or methods might the
ParamRule have? It doesn't feel right to create this static class
that only has one member. I'm backtracking a little bit here. I'm
thinking that having a class named Assert worked well for NUnit so why
not just Demand or some other clever, but acceptable name that doesn't
conflict with any other class that might be commonly used.
> >From a C# perspective, that's fine; VB developers might balk at it.
>
> Thoughts? Suggestions?
One thing that is frustrating for me is that VB keywords use Pascal
casing. That makes it very easy to inadvertantly use a VB keyword in
the public interface (because class library authors typically use
Pascal casing for class, method, property, etc. names) forcing VB
programmers to use [] to escape the name in some cases. That's
another thing you have to be aware of when choosing names.
Mike Hofer
Demand (formerly Validate) is a class factory; it's a singleton, and
so each of its methods simply returns a different validator class
based on the argument list. Like so (watch out, real NValidate code
coming!):
using System;
namespace NValidate.Framework
{
public sealed class Demand
{
public static ArrayValidator That(Array parameterValue, String
parameterName)
{
return new ArrayValidator(parameterValue, parameterName);
}
public static BooleanValidator That(Boolean parameterValue, String
parameterName)
{
return new BooleanValidator(parameterValue, parameterName);
}
public static ByteValidator That(Byte parameterValue, String
parameterName)
{
return new ByteValidator(parameterValue, parameterName);
}
}
}
(Obviously, we're not dealing with rocket science, here. =D)
Given that it's purely a class factory, and the XML documentation
comments (which I snipped for brevity) make that pretty clear, my
reservations about it having only one distinct method with multiple
overloads are not substantial enough to warrant a complete rewrite at
this time.
Now, having said that, if someone can provide a better solution that
will be more extensible (I'd *really* like for developers to be able
to dynamically invoke their own validators at some point), I'm all
ears. The class factory design you see above is pretty restrictive;
it'll work for the first iteration, and it's extensible from the point
of view that users will have the source code and can extend the
library themselves. BUT...
What would be nice is if a 3rd party DLL could create a class that
implemented an interface or extended a base class or something and
passed that to NValidate for invocation. That would allow end-users to
write more complex test sets, and possibly more efficiently than
NValidate can execute them individually. I've figured out the idea
behind a basic interface or a function pointer approach, but the
problem arises where users want to pass *more* information to the
custom validator. I could use some help figuring out how to do that.
Mike Hofer
>
> > If I had to choose a noun to prefix it with, I think I'd want
> > something equally as strong. What about ParamRule?
>
> > ParamRule.Demand.That()
>
> > This has the advantage of making it clear that we're working with
> > parameters. So we end up with this:
>
> > ParamRule.Demand.That(foo, "foo")
> > .IsNotNull()
> > .StartsWith("bar")
> > .EndsWith("baz");
>
> I like it. It's better. What about Parameter instead of ParamRule?
Oh, and Parameter it is. :)
Mike Hofer
>
> - Show quoted text -
Okay, I did a lot of testing in the code base today, and I'm having
some difficulty with the end results of the tests. The end results of
the test code in NUnit seem to be defeating one of the key tenets of
the design ("Less code, not more"). For example:
[Test]public void ThatPasses()
{
Validate.That(m_arrayOfIntegers, "m_arrayOfIntegers").IsNotNull();
Parameter.Check.That(m_arrayOfIntegers,
"m_arrayOfIntegers").IsNotNull();
}
It's also presenting another design problem from the point of view
that the Parameter class itself has one member: the Check property,
which returns a reference to the class factory. That's its sole reason
for existence. I'm having a hard time justifying that.
So, I'm back to the drawing board. I'm pretty sure I'm going to drop
the container class. On the other hand, I'm sticking with Demand in
lieu of Validate. I actually considered Check, and tested it. But
Check doesn't carry the same weight that Demand does; Demand carries a
psychological weight to it that I think is better suited to what I'm
trying to do.
So, no wrapper class, but I will change it from Validate to Demand.
Demand.That(foo, "foo").IsNotNull().StartsWith("bar").EndsWith("baz");
Unless anyone else can think of something really stunning, thanks for
all your input and help. It's meant an awful lot to me.
Paul E Collins
> I agree and I believe it's better OO to do so. Classes get noun
> names, methods get verb names, properties get adjective names, [...]
I think property names are more frequently nouns (e.g. height, colour,
index).
Eq.
Ngan Pham
Juan T. Llibre
Look for the release announcement at :
Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Ngan Pham" <nga...@matbao.com> wrote in message news:uLLS7s$DIHA...@TK2MSFTNGP05.phx.gbl...
Mike Hofer
>
> - Show quoted text -
The Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.
Just don't expect to be able to sue me if it blows your foot off. :)
The web site's been expanded to include the API reference and
community forums. You can find them at http://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)
Thank you for your interest!!
Brian Gideon
> The Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
> BE PRODUCTION READY CODE. It's being released for public review.
> However, since it's being released under the GPL, you're free to fix
> any bugs you find and run with it.
>
> Just don't expect to be able to sue me if it blows your foot off. :)
>
> The web site's been expanded to include the API reference and
> that the docs have some holes in them; they'll be fixed tonight as
> well. (I'm posting this from work.)
>
> Thank you for your interest!!
Mike,
I downloaded it and gave it a brief test drive. The API is pretty
much how I envisioned it would be. I really like how similar the
"feel" is to NUnit's API. I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.
You know...it's use cases might not just be limited to parameter
validation. I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc. I'm not sure how narrow of a scope you want to keep
for the project though.
Brian
Brian Gideon
> BE PRODUCTION READY CODE. It's being released for public review.
> However, since it's being released under the GPL, you're free to fix
> any bugs you find and run with it.
>
> Just don't expect to be able to sue me if it blows your foot off. :)
>
> The web site's been expanded to include the API reference and
> that the docs have some holes in them; they'll be fixed tonight as
> well. (I'm posting this from work.)
>
> Thank you for your interest!!
Mike,
Mike
news:1192734561.3...@v23g2000prn.googlegroups.com...
Thanks VERY much for downloading and test-driving the framework.
My goal in writing NValidate is to make it easier to write higher quality
software by writing less code without sacrificing clarity or significantly
impacting performance. (I would venture to say that that statement, in a
nutshell, summarizes the purpose of NValidate.)
If extending it to support additional validation outside of method and
property validation satisfies that rule, I'm game. But the scope of the
product must be reasonably constrained. There's another additional rule: The
end users should never be asked to use something that's so complex that they
can't reasonably explain it. If *we* can't explain what it's doing or how it
works, forget it. In my book, that's an unsafe operation. :)
Regarding the dropping of the ParamRule "domain": I'm very pleased that it
was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
an entire class with one property on it:
public sealed class ParamRule
{
public Demand Demand {
get { return Demand; }
}
private ParamRule()
{
}
}
It seemed rather idiotic to me. Further, if you were going to do something
like that, you might as well have named it "I", and change Demand to Insist:
I.Insist.That(dateOfBirth, "dateOfBirth").IsNotInFuture();
Now that's a truly fluent interface, but it's approaching the absurd, just
to satisfy OO purists. In the end, I decided to leave it out, and save the
overhead. I'm really happy with the way the API flows now, and aside from a
few known issues that I've got slated for resolution, I'm confident that
it's going to be a pretty decent product once it's finished.
I do have one concerned raised by a member on the NValidate forums. He's
concerned that creating lots of objects just to validate parameters might
negatively impact the application's performance. I was hoping you might
offer your opinion on that, now that you've had an opportunity to look at
it.
Before you do though, I'd like to offer the following points:
1. I specifically split the validators into two groups, derived from two
different base classes so that boxing and unboxing would not occur when the
value of a value type parameter was cached within the validator itself.
2. Only one validator is created per parameter. If the caller chains the
tests together (as intended), the same validator is reused over and over
again.
3. Each validator only holds two pieces of information: the name of the
parameter (a string), and the value of the parameter. So we're not keeping
lots of data in memory.
4. The validator's test method must conduct its test and either throw an
exception if the test fails or return a reference to the validator. The
tests are written to be as fast as possible. (If they're not written that
way, that's a defect and needs to be resolved.)
5. I avoided reflection and attribute-driven solutions because they tend to
be slower. (Reflection requires loading and parsing an assembly's manifest;
attribute-driven solutions require reflection.) The sole case where I use
reflection is in the IsValid test on the EnumValidator.
So those are the performance-measures I took when designing the framework. I
realize that we're going to have to just test the thing and measure the
impact and provide raw numbers at some point. But my gut feeling is that the
number and complexity of the objects were creating is so small compared to
the number and complexity of other objects created throughout the lifetime
of an application (or even within a method) that the impact will be minimal.
Again, I fully agree that testing must be done to prove this and fix it if
it's not true.
I do have a solution in mind if we think this will be a serious problem. I'd
just like to get a feel for whether or not it's worth redesigning the
framework or not.
Brian Gideon
> I was hoping you might
> offer your opinion on that, now that you've had an opportunity to look at
> it.
I'm taking a short vacation this weekend so I'll follow up with a post
in a couple of days when I get more time.
Brian Gideon
> was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
> an entire class with one property on it:
>
I couldn't agree more.
Typically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with. Furthermore, based on what you
just said, there's only one object per parameter. So I agree that
object creation would be small relative to the rest of the developers
application. The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.
> I do have a solution in mind if we think this will be a serious problem. I'd
> just like to get a feel for whether or not it's worth redesigning the
> framework or not.
Like you said, do some testing. My hunch is that it won't be that big
of an issue. Even if it is I'm sure there are more things that could
be done without redesigning the API.
Brian Gideon
> was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
> an entire class with one property on it:
>
I couldn't agree more.
> I do have one concerned raised by a member on the NValidate forums. He's
Typically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with. Furthermore, based on what you
just said, there's only one object per parameter. So I agree that
object creation would be small relative to the rest of the developers
application. The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.
> I do have a solution in mind if we think this will be a serious problem. I'd
> just like to get a feel for whether or not it's worth redesigning the
> framework or not.
Like you said, do some testing. My hunch is that it won't be that big