Method chaining with short-circuit parameter evaluation
-
Or a decorator, preferably combined with the NullObject-pattern :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
System.DBNull is an example of the pattern. And I can't describe in words how much I dislike it.
People say nothing is impossible, but I do nothing every day.
-
You were beat to the punch. :)
So I was. Great minds think alike but in my case I'll pass up on the citation. ;) Hopefully it'll convince Muppet Maunder to read it and see if helps him.
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68). "I don't need to shoot my enemies, I don't have any." - Me (2012).
-
If only there was some sort of site where people could write articles on exactly this issue[^]! ;P
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I am humbled and ashamed. And have just found an endless opportunity for way, way more procrastination.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
There is a way that you could do this, but it would be much more trouble than it was worth, and it would definitely open up a whole world of hurt. Effectively, what would need to be implemented is an IL rewriter to manage and rewrite the chain internally. Then you could create a fluid interface that would need to be recognised as the item that needs rewriting.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
I respect a man who prefers power drills and small explosives where others would wimp out and use tweezers. :thumbsup:
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Out of curiosity, what would you do in the
elsesection of such a call?Else? There is no else. Just blindly plow on!
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I respect a man who prefers power drills and small explosives where others would wimp out and use tweezers. :thumbsup:
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
When I get the chance, I may just have a go at it. Need some free time first.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
The first code block doesn't make any sense to me but this line
var result = Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
can be represented like this, can't you?
var result = (myObject == null ? false: myObject.MyProperty == null ? false : IsPositive(myObject.MyProperty.Id);
Just bouncing off an idea :) P.S. You can do it much simpler by using exceptions, I believe Cheers
-
You could just toss a :thumbsup: in place of a 5 vote.
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Would the C# ?? operator help you?
Would that do what you want? It definitely saves typing.
http://msdn.microsoft.com/en-us/library/ms173224.aspx -
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Not really an answer for the question you asked, but just a comment about error handling. A good strategy to avoid endless nested checks in error handling is to handle the opposite case first. So instead of writing
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}we would have
Test.NotNull(myObject);
if (myObject == null)
return;Test.NotNull(myObject.MyProperty)
if (myObject.MyProperty == null)
return;Test.IsPositive(myObject.MyProperty.Id);
...
Interested in Machine Learning in .NET? Check the Accord.NET Framework. See also Haar-feature Object Detection (With The Viola-Jones Framework) in C#
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
You can do that with extension methods! Just saying! ;)
My programming get away... The Blog... Taking over the world since 1371!
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
So this got me thinking: You can do
if (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation.
Well, I find myself doing a lot of those kind of checks and it would save me a lot of time and potential bugs if there was such a language. But now you have just stimulated me to think about a general purpose solution in C#. Maybe if I find something I'll post it on tips and tricks.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Not really an answer for the question you asked, but just a comment about error handling. A good strategy to avoid endless nested checks in error handling is to handle the opposite case first. So instead of writing
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}we would have
Test.NotNull(myObject);
if (myObject == null)
return;Test.NotNull(myObject.MyProperty)
if (myObject.MyProperty == null)
return;Test.IsPositive(myObject.MyProperty.Id);
...
Interested in Machine Learning in .NET? Check the Accord.NET Framework. See also Haar-feature Object Detection (With The Viola-Jones Framework) in C#
Not sure how that counts as handling the opposite case first, but I see what you mean and I do do that, though I do try and have only 2 exit points in a routine: 1 at the top when input fails, and the return at the end. Hence my thought that it would be nice having a single chained line at the top. All good discussion though. I love it.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
It might be simpler to just push the test down into a function call. This keeps the calling method simple, making the code more understandable and maintainable. Anyone maintaining the code doesn't have to reason about a unique control structure, and can skip all the details to focus on the overall algorithm. If they're curious about the test, they can optionally browse the testing function. The chaining looks cool, but is more complex than a sequence of plain, vanilla, if statements.
-
Not sure how that counts as handling the opposite case first, but I see what you mean and I do do that, though I do try and have only 2 exit points in a routine: 1 at the top when input fails, and the return at the end. Hence my thought that it would be nice having a single chained line at the top. All good discussion though. I love it.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Sorry, I should have meant "handle the error case first and exit as soon as possible", even if this "as soon as possible" will only occur in the middle of the function. Usually I don't have problems with multiple exit points in a function. Those are particularly useful, for example, when implementing a syntax parser from a LL(1) grammar. Another situation may happen, for example, if you are in the middle of a very nested loop and would like to exit them all. Refactoring the loop into its own function and using a
returnis often one of the clearest ways to quit all loops at once, specially in comparison with the alternative which is to maintain quite a number ofdonevariables guarding the loop exits as infor (int i = 0; i < n && !done; i++)
By the way, another sensible alternative for this case is also to use a
gotostatement, this being one of the few justified cases for using it. I know this doesn't have anything to do with your question either, but I am just keeping up the discussion :)Interested in Machine Learning in .NET? Check the Accord.NET Framework. See also Haar-feature Object Detection (With The Viola-Jones Framework) in C#
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Actually, there is something like that. It's called Embarcadero Prism (ex Delphi Prism). Borland made Delphi Prism using the Oxygene language (ex Chrome) through some agreement with RemObjects Software. Borland needed it as a .NET language replacement for the trully crappy Borland Delphi.NET. Check this beauty out: http://wiki.oxygenelanguage.com/en/Oxygene\_by\_Example\_-\_Colon\_and\_Null
-
I am testing several depths of properties in an object to make sure they are safe before I call them:
Test.NotNull(myObject);
if (myObject != null)
{
Test.NotNull(myObject.MyProperty);
if (myObject.MyProperty != null)
Test.IsPositive(myObject.MyProperty.Id);
...
}I was thinking it would be really cool to be able to do
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
but obviously if
myObject == nullthen we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObjectis still null. So this got me thinking: You can doif (myObject != null && myObject.MyProperty != null)
because of short circuit boolean evaluation in C#, but I was wondering, with my fairly mainstream experience in languages, if there are languages out there that would allow chaining of methods with short circuit evaluation. Essentially you'd have to have the input parameter be resolved after the method was called in order to have the method be able to say "I don't need the input parameter, please just ignore it". Has anyone heard of this? Would it open up a World Of Pain when it comes to debugging? Would it be useful? Am I procrastinating? --- Update: and it turns out this leads into a great discussion of extension methods. See The Maybe Monad[^] and Chained null checks and the Maybe monad[^] for two ways of achieving this. Once you've done that, debate the correctness of extension methods that are able by design to operate on a null references. I will be over there looking for new, shiny, distracting things.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
You can't possibly call this cool. This is a code janitor's nightmare. If any part of that fails, you don't know what has failed so you end up breaking it down into
aa = Test.NotNull(myObject);
bb = aa.NotNull(myObject.MyProperty)
cc = bb.IsPositive(myObject.MyProperty.Id);to see what is falling over. Cool is only for those who make a mess then disappear off to another job and leave someone else to tidy up their mess. They've never had to maintain the crap they generate and they find it difficult to understand, let alone maintain someone else's mess. This means that you have to hire an expensive janitor to unravel the coolness. You really don't want cool - you want maintainability so you can hire a cheap code janitor (fresh graddy).
-
Test.NotNull(myObject).NotNull(myObject.MyProperty).IsPositive(myObject.MyProperty.Id);
You can't possibly call this cool. This is a code janitor's nightmare. If any part of that fails, you don't know what has failed so you end up breaking it down into
aa = Test.NotNull(myObject);
bb = aa.NotNull(myObject.MyProperty)
cc = bb.IsPositive(myObject.MyProperty.Id);to see what is falling over. Cool is only for those who make a mess then disappear off to another job and leave someone else to tidy up their mess. They've never had to maintain the crap they generate and they find it difficult to understand, let alone maintain someone else's mess. This means that you have to hire an expensive janitor to unravel the coolness. You really don't want cool - you want maintainability so you can hire a cheap code janitor (fresh graddy).
:| I was discussing a concept, not presenting production code.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
