It's already better. But users still need to do console.log(this) in order to find out the names of properties of type "Engine" (property = "engine") and "Gearbox" (property = "gearBox").
The superfluous argument on the function has been removed and I've done a proofreading pass through the description. Please let me know if you have any further issues with the description.
In JS, the assertions are swapped. Instead of assert.strictEqual(correctResult, userResult) it should be assert.strictEqual(userResult, correctResult). This is important because otherwise when a solution is wrong, currently it makes it look like the tests have the wrong answer, which is confusing.
For JS, since the case convention isn't the same as C#, the interface should be discussed in the description: the properties are camelCased (please use languages conditional rendering blocks to do so)
What do you mean by "legal"?
It's just a very spectacular way of solving this issue, but would never found a way into any prod code,
due it's complexity.
But it works for sure and is correct nontheless. :)
func1 and func 2 are delegates, a type that represent a calling site (a method somewhere).
It's like pointer of function in C/C++, but delegates in C# posses more informations than that (the instance of the object for non static method, ...)
This feature is used in many scenario: Event manamgement, Linq (to object), ...
If compiler produce a binary and the binary works, that's clearly legal.
But, as you don't put parenthesis on a variable, it's better to use Invoke() to clarify the context.
Good
fixed for C#
Edited again to show the full accessor chain for each language in the description.
It's already better. But users still need to do
console.log(this)
in order to find out the names of properties of type "Engine" (property = "engine") and "Gearbox" (property = "gearBox").I've added these test cases to JS, but don't have permission to do so for C#.
The superfluous argument on the function has been removed and I've done a proofreading pass through the description. Please let me know if you have any further issues with the description.
Such an annoying kata!
This comment is hidden because it contains spoiler information about the solution
.
In JS, the assertions are swapped. Instead of
assert.strictEqual(correctResult, userResult)
it should beassert.strictEqual(userResult, correctResult)
. This is important because otherwise when a solution is wrong, currently it makes it look like the tests have the wrong answer, which is confusing..
Hi,
For JS, since the case convention isn't the same as C#, the interface should be discussed in the description: the properties are camelCased (please use languages conditional rendering blocks to do so)
Cheers
What do you mean by "legal"?
It's just a very spectacular way of solving this issue, but would never found a way into any prod code,
due it's complexity.
But it works for sure and is correct nontheless. :)
Loading more items...