On Fri, 11 Apr 2008 02:28:53 -0700, Anthony Jones <Ant@yadayadaya da.com>
wrote:
>
Well thats the crux of the matter isn't it? Why is it "silly" ?
Just my opinion, granted...but it's "silly" because you are doing the same
thing twice. Each time you return a different kind of result: the first
time, you return "did I succeed?", the second time you return "the outcome
of my success". But the work leading up to that is basically the same.
As Marc pointed out, the "Try..." pattern isn't obscure. Later you wrote
"it may become part of the expected structure of code". Sorry to break
the news to you: it's _already_ used so often that it's a standard pattern
in .NET.
That's not what I meant. Your statement seemed to imply that you find
something wrong with the "Try..." pattern. The rest of your post seems to
say that too.
For what it's worth, you could easily write your own "CanParse". It would
be trivial. You aren't forced to use the "Try..." pattern at all.
Okay. I do have sympathy for the question of what your brain sees versus
what the compiler sees. In this particular case, I don't have any trouble
seeing what the compiler sees, but I've been in other situations where I
do, so I'll grant you that you yourself may have trouble with this.
Still, I think it's a scenario worth retraining yourself for. The
"Try..." pattern isn't going away, and it provides a performance benefit
for trivial effort on your part. I agree most of the time it's not a
needed performance benefit, but I don't think this is a scenario where the
non-performant variation carries some huge benefit over the performant one
from a readability point of view.
Is it really that hard to teach yourself to recognize passing by-reference
semantics?
I guess this is where we simply will disagree. I don't find by-reference
parameters hard to read in code, and on top of that, while I agree that
they should be used very sparingly, they are an important part of the
language and it's my opinion that if you're having trouble recognizing the
pattern, the solution is to spend more time with the language so that the
pattern is recognizable, rather than to change the framework so that you
can call the same thing twice with slightly different semantics each time.
As I said, I have sympathy for your position -- readability is a pet
project of mine too -- but I think that in this case you'll be better
served by drinking the Kool Aid. :)
This I don't understand. All that the try/catch adds is a few more
lines. The assignment is right in there, just as you've expected. That
said, you could always add the CanParse() method yourself.
So, I'm curious: have you? Is this really important enough to you that
you've dealt with the problem? Or is it just something you'd rather just
complain about?
That's not really true. You can add both the CanParse() and the nullable
return value pattern to your own code, trivially.
I'd say that's the other place I disagree. Granted, "smell bad" isn't a
techincal phrase anyway, so by its very nature using it is going to be
imprecise. But I don't think a particular pattern "smells bad" just
because it should be used sparingly.
Maybe you're just using the phrase differently from the way I'd use it.
For me, code only "smells bad" (inasmuch as it could have a smell :) ) if
and when something is used inappropriately . If it's something that should
be used sparingly, but it's still being used appropriately, then that's
fine-smelling code.
Pete
wrote:
>I wouldn't want that at all. If I'm calling CanParse(), 99 times out
>of a
>100 it's because I want to parse the string. It'd be silly to call a
>method that basically has to do the work of parsing the string, but
>which
>only returns a flag telling me if actually parsing the string will work.
>of a
>100 it's because I want to parse the string. It'd be silly to call a
>method that basically has to do the work of parsing the string, but
>which
>only returns a flag telling me if actually parsing the string will work.
Well thats the crux of the matter isn't it? Why is it "silly" ?
thing twice. Each time you return a different kind of result: the first
time, you return "did I succeed?", the second time you return "the outcome
of my success". But the work leading up to that is basically the same.
[...]
>
Its also an example of obscurity of function.
>If anything the "Try..." pattern is a great example of the usefulnessof
>by-reference parameters.
>by-reference parameters.
Its also an example of obscurity of function.
"it may become part of the expected structure of code". Sorry to break
the news to you: it's _already_ used so often that it's a standard pattern
in .NET.
[...]
>
No I wrote "Not having CanParse I'm forced ...". Its not the presenceof
TryParse as an option which bothers me its not having a CanParse that I
have
issue with.
>You write "forced" as though there's something about calling TryParse()
>that is harmful.
>that is harmful.
No I wrote "Not having CanParse I'm forced ...". Its not the presenceof
TryParse as an option which bothers me its not having a CanParse that I
have
issue with.
something wrong with the "Try..." pattern. The rest of your post seems to
say that too.
For what it's worth, you could easily write your own "CanParse". It would
be trivial. You aren't forced to use the "Try..." pattern at all.
[...]
>
Its a relative thing. True it isn't actually hard to see that the out
keyword on the parameter indicates where x gets its value. However itis
harder to see than x = because that's what our minds will be condition to
expect when looking for an assignment. This may seem to be a
microscopic
and insigniifcant difference but to think so is a mistake.
>Why is it the case that "how did x get assigned a value" is "not that
>obvious"? The "out" in the parameter list for the call to TryParse()
>makes it very clear where x is getting assigned.
>obvious"? The "out" in the parameter list for the call to TryParse()
>makes it very clear where x is getting assigned.
Its a relative thing. True it isn't actually hard to see that the out
keyword on the parameter indicates where x gets its value. However itis
harder to see than x = because that's what our minds will be condition to
expect when looking for an assignment. This may seem to be a
microscopic
and insigniifcant difference but to think so is a mistake.
what the compiler sees. In this particular case, I don't have any trouble
seeing what the compiler sees, but I've been in other situations where I
do, so I'll grant you that you yourself may have trouble with this.
Still, I think it's a scenario worth retraining yourself for. The
"Try..." pattern isn't going away, and it provides a performance benefit
for trivial effort on your part. I agree most of the time it's not a
needed performance benefit, but I don't think this is a scenario where the
non-performant variation carries some huge benefit over the performant one
from a readability point of view.
Is it really that hard to teach yourself to recognize passing by-reference
semantics?
[...]
The same principle can be applied to readability of code. Small
differences
such as CanParse/Parse vs TryParse only have a small effect individually
on
readability however the cumalitive effect of computer oriented over human
oriented coding is significant.
The same principle can be applied to readability of code. Small
differences
such as CanParse/Parse vs TryParse only have a small effect individually
on
readability however the cumalitive effect of computer oriented over human
oriented coding is significant.
parameters hard to read in code, and on top of that, while I agree that
they should be used very sparingly, they are an important part of the
language and it's my opinion that if you're having trouble recognizing the
pattern, the solution is to spend more time with the language so that the
pattern is recognizable, rather than to change the framework so that you
can call the same thing twice with slightly different semantics each time.
As I said, I have sympathy for your position -- readability is a pet
project of mine too -- but I think that in this case you'll be better
served by drinking the Kool Aid. :)
[...]
>
That simply replaces one unusual pattern of code with another. Not a
solution to the human problem I'm looking for.
>If performance is not a concern (and you already wrote that it almost
>never is), you can always just wrap a call to Parse() with a try/catch
>block. That provides the exact assignment pattern you're asking for.
>never is), you can always just wrap a call to Parse() with a try/catch
>block. That provides the exact assignment pattern you're asking for.
That simply replaces one unusual pattern of code with another. Not a
solution to the human problem I'm looking for.
lines. The assignment is right in there, just as you've expected. That
said, you could always add the CanParse() method yourself.
So, I'm curious: have you? Is this really important enough to you that
you've dealt with the problem? Or is it just something you'd rather just
complain about?
[...] It would be nice to have the choice of all three but if I
could only have two I would take CanParse and TryParse. Sadly I only have
the one TryParse.
could only have two I would take CanParse and TryParse. Sadly I only have
the one TryParse.
return value pattern to your own code, trivially.
[...]
ByRef parameters are unusual and can catch the less wary out. They can
be
gotchas even for the experienced. Whilst they do have their place they
should be used sparingly and be treated with suspicion. In short, they
smell bad.
ByRef parameters are unusual and can catch the less wary out. They can
be
gotchas even for the experienced. Whilst they do have their place they
should be used sparingly and be treated with suspicion. In short, they
smell bad.
techincal phrase anyway, so by its very nature using it is going to be
imprecise. But I don't think a particular pattern "smells bad" just
because it should be used sparingly.
Maybe you're just using the phrase differently from the way I'd use it.
For me, code only "smells bad" (inasmuch as it could have a smell :) ) if
and when something is used inappropriately . If it's something that should
be used sparingly, but it's still being used appropriately, then that's
fine-smelling code.
Pete