Ad
  • Custom User Avatar

    It's a good implementation, but by nature converting a number into a string is much more complicated than a simple while loop which runs a dozen or so times.

  • Custom User Avatar

    Approved by someone

  • Custom User Avatar

    python new test framework is required. updated in this fork

  • Custom User Avatar

    Well, the kata "works" as it is, hence rather a suggestion.

    I used option #1 in all my solutions, but as I said, it doesn't make a difference because it's not tested in any language.

  • Custom User Avatar

    shouldn't this be an issue, actually?

    What did you use for the translation? way 2?

  • Custom User Avatar

    While translating the kata, the question that arose back when I first solved it reared its ugly head again:
    The builder is entirely capable of calling a base coffee type twice in a single chain, and it is not specified what effect exactly this should have.
    Accordingly, it is never tested for, though a correct solution should handle such a case, and I believe we should be promoting correctness wherever possible.

    Imagine a case like Builder().cubano().with_milk(1.0).americano()
    Note the trailing americano(), a new base type. From what I can see, there are 3 different choices on how to handle this case:

    1. A trailing base type "resets" any previous build process. Here, these two expressions are equivalent:
      Builder().cubano().with_milk(1.0).americano()
      Builder().americano()

    2. A trailing base type simply adds its attributes to the existing build proceess. Here the expression
      Builder().cubano().with_milk(1.0).americano()
      simply adds the base 0.5 of the "americano" to the existing ingredients, resulting in a coffee with 1 brown sugar (cubano) and 2 milks, 1.0 (with_milk) and 0.5 (americano)

    3. Any base type following the first base type call is invalid. So as not to introduce error handling into this kata, any trailing base type call would simply be ignored as a no-op. These two expressions are equivalent:
      Builder().cubano().with_milk(1.0).americano().with_sugar("Stevia")
      Builder().cubano().with_milk(1.0).with_sugar("Stevia")

    Option #2 is what the reference implementations (and most user solutions) do in C# and Rust, and I assume in other languages as well, however this is purely incidental. When authoring my own solution, I wasn't aware the tests simply wouldn't produce such cases, and opted to go with option #1 for lack of any specification.

    Additionally, the spec does not mention the behaviour of first adding milk/sugar, and then calling a base type: Builder().with_milk().americano(). This needs the same considerations as above.

    My proposal would be to actually decide on a proper spec, describe it, and modify existing translations to implement and test them while there are only 3-4 languages currently implemented.

  • Custom User Avatar

    Python translation ready for review (see notes in translation discourse)

  • Default User Avatar

    thanks for kata,it was good one

  • Custom User Avatar

    Nice change from the standard kata.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Well, this is kinda a duh moment for me... I did an iteration version which is wildly unnecessary, if you see this one. If anyone is still wondering how it works, it uses integer division to round down to the nearest whole number before multiplying by the divisor to get the complement.

  • Custom User Avatar
  • Custom User Avatar

    Should be updated to Rust 1.49.

  • Custom User Avatar
  • Custom User Avatar

    this doesnt seem to work on a calculator

  • Loading more items...