You should keep internal state of your class hidden to the user. My solution should not pass, I guess. Alternatively, don't use classes and just provide a string and expect an array as result.

Apologies for the delay - updated back to [0].

According to voile, the change about empty columns must be reverted (See thread below / sorry about that...)

fine, but it still doesn't make any sense.

Bruh, why is [0] changed to []? [0] is the standard representation of an empty row/column clue in Picross, so if we're doing a kata bout Picross we should be following standard notations.

Yep, replace is certainly a better fit. I'd probably prefer multiline for clarity, as you suggest, but this is clearly superior to split/filter/map.

Oh no my implementation (like most implementations actually I assume) would actually be simpler without this 0 constraint. I wrote the description and classes before writing a solution, so my implementation didn't have any impact on any of those. I just thought it would be almost equally likely in the development of a game like this to be decided to have a 0 (for any reason) rather than an empty array.

Yeah I mean I agree it's not good to generalize bad designs, but I feel like katas are more to train coding itself than design decisions. And in this context, flexibility is a good skill to train.

But yeah sure, I'll change it, I'm not really attached to that part of the challenge anyway

Thanks! I will switch to that

thing is, this 0 is related to an internal choice of your implementation. It feels like "I didn't find a simple way to get an empty array, so let's use [0] instead". That looks suboptimal and decreases (imo) the overall quality of the kata.

To clarify, I don't see ideas like (summarizing roughly) "shits happen in real life, so let's implement some weird things here too" as good ideas. That's sort of reinforcing the idea that it's not a problem to create a bad design since it happens everywhere. I'm against this idea. A better train of thoughts is imo: "let's do our best. Maybe we'll make mistakes, but at least let's avoid antipatterns". See my point? So yeah, I don't like that [0] thing at all. ;)

About this, I feel like the only thing needed is reformatting a part of the description.

Reomve this sentence:

Each cell in the context of this kata will have a value of either PicrossBoard.FILLED or PicrossBoard.EMPTY.

and push it as first bullet point just after, rewording it a bit:

• Each cell has a value/state that can be either PicrossBoard.FILLED or PicrossBoard.EMPTY.

With that, the info stands out more and that should resolve the ambiguity.

Oops, looks like I was testing my tests and forgot to re-enable them for the randomly generated ones... That explains it! I've addressed most of your comments btw (tried to make the description more explicit)

I agree, with my "rather than" I was trying to imply "even if it is less semantic and intuitive than".

"By design" in this case for me means "What has been decided for this project", which could be for example because most Picross games do show a 0 next to empty rows rather than leaving the clues empty (although I agree that this should rather be done when the clues get displayed rather than being actually internally represented by a 0). I added this as one of these maybe slightly suboptimal real-world type of constraints.

I'm open to change it in the kata if there is a strong opinion against it, but in the end this is really just a convention, so I do not think this is that much of a problem as long as it is clearly specified.

I don't know... On my two solutions, the fist (long) one is the problematic one because I used board.column(...). You can explore its behavior with the random tests through its fork panel.

Thanks!! Apologies, I completely missed that one.

And yeah the random tests are generating non-square grids, so I am unsure why they would work. I think my tests were generating wrong solutions which happened to match yours maybe? Not entirely sure

Yeah I do think that "value" is still ok as for me it doesn't necessary imply any type. For example in my head even a function could be considered the "value" of a variable.

But it does depends on everyone's definition of value and I agree that a portion of people would misinterpret it as being a number. I will try to clarify!