« The Silly Season | Main | Test Post »
July 08, 2005
Communication at Microsoft: Blogs, Bugs, and Other
A little while ago Lee Holmes filed a bug in our bug database about how the get-history cmdlet works. Basically if you write
$a = get-history
then if there is one item in the history $a will be a scalar, and if there is more than one $a will be an array.
Lee filed the bug against me because I "own" the get-history cmdlet from the PM side, but it's actually not get-history that is causing this. The cmdlet is just outputting objects; it's the Monad parser which is converting the result into a scalar or an array. The output of get-process, get-childitem, etc. would all have the same behavior. In general this is not a problem, if you want to print $a, or pipe it into another cmdlet, or use it in a foreach block. One problem, however, is if you want to refer to the first element of history, then you would use $a[0], but if $a were a scalar, this would fail.
Monad could have done this differently...we could have designed it so that if a cmdlet output a single object then it became an array with one element, instead of a scalar. Or perhaps we could have done something like Perl, where the context determines if a value should be treated as a scalar or an array, and automatic conversion is done. We could have done that, but we didn't, and given the choices we made the language is consistent, so you can't just tweak one part of it.
Anyway Lee filed this bug and I resolved it back to him as "By Design", but then a few days later he opened it back up saying "We really should fix this." So I chonked it right back to him. We are nearing a milestone and need to get our bug counts down; this means that using the bug database as a form of communication works pretty well because people check their bugs often, but I also don't want bugs lurking around on my plate.
Then I noticed that he had written a blog item about including the ID of the last history item in his prompt. Which is exactly the scenario that causes trouble: you want to grab a single history item, when the output of get-history might be a scalar or an array. So then I understood why he had filed the bug.
From his script I can see that Lee solved the problem by using the @() syntax, which will convert a scalar into an array of length 1 and keep an array unchanged--exactly what you want. I made a similar change between the second and third versions of my get-feeds.msh RSS reader. The amusing thing is that I never talked or emailed him about this; the communication was entirely through the bug database and our blogs.
A similar thing happened with the last version of get-feeds.msh. I had switched to use -contains to check if an value existed in an array. One of the testers (he tests the MSH language itself, thus is probably one of the three greatest experts worldwide) pointed out that -contains technically returns the matching elements in the array, not a boolean. However, the -eq operator, when comparing an array to a scalar, does do what I want. Compare these two:
MSH> (1,2,3) -contains 2
2
MSH> (1,2,3) -eq 2
True
That would probably work since 2 is "true"; the problem occurs when the element you are looking for won't evaluate to true:
MSH> if ((0,2,4) -contains 0) { "TRUE" }
MSH> if ((0,2,4) -eq 0) { "TRUE" }
TRUE
MSH> if (("a",$null,"b") -contains $null) { "TRUE" }
MSH> if (("a",$null,"b") -eq $null) { "TRUE" }
TRUE
Now in my scenario it wouldn't matter much because I am comparing strings with dates in them...but still it is more correct to do it with -eq.
So there the conversation was a blog entry followed by email.
I am actually having a problem trying to play with the formatting of the RSS output, which is the next improvement I had planned to post about. I know which developer I need to ask about it, but I have to decide which arrow in my quiver I used to resolve this.
I could blog about it, but not much point in displaying code that I know doesn't work (I have posted some code that could be improved, like the -contains to -eq change, but at the time I posted it I thought it was right). I could file a bug, but at this stage every bug filed raises the stress level. I could email him, but it might be hard to explain. I could go talk to him, but then I wouldn't have the script on my machine to show him. Hmf. And to think that our group, for whatever reason, doesn't use Instant Messenger, or that could be another choice.
Maybe I'll type up a memo, print it out, and interoffice mail it to him.
Posted by AdamBa at July 8, 2005 08:44 AM
Trackback Pings
TrackBack URL for this entry:
http://proudlyserving.com/cgi-bin/mt-tb.cgi/327
