Method chaining with short-circuit parameter evaluation
-
No. I always say that.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
I may well be tonight.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
If voting was available, I would of shot you a 5, but alas.....
Software Kinetics - Dependable Software news
Norm .net wrote:
If voting was available, I would of shot you a 5, but alas.....
Seconded.
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
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
-
You can implement this using extension methods[^] ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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 very elegant, even if you could. Nice to get all clever (over engineering is, surely, an anti-pattern) with code but sometime in the future some poor sap will have to maintain what you have put together so keep it simple and verbose.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
You can implement this using extension methods[^] ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
I've heard of chaining programs and subprograms - using hpl on the HP 9825, for instance - but short circuit evaluation was never considered. Having never optimized a program for multi-processor environments, I have no idea how to do this, but you could launch a separate process for each of your levels of test, then cancel all if any one of them fails. It might not be useful, but it would certainly give the grunts whose job it is to debug things something interesting to do. :rolleyes:
Will Rogers never met me.
-
No. I always say that.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
Out of curiosity, what would you do in the
else
section of such a call? -
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
There are a few ways you could do this, but one thing I've been meaning to write a tip/trick on (as soon as I figure out how it can be done) is the expression tree approach. You'd do this:
var result = SafeChain(A.b.c.d.e.f.g.h.i.j.k);
The parameter would be passed as an expression tree, which would then be evaluated in steps, making sure to check for nulls along the way. The first null would cause null to be returned, otherwise the result value would be returned. I imagine you could use the same approach with your method chaining / expression trees.
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
In C# you can implement this k<ind of chaining using extension methods and expressions trees. The extension method (somewhat combined version of the two above):
public static U NotNull(this T myObject, Expression expression) where U : class { if (myObject == null) return null; else { var func = expression.Compile(); return func(); } }
Usage (returns either null if there's a null in the chain, or the value of MySubProperty, with almost the same syntax as above):
var value = myObject.NotNull(() => myObject.MyProperty).NotNull(() => myProperty.MySubProperty);
The only downside I found that in this case you have to declare a variable of type MyProperty for use in the second lambda expression. Maybe there's a way around it, but I didn't manage to find one as of yet. That can be changed though if the input remains myObject and the expression consists of the full path i. e. () => myObject.MyProperty.MySubProperty.
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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:
Am I procrastinating?
Yep! But then, you probably don't want to fix RootAdmin - it's down according to http://www.downforeveryoneorjustme.com/rootadmin.com[^]
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
There are a few ways you could do this, but one thing I've been meaning to write a tip/trick on (as soon as I figure out how it can be done) is the expression tree approach. You'd do this:
var result = SafeChain(A.b.c.d.e.f.g.h.i.j.k);
The parameter would be passed as an expression tree, which would then be evaluated in steps, making sure to check for nulls along the way. The first null would cause null to be returned, otherwise the result value would be returned. I imagine you could use the same approach with your method chaining / expression trees.
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
public static U NotNull<T, U>(this T myObject, Expression<Func<T, U>> expression) where U : class
{if (myObject == null) { return null; } try { var func = expression.Compile(); return func(myObject); } catch (Exception) { return null; }
}
Based off of a suggestion above. I tested this, and it seems to work.
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Chris Maunder wrote:
Am I procrastinating?
Yep! But then, you probably don't want to fix RootAdmin - it's down according to http://www.downforeveryoneorjustme.com/rootadmin.com[^]
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Maybe this IS the fix for the site.
-
In C# you can implement this k<ind of chaining using extension methods and expressions trees. The extension method (somewhat combined version of the two above):
public static U NotNull(this T myObject, Expression expression) where U : class { if (myObject == null) return null; else { var func = expression.Compile(); return func(); } }
Usage (returns either null if there's a null in the chain, or the value of MySubProperty, with almost the same syntax as above):
var value = myObject.NotNull(() => myObject.MyProperty).NotNull(() => myProperty.MySubProperty);
The only downside I found that in this case you have to declare a variable of type MyProperty for use in the second lambda expression. Maybe there's a way around it, but I didn't manage to find one as of yet. That can be changed though if the input remains myObject and the expression consists of the full path i. e. () => myObject.MyProperty.MySubProperty.
I figured out something that works. See my message below. It is based off of yours, with an extra parameter for the expression.
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
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
-
If voting was available, I would of shot you a 5, but alas.....
Software Kinetics - Dependable Software news
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 == null
then we have a runtime null ref error because, regardless of what the NotNull method returns as part of the chaining,myObject
is 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
Have you looked at this CP article by Dimitri Nesteruk[^] It looks very useful.
"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).