I hesitate to say "Best Practices", since Address is officially deprecated,
but I really think this is the best possible practice. You used the provided
API for exactly what it was meant for.

From the first paragraph of the Wikipedia article about Y (emphasis mine):

Y, or y, is the twenty-fifth and penultimate letter of the Latin alphabet, used in the modern English alphabet, the alphabets of other western European languages and others worldwide. According to some authorities, it is the sixth (or seventh if including W) vowel letter of the English alphabet. In the English writing system, it mostly represents a vowel and seldom a consonant, and in other orthographies it may represent a vowel or a consonant. Its name in English is wye (pronounced /ˈwaɪ/), plural wyes.

Boxing won't occur here.

char.IsUpper takes a char and returns a bool.

bool (or System.Boolean) has a Equals(bool) override, so the compiler won't choose the Object.Equals(Object) method.

Using == is still better practice, though, as

1. it's more idiomatic; and
2. it avoids having to perform a method call (Equals), though the I'm nearly positive bool.Equals(bool) would be inlined

The description of the kata said to count the positive odd integers -- and since the function takes a signed int, I was making sure nothing negative got through.

It's because Object.defineProperty is a bit more complex than just assigning values to target object.

The second argument is a map of property names to property descriptors, which allow you to customize how the property is accessed.

The descriptor for attack in my code says that the value of attack is a function. Note, in contrast, that isDead has get rather than value in its descriptor, means that its value is calculated by the function provided.

An equivalent way to define attack would to just set its value on the prototype, like so

Fighter.prototype.attack = function(other) { other.health -= this.damagePerAttack; };

I chose to use Object.defineProperties because it also allowed me to create the "get-only" property isDead.

Thanks!

Great, thanks!

A note on the PowerShell version:

\n does not represent a newline in Powershell. Powershell escapes characters by prefixing them with backticks (`), so a newline is represented as "`n".

Note the difference in how Powershell echoes the following lines

PS C:\> "a\nb"
a\nb

PS C:\> "a`nb"
a
b

The current Powershell translation has a number of issues with its whitespace.

1. It's attempting to use C-style backslash escapes in its strings, whereas Powershell uses backticks. This is causing the two-character string "\r" to be expected, rather than a carriage return.
2. In Powershell (on Windows, at least), the line separator is the two-character string "`r`n" (CR+LF), though it also accepts "`n". If you try printing a string with just a carriage-return, it overwrites the preceding portion of the line.

E.g.,

PS> "a\rb" # this translation, with a literal '\r'
a\rb

PS> "a\\rb" # showing doubled backslash showing there's no special handling
a\\rb

PS> "abc`rDE" # with a real carriage return, showing it overwriting the preceding portion of the line
DEc

PS> "abc`r`nDE" # with Windows Powershell's preferred line separator
abc
DE

PS> "abc`nDE" # with just a linefeed (also acceptable)
abc
DE

Sample tests don't work (looks like they need to be placed in a class).

Actual tests pass arguments in reverse order (expected vs actual).

Instructions should specify how to handle when searchPhrase is empty string or null. (Does empty searchPhrase match everything or nothing?)

Overall a fun kata though!

Thanks!