I really like how C# implements getters/setters. The first language I started coding in was Actionscript 3 so I 'grew up' using implicit getters/setters.

For instance, I don't care for how Python/JS deal with private vars.

Thanks for pointing that out. I overlooked that the C# version tested for that; I attempt to keep my tests as faithful to the original as possible.

I've added a test to the python translation that fixes the issues with tabs.

Sorry about that. I need to change my .vimrc to use 4 spaces rather than tabs in python.

It didn't let me just edit the translation; it complained about a difference in the description. I tried copy/paste the description from a fresh translation page. It still didn't like it.

I forked my existing translation and replaced all tabs with 4 spaces. I'll go back to part one and check that for tabs as well.

I didn't enforce that side should be private. Typically, in Python culture you prepend a property with _ or __ to state that it's private and shouldn't be directly accessed touched.

Python does have a way to add some encapsulation to the value. I didn't go this route because the C# tests (if I remember correctly) don't include tests for whether side is private or not or whether you can assign invalid values to it.

In Python a class that would more closely emulate a private var would be:

class Cube(object):
  def __init__(self, side = 0):
    self.side = side
  
  @property
  def side(self):
    return self.__side
  
  @side.setter
  def side(self, n):
    self.__side = n

Damn. I'm taking off today but either later today or tomorrow I'll look into it more. I remember Jake fixed this problem for me before. I'll have to look through my older translations and find the one he fixed so I can mimic what he did.

Good call. I'll revise the submissions later today or tomorrow to conform more to their language(s) idioms.

I've been thinking about it quite a bit and am thinking more and more that the no constructor constraint should be abandoned on certain languages. Just like how some languages don't allow you to overload methods, some languages don't like instantiating objects without a constructor.

@-Julz-

How important is it that the Cube object doesn't use a constructor?

In Python, it's very doable if you know the builtins.

In javascript, it's a real annoyance to create the Cube without an initializer (calling new).

In Ruby, I can write a solution without using an initialize function but haven't figured out how to test for its existance yet. It shows up as an instance method even when the class was built without the initialize function.

Haven't gotten to CoffeeScript, Clojure, or Haskell, yet.

I don't love how I went about creating the Cube object. It was all in an attempt to conform to the no constructor constraint. The more JS way to define the cube would be:

function Cube(s = 0) {
  var _side = s;
  
  this.getSide = function() { return _side; };
  this.setSide = function(n) { _side = n; };
}

c = new Cube();
c.getSide(); // returns 0
c.setSide(5);
c.getSide(); // returns 5

Of course this has a constructor, my solution only allows you to use the Cube directly because CW's JS runner doesn't have Object.clone.

I'd be happy to re-write this so that it's more JS-esque and ignore the no constructor constraint for JS; your choice. It wouldn't take more than a few minutes to edit it to fit.

Side note on your C# tests. The range for the randon number is -500 - 499 if I understood the Random.Next documentation. I don't think there's anything wrong with that. But if you want the range to be -500 - 500 you'd need to change your Random.Next call to be Random.Next(1001) - 500;

I didn't touch the description. I don't think it's sensible until all the translations are complete. I left notes in the setup describing the differences; for instance GetSide isn't very pythonic so I changed it to get_side and noted it in the comments on the setup.

I added a test to the end of the test cases to make sure the trainee didn't use a constructor. My solution shows two methods of creating the Cube class without a constructor.

I think I fixed the JS translation. I commented more in depth on it's discourse page.

To get a better hold of things I'm going to go back to the Cube I excersize and do all the translations before moving on to this one and then part 3.

(I'm leaving my damned mits off the descriptions. After all translations are correct and integrated any changes to the description can be done in one action rather than merging for every translation.)

TLDR: I am 76.42% sure that I fixed it so this translation should merge without a problem.

I edited the kata and copy/pasted the description from a new translation so it shouldn't have any problems merging. I can think of two possible solutions. 1- Wait on editing the description until all translations are done. Then do one update to the translation giving the note to languages that can't overload functions that they'll have to write a constructor that accepts variable arguments. 2- Change the description so the parts that differ by language are in code blocks and the trainee will then only see the part of the description for th elanguage they've selected. Example (If the text in the codeblock was how the description was formatted :

-Description as applies to all languages
```C#
  Create two constructors for our Cube; one that accepts an int for the Cube's
  side and one that takes no arguments, setting the cube's side to 0
\`\`\` (The backslashes wouldn't be in the description, I just have to escape them so they don't close off the code block
\`\`\`python
  Create a constructor for our Cube. It will need to be able to accept either a single integer as an argument for the length of the Cube's side or no arguments, in which case the side of the Cube is 0
\`\`\`

Remember, a Cube can't have a negative value for it's side.

If the final description was formatted that way someone browsing with Python selected wouldn't see the chunk of text for C#; likewise, someone training on
C# wouldn't see the bit of text wrapped in the python codeblock.

I forgot about that caveat of CW. I think what happens is CW makes a diff patch of the description when you publish. When you approved the PYthon translation it merged in the patch to the description. The Javascript translation was published before the Python translation changed the description. So I think it's diff patch is invalid because it's the diff against the original description.

I'm pretty sure I know how to fix this and what's causing the problem. The same thing happened the first time I translated a kata. I'd written a translation for two languages, each making a change to the description (I didn't know it was shared.)

I think I remember what jhoefner did to fix it. I'll hop on fixing it so it can be approved after I go chainsmoke a bit.

The example test cases were pretty difficult to decipher, I'd like to recommend to the Author (if still active) that they change the example test cases to:

test_inputs = ['', '123', 'SF$SDfgsd2eA', '4526849387241925']
test_solutions = ['', '123', '########d2eA', '############1925']

for i in xrange(len(test_inputs)):
    test.describe("Masking: {0}".format(test_inputs[i]))
    user_answer = maskify(test_inputs[i])
    test.assert_equals(user_answer, test_solutions[i], "Got: {0}\nExpected: {1}".format(user_answer, test_solutions[i]))