Charlie Poole
2008-09-07 18:03:52 UTC
Hi All,
Working on the new AttributeConstraint I realized something
that I hadn't noticed before:
Sometimes you want to check a Type for Attributes, and
sometimes you want to check an instance of the Type.
Of course, it's simple enough to require you to pass
in a type - you can always use GetType() if what you
have is an instance. But I think the difference is
more subtle than that and it applies to our old
PropertyConstraint as well.
For example, if you have an instance, you can examine the
value of a property of that instance. If you have a type,
you can check for the existence of a property, but not
for its value - unless it's static of course.
I can imagine different uses for each sort of constraint
and I think we should support both.
Currently, PropertyConstraint works on instances. It
takes the Type of that instance and looks for a property,
then extracts the value. If you pass it a Type, it will
check the type of that Type instance - which is Type.
For AttributeConstraint, I allowed you to pass in either
a Type or an instance. If it's not a Type, I use GetType()
to find the type. I'm adding the ability to apply further
tests to the attribute, and I plan to throw an exception
if you try to extract an instance value but didn't
supply an instance.
Similarly, it seems to me that Property should work the
same way. I should be able to write ...
Assert.That(type, Has.Property("Name"));
or
Assert.That(customer, Has.Property("Name"));
or
Assert.That(customer, Has.Property("Name").EqualTo("Charlie"));
[Currenty you can't do the first one.]
The only drawback I see is that you can't apply any
value tests to *instances* of the Type class. I see
no problem with this, since any properties of Type
can be accessed directly - like Type.FullName.
As we progress into this set of constraints that
operate on Types, I see possibe use for
MethodConstraint, FieldConstraint and possibly others.
Your comments are requested!
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=/
Working on the new AttributeConstraint I realized something
that I hadn't noticed before:
Sometimes you want to check a Type for Attributes, and
sometimes you want to check an instance of the Type.
Of course, it's simple enough to require you to pass
in a type - you can always use GetType() if what you
have is an instance. But I think the difference is
more subtle than that and it applies to our old
PropertyConstraint as well.
For example, if you have an instance, you can examine the
value of a property of that instance. If you have a type,
you can check for the existence of a property, but not
for its value - unless it's static of course.
I can imagine different uses for each sort of constraint
and I think we should support both.
Currently, PropertyConstraint works on instances. It
takes the Type of that instance and looks for a property,
then extracts the value. If you pass it a Type, it will
check the type of that Type instance - which is Type.
For AttributeConstraint, I allowed you to pass in either
a Type or an instance. If it's not a Type, I use GetType()
to find the type. I'm adding the ability to apply further
tests to the attribute, and I plan to throw an exception
if you try to extract an instance value but didn't
supply an instance.
Similarly, it seems to me that Property should work the
same way. I should be able to write ...
Assert.That(type, Has.Property("Name"));
or
Assert.That(customer, Has.Property("Name"));
or
Assert.That(customer, Has.Property("Name").EqualTo("Charlie"));
[Currenty you can't do the first one.]
The only drawback I see is that you can't apply any
value tests to *instances* of the Type class. I see
no problem with this, since any properties of Type
can be accessed directly - like Type.FullName.
As we progress into this set of constraints that
operate on Types, I see possibe use for
MethodConstraint, FieldConstraint and possibly others.
Your comments are requested!
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=/