Tim Holloway wrote:I would be very interested in how you make the determination that a tuple is "strongly typed". Of the 3 languages that I can think of that can return tuples: LISP (a tuple here is a list), Python, Perl - and I think I had a 4th, but it just fell out of my mind. None of those languages defines a tuple with strong typing or even fixed-length. A Python or Perl method can have multiple return statements and each statement could return a simple value, a tuple, or some other data type like an array or dictionary and no two of those return statements would be obliged to return the same sort of thing(s).
I haven't dug into Scala enough to say whether it defines fixed-type tuples, but if so, it's an outlier. Not that I'd complain. Just pointing out that no such assurances occur in most other popular languages that can return tuples.
Knute Snortum wrote:Looks good!
I think you can simplify the Diagonal class to one field, and use
Also, in the Piece class, I'd add after line 38:
I haven't tested any of this, though.
Junilu Lacar wrote:One pair I worked with at Global Day of Coderetreat last Saturday had code like this:
That pair was actually working in Python but the code they had was essentially the same as that Java code.
My question to folks here is this: Would you see this code and think, "Oh, code smell..." or would you think it's a reasonable API?
I'd like to get some other opinions/perspectives before sharing what mine are.
Thanks!
Liutauras Vilda wrote:
Gerard Charles wrote:some of those neighborLocation values will be negative, but because the code calls worldWrapped they become positive. Logically, I'd expect setAlive to do the same thing.
This is what it does.
Liutauras Vilda wrote:
Gerard Charles wrote:because if the GUI's calculated location of a point is negative
Wondering how that could happen? Does it work like x and y axis where 0 is in a center? My model follows rows, columns idea starting from the upper left corner where 0's are.
Piet Souris wrote:We have arrived at a point where the discussion is hard to understand, if at all.
Anyway: what I was wondering: if incorporating some GUI makes it necessary to adjust the World code in places, then what is wrong with, or missing from, the design?
Liutauras Vilda wrote:
Gerard Charles wrote:It include's a drop down to include a couple gliders. The implementation of that needs to be able to add
locations modulo the grid, which is why the code is calling worldWrapped.
I don't think so. API does that already, you don't need to do that in a front-end. You just need to pass pattern's alive cells locations.
Gerard Charles wrote:The GUI intentionally messes with the world -- it allows the user to click on the grid and toggle cells on or off
Understand that, but since my nextGeneration() always construct a new world, for me it makes sense to have all in tact and don't rely on GUI implementor's vision. If GUI wants to change something, it can change through aliveAt(), deadAt(), that way I can assure that world is in consistent state. So getWorldMap() actually supposed to return immutable map.
Liutauras Vilda wrote:
World.java Cell at(Location) as well as worldWrapped(Location) instead private became both public. For what reason?
...
2. Map<Location, Cell> getWorldMap(), and that would be a copy of original, so front end couldn't mess up with world's state.
Liutauras Vilda wrote:
Gerard Charles wrote:I'm am curious as to your thought process in the static Location.of instead of simply having a public Location(int rowIndex, int columnIndex) constructor?
If you get a chance, read an Item 1 from Effective Java by Joshua Bloch. It has comprehensive chapter about that, advantanges and dis
However, my main reason was readability in this case. I really like that way, which seem to go in line what newer Java version follow as as naming convention, i.e.: List.of(...), Map.of(...).... Yes, new Location() is also fairly readable in this case.
One of other advantages could be, that I'm still left with an option to cache Location objects if I wanted to in a future, while habitual way to create object through constructor does not give you such flexibility, whenever you write "new" you create a new object.
Don't want to list other advantages and repeat what is way better written in a book, but there are quite a few advantages over constructors.
Junilu Lacar wrote:Names like WorldConsumer and CellConsumer are smelly.
Why not Consumer<World> or Consumer<Cell> instead?
See the difference?