What do you think about Constraint modifiers?

[Charlie Poole]

In case you didn't know, those are the things that come after the main
constraint
and modify how it acts. Currently we have:
.Within(...)
.IgnoreCase
.RespectCase
.AsCollection
.NoClip
.Comparer(...)

These are devilishly hard to get right in the syntax. For example, you can
type Is.Null.IgnoreCase in the current code, which makes no sense. Before
putting more time into this, I wanted to ask whether you use these and
whether the current format works well.

I know some people are bothered by a form that looks like a getter property
modifying the state of the object, but you could also say it's just a new
paradigm and get used to it. Obviously, if we abandoned the modifier
syntax, we would need to find other ways to do the same stuf.

Your thoughts?

Charlie




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Kelly Anderson]

Post by Charlie Poole
In case you didn't know, those are the things that come after the main
constraint
.Within(...)
.IgnoreCase
.RespectCase
.AsCollection
.NoClip
.Comparer(...)
These are devilishly hard to get right in the syntax. For example, you can
type Is.Null.IgnoreCase in the current code, which makes no sense.

Even though it doesn't make sense, does it really hurt anything? Does
it act just as Is.Null would? If so, then I see no problem allowing
people to type in this foolishness.

Post by Charlie Poole
Before
putting more time into this, I wanted to ask whether you use these and
whether the current format works well.

I've used them a couple of times. When you need something like this,
you need it bad. So, even if you don't use them every day, I think
having something like this is ok.

Post by Charlie Poole
I know some people are bothered by a form that looks like a getter property
modifying the state of the object, but you could also say it's just a new
paradigm and get used to it. Obviously, if we abandoned the modifier
syntax, we would need to find other ways to do the same stuf.

It fits with the constraint syntax, and if you've gone down that road
to that point, why not go all the way. They can always use
Assert.True(...) if they don't like it.

-Kelly

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Charlie Poole]

Hi Kelly,

We haven't met, but I have imagined that you are a relative
old-timer - as am I. :-)

Back before intellisense, I think your comment would have
been correct and - in fact - that was my thought in designing
it the way I did.

However, with intellisense (or similar features in other IDEs)
the programmer is actually /invited/ to type in the meaningless
stuff, which is a bit of a bait-and-switch. Also, aside from
the fact that it's meaningless, having too many things in the
list makes it hard to see the useful items.

Designing for intellisense-like features of IDEs is a bit
of a new ballgame for me - and I'm guessing it is for you too!

Charlie

-----Original Message-----
Behalf Of Kelly Anderson
Sent: Monday, August 11, 2008 5:24 PM
To: Charlie Poole
Subject: Re: [nunit-developer] What do you think about
Constraint modifiers?
On Fri, Aug 8, 2008 at 7:32 PM, Charlie Poole

Post by Charlie Poole
In case you didn't know, those are the things that come

after the main

Post by Charlie Poole
.Within(...)
.IgnoreCase
.RespectCase
.AsCollection
.NoClip
.Comparer(...)
These are devilishly hard to get right in the syntax. For

example, you

Post by Charlie Poole
can type Is.Null.IgnoreCase in the current code, which

makes no sense.
Even though it doesn't make sense, does it really hurt
anything? Does it act just as Is.Null would? If so, then I
see no problem allowing people to type in this foolishness.

Post by Charlie Poole
Before
putting more time into this, I wanted to ask whether you

use these and

Post by Charlie Poole
whether the current format works well.

I've used them a couple of times. When you need something
like this, you need it bad. So, even if you don't use them
every day, I think having something like this is ok.

Post by Charlie Poole
I know some people are bothered by a form that looks like a getter
property modifying the state of the object, but you could also say
it's just a new paradigm and get used to it. Obviously, if we
abandoned the modifier syntax, we would need to find other

ways to do the same stuf.
It fits with the constraint syntax, and if you've gone down
that road to that point, why not go all the way. They can always use
Assert.True(...) if they don't like it.
-Kelly
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Chris Wright]

Post by Charlie Poole
Back before intellisense, I think your comment would have
been correct and - in fact - that was my thought in designing
it the way I did.

I was weaned with Resharper, so to speak, and I've never noticed these
issues. The odd cases don't make sense, except maybe if you had
something like:
int* ptr = ...;
Assert.That (ptr, Is.Null.Within(4095)); // make sure that it points
to an address in the first page of memory

So, if it doesn't make sense, I'm unlikely to choose that option in
the first place. I don't go from intellisense to intent, after all.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[Charlie Poole]

Hi All,

Feedback was light on the list, but several of you engaged me
directly. My conclusions are...

1) The mechanism is a good one, but may need some better
explanation. Logically, these are "Modifiers" even though
they are implemented as getters and methods returning a
value. The fact is that this is already a well-established
pattern in other fluent interfaces.

2) Not all the existing modifiers are necessarily useful. I
have my doubts about AsCollection and will look at using
the types passed in to determine how the comparison is
actually made.

3) In the latest code, I have an approach in place to make
sure that modifiers are only allowed where they are expected.
So "Is.Null.IgnoreCase" or "Is.Null.Within(.0005)" are
not allowed at all. This will take a bit more cleanup, but
it's basically solved.

4) I've implemented And and Or operators, which work as you
might expect and look cleaner (to me) than & and |.

Charlie

-----Original Message-----
Of Charlie Poole
Sent: Friday, August 08, 2008 6:32 PM
Subject: [Nunit-users] What do you think about Constraint modifiers?
In case you didn't know, those are the things that come after
.Within(...)
.IgnoreCase
.RespectCase
.AsCollection
.NoClip
.Comparer(...)
These are devilishly hard to get right in the syntax. For
example, you can type Is.Null.IgnoreCase in the current code,
which makes no sense. Before putting more time into this, I
wanted to ask whether you use these and whether the current
format works well.
I know some people are bothered by a form that looks like a
getter property modifying the state of the object, but you
could also say it's just a new paradigm and get used to it.
Obviously, if we abandoned the modifier syntax, we would need
to find other ways to do the same stuf.
Your thoughts?
Charlie
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nunit-users mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-users

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/