473,842 Members | 1,600 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Method Name Suggestion: Validate a Poor Choice?

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(f oo,
"foo").IsNotNul l().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.Frame work.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
24 2119
Call it nValidate

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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
Be more explicit with your naming, FactoryClassVal idation,
CleanMyRoomVali dation 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********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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
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.co m

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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
On Oct 11, 2:27 pm, "clintonG" <nob...@nowhere .comwrote:
Be more explicit with your naming, FactoryClassVal idation,
CleanMyRoomVali dation 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://clintongallaghe r.metromilwauke e.com/

"Mike Hofer" <kchighl...@gma il.comwrote in message

news:11******** **************@ v3g2000hsg.goog legroups.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(f oo,
"foo").IsNotNul l().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.Frame work.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.Frame work namespace:

ValidatorBase
ValueTypeValida torBase (derives from ValidatorBase)
ObjectValidator Base (derives from ValidatorBase)
BooleanValidato r (derives from ValueTypeValida torBase)
StringValidator (derives from ObjectValidator Base)
ArrayValidator (derives from ObjectValidator Base)
ConnectionValid ator (derives from ObjectValidator Base)

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(f oo, "foo").IsNotNul lOrEmpty();

Instead of this:

if (null == foo)
throw new ArgumentNullExc eption("foo");
if (string.Empty == foo)
throw new ArgumentExcepti on("Empty strings not permitted.", "foo");
Oct 11 '07 #5

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********@gma il.com>
wrote:
>Please forgive the cross-post to multiple forums. I did it
intentionall y, but I *think* it was appropriate given the nature of my
question.
Again, thanks for your help.
Oct 11 '07 #6
On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.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(f oo,
"foo").IsNotNul l().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.Frame work.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.Valid ate.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

or

Validator.Deman d.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

....where Validator is a static class and Validate or Demand is a
singleton.

Oct 11 '07 #7
On Oct 11, 4:15 pm, Brian Gideon <briangid...@ya hoo.comwrote:
On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.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(f oo,
"foo").IsNotNul l().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.Frame work.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.Valid ate.That(foo,
"foo").IsNotNul l().StartsWith( "bar").EndsWith ("baz");

or

Validator.Deman d.That(foo,
"foo").IsNotNul l().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.Deman d.That()

This has the advantage of making it clear that we're working with
parameters. So we end up with this:

ParamRule.Deman d.That(foo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

instead of this:

Validate.That(f oo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );
>From a C# perspective, that's fine; VB developers might balk at it.
Thoughts? Suggestions?

Oct 11 '07 #8
How about,

ThouShell.beEqu alTo().NotBeNul l().StartsWith( "bar").EndsWith ("baz");

"Mike Hofer" <kc********@gma il.comwrote in message
news:11******** **************@ o80g2000hse.goo glegroups.com.. .
On Oct 11, 4:15 pm, Brian Gideon <briangid...@ya hoo.comwrote:
>On Oct 11, 12:59 pm, Mike Hofer <kchighl...@gma il.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(f oo,
"foo").IsNotNul l().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.Frame work.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.Vali date.That(foo,
"foo").IsNotNu ll().StartsWith ("bar").EndsWit h("baz");

or

Validator.Dema nd.That(foo,
"foo").IsNotNu ll().StartsWith ("bar").EndsWit h("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.Deman d.That()

This has the advantage of making it clear that we're working with
parameters. So we end up with this:

ParamRule.Deman d.That(foo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );

instead of this:

Validate.That(f oo, "foo")
.IsNotNull()
.StartsWith("ba r")
.EndsWith("baz" );
>>From a C# perspective, that's fine; VB developers might balk at it.
Thoughts? Suggestions?

Oct 11 '07 #9

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:um******** ******@TK2MSFTN GP02.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

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

24
1497
by: Mike Hofer | last post by:
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.
0
9871
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9715
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10944
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10610
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9453
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7035
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
4499
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4089
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3144
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.