By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,818 Members | 1,381 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,818 IT Pros & Developers. It's quick & easy.

Method Name Suggestion: Validate a Poor Choice?

P: n/a
Please forgive the cross-post to multiple forums. I did it
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.

Oct 11 '07 #1
Share this Question
Share on Google+
24 Replies


P: n/a
Call it nValidate

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@v3g2000hsg.googlegro ups.com...
Please forgive the cross-post to multiple forums. I did it
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.

Oct 11 '07 #2

P: n/a
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
URL http://clintongallagher.metromilwaukee.com/


"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@v3g2000hsg.googlegro ups.com...
Please forgive the cross-post to multiple forums. I did it
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.

Oct 11 '07 #3

P: n/a
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 know it kind of breaks the flow you are trying to achieve, but it
would work.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@v3g2000hsg.googlegro ups.com...
Please forgive the cross-post to multiple forums. I did it
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.

Oct 11 '07 #4

P: n/a
On Oct 11, 2:27 pm, "clintonG" <nob...@nowhere.comwrote:
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/

"Mike Hofer" <kchighl...@gmail.comwrote in message

news:11**********************@v3g2000hsg.googlegro ups.com...
Please forgive the cross-post to multiple forums. I did it
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.- Hide quoted text -

- 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");
Oct 11 '07 #5

P: n/a

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 <kc********@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.
Again, thanks for your help.
Oct 11 '07 #6

P: n/a
On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gmail.comwrote:
Please forgive the cross-post to multiple forums. I did it
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.
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.

Oct 11 '07 #7

P: n/a
On Oct 11, 4:15 pm, Brian Gideon <briangid...@yahoo.comwrote:
On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gmail.comwrote:


Please forgive the cross-post to multiple forums. I did it
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.

Neat concept by the way.
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?

Oct 11 '07 #8

P: n/a
How about,

ThouShell.beEqualTo().NotBeNull().StartsWith("bar" ).EndsWith("baz");

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@o80g2000hse.googlegr oups.com...
On Oct 11, 4:15 pm, Brian Gideon <briangid...@yahoo.comwrote:
>On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gmail.comwrote:


Please forgive the cross-post to multiple forums. I did it
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.

Neat concept by the way.

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("ba z");

or

Validator.Demand.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("ba z");

...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?

Oct 11 '07 #9

P: n/a

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:um**************@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.
Oct 12 '07 #10

P: n/a
Mike,

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

Oct 12 '07 #11

P: n/a
On Oct 11, 7:05 pm, "Scott M." <s-...@nospam.nospamwrote:
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".
Oct 12 '07 #12

P: n/a
On Oct 11, 3:41 pm, Mike Hofer <kchighl...@gmail.comwrote:
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.

Oct 12 '07 #13

P: n/a
On Oct 12, 12:07 am, Brian Gideon <briangid...@yahoo.comwrote:
On Oct 11, 3:41 pm, Mike Hofer <kchighl...@gmail.comwrote:
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. :)

Oct 12 '07 #14

P: n/a
On Oct 12, 7:11 am, Mike Hofer <kchighl...@gmail.comwrote:
On Oct 12, 12:07 am, Brian Gideon <briangid...@yahoo.comwrote:


On Oct 11, 3:41 pm, Mike Hofer <kchighl...@gmail.comwrote:
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. :)- Hide quoted text -

- 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.

Oct 12 '07 #15

P: n/a
"Scott M." <s-***@nospam.nospamwrote:
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.
Oct 12 '07 #16

P: n/a
Anyone please tell me where to download NValidate?.

Mike Hofer 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.

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.
Oct 16 '07 #17

P: n/a
It's not available yet.

Look for the release announcement at :

http://www.nvalidate.org/

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" <ng****@matbao.comwrote in message news:uL**************@TK2MSFTNGP05.phx.gbl...
Anyone please tell me where to download NValidate?.

Mike Hofer 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.

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("ba z")

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.

Oct 16 '07 #18

P: n/a
On Oct 16, 9:48 am, Ngan Pham <nga...@matbao.comwrote:
Anyone please tell me where to download NValidate?.

Mike Hofer 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.
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.- Hide quoted text -

- 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!!

Oct 17 '07 #19

P: n/a
On Oct 17, 4:00 pm, Mike Hofer <kchighl...@gmail.comwrote:
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 athttp://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!!
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

Oct 18 '07 #20

P: n/a
On Oct 17, 4:00 pm, Mike Hofer <kchighl...@gmail.comwrote:
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 athttp://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!!
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

Oct 19 '07 #21

P: n/a
"Brian Gideon" <br*********@yahoo.comwrote in message
news:11**********************@v23g2000prn.googlegr oups.com...
On Oct 17, 4:00 pm, Mike Hofer <kchighl...@gmail.comwrote:
>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 athttp://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!!

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
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.


Oct 19 '07 #22

P: n/a
On Oct 18, 9:46 pm, "Mike" <tyrantmi...@comcast.netwrote:
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.

Oct 19 '07 #23

P: n/a
On Oct 18, 9:46 pm, "Mike" <tyrantmi...@comcast.netwrote:
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:
I couldn't agree more.
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.
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.

Oct 21 '07 #24

P: n/a
On Oct 18, 9:46 pm, "Mike" <tyrantmi...@comcast.netwrote:
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:
I couldn't agree more.
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.
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.

Oct 21 '07 #25

This discussion thread is closed

Replies have been disabled for this discussion.