replace classes with functions in challenge package

[tyrcho]

I'm trying to simplify this package to use more FP and les OO.

I'll try to make use of the State pattern in package fp.state ...

[huiwang]

For me, defining a trait doesn't imply OO. OO is about encasuplating states inside class and offer possiblity to mutate them through methods.

I consider traits as contracts. It doesn't impose a specific underlying paradigm to implement that contract. One thing I notice that we lose the opportunity to document the contract if we remove traits.

[tyrcho]

sure, the debate is not really about OO vs FP :)

I'm just trying to remove some boilerplate here.

About documenting, we can document the arguments of the method GameLoop.run

What do you think about this new design ? For me it's simpler to learn, only 1 object (GameLoop) to look at.

[huiwang]

GameLoop is a control structure. It's something built on top of the primitive concepts. In the past, I had a local arenna control strucutre which allows two players to play many rounds of game.

In other words, I'd prefer to keep the primitive concpets such as io, bot, accumulator in dedicated place. I might not rely on a control strucutre to document the primitive concepts.

[huiwang]

I'm afraid that we are going in two completly different directions. My original proposal is to make better seprations of concepts and now we are talking about the necessity to have traits or not.

[tyrcho]

OK, I'm done with this proposal. Feel free to reject it, I won't be hurt :)

It just seems clearer to me this way, but I can understand that you look at it differently ...

I can't integrate with my State monad class which is for a different purpose (representing State transformations).

[tyrcho]

It also gives more freedom to the developper using the GameLoop object, he can still use classes or just the functions.

[tyrcho]

maybe @Wei-1 you could also give your opinion, more as a "user" of the kit, you should have a fresh eye. Which design do you prefer here ? traits or simple functions ?

[tyrcho]

I discussed about this design with colleagues over lunch and they brought a few valid points :

• a trait is useful when we group several functions which are implemented together (you mentioned that already @huiwang). I restored the trait GameIO in this branch. It also has the benefit of limiting the number of arguments to the run function.
• a trait with a single method can be useful if this method is used in several places in the code, to share the intent and documentation about it. I don't think it was the case for the GamePlayer trait yet, but it could become useful if we continue building the framework. For instance RulesFor2p.judge method could reuse this GamePlayer trait instead of S => M.

[tyrcho]

This last commit comes from an idea I discovered in a refactoring code retreat. If you can externalize all your dependencies (like IO, RNG) it makes the code much easier to test.

Usage of implicits and duck typing (the types in the package object) is debatable; I like it because it keeps a default sensible behaviour for users, but it exposes the implicits in the signatures we have to implement in WondevIO.

[Wei-1]

Actually, I use scalac instead of sbt for contest. So what I will do is that I will copy the useful pieces into my code. Therefore, I didn't use a lot of trait. Functions are more straight forward to me.

[huiwang]

It's nice to have collegues who can discuss over lunch!

I'm also thinking about which to choose between trait and lambda. It's quite interesting.

When I have something important to say, I would use a trait. This tells the developer that it's an important concept in the framework. This has nothing to do with the number of methods neither how people are going to implement that interface. Examples can be the Serializable trait in scala/java, collector interface in java, etc.

Unlike trait, lambda is more concrete, more about paradigm, less related to concept. For example, when I want to filter a collection, we use lambda as predicate; when i want to transform a list of object, i use lambda as mapper.

In our case, I consider both IO, Bot, Accumulator, Simulator as first-class concept, It's our way to shape our Bot. These concepts enable many features as debugging, performance tuning and simulation as the rationals explained in the blog post. That's why I find they worth a trait.

[huiwang]

@tyrcho let's discuss it later when more feedbacks are collected.