AndInThreadsTest.java:49-51: Remove the use of the static...

[0pdd]

The puzzle 829-59f865f8 from #829 has to be resolved:

https://github.com/yegor256/cactoos/blob/995eb06e36912fe63f3ab22d1f992284084ee698/src/test/java/org/cactoos/scalar/AndInThreadsTest.java#L49-L51

The puzzle was created by Paulo Benety on 22-May-18.

Estimate: 30 minutes,

If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

[scristalli]

@0crat resign - this is taking way too long and I'd rather pass, in order to free up slots and improve reputation and metrics.

[0crat]

@0crat resign - this is taking way too long and I'd rather pass, in order to free up slots and im... (here)

@scristalli The user @scristalli/z resigned from #898, please stop working. Reason for job resignation: Order was cancelled

[0crat]

Tasks refusal is discouraged, see §6: -15 point(s) just awarded to @scristalli/z

[0crat]

The job #898 assigned to @iakunin/z, here is why; the budget is 30 minutes, see §4; please, read §8 and §9; if the task is not clear, read this and this; there will be no monetary reward for this job

[iakunin]

@paulodamaso, as I understand, I should create a mutable version of org.cactoos.collection.Synced, but it's not clear for me, how should I do that properly from architectural point of view.

Could you give me couple of advises?

[iakunin]

@0crat, waiting for @paulodamaso response

[0crat]

Are you speaking to me or about me here; you must always start your message with my name if you want to address it to me, see §1

[iakunin]

@0crat waiting for @paulodamaso response

[0crat]

@0crat waiting for @paulodamaso response (here)

@iakunin The impediment for #898 was registered successfully by @iakunin/z

[fabriciofx]

@paulodamaso @scristalli @victornoel @iakunin @llorllale @vzurauskas @skapral I don't like the idea of mutable collections or even mutable classes in Cactoos. To me, it's thw wrong approach to this problem. My suggestion is to implement a Persistent Data Structure (there's a nice discussion about it here) to make our collections trully immutable. WDYT?

[vzurauskas]

@fabriciofx As far as I can tell, the latest decision was for envelopes to delegate everything to the enveloped collection. If the collection is mutable, then the envelope is mutable; if the collection is immutable, then the envelope is immutable. For situations when client explicitly needs immutable collections, immutable decorators were supposed to be introduced.

I think this is a good decision because copying the entire collection every time something needs to be added or removed might be unfeasible sometimes, and also there are situations where it's very difficult to fit PDS into given architecture, and it's not obvious it would be worth it. Furthermore, I think there should be no logic in envelopes other than delegating to the enveloped object for the reasons I outlined here.

[victornoel]

@vzurauskas

…copying the entire collection every time something needs to be added or removed might be unfeasible sometimes.

This is not how persistent data structures work.

@fabriciofx That being said, maybe PDS is a good thing to implement, but it's another domain completely. Both needs exist (PDS or mutable collections) and they solve different problems. When doing OO, I personally see no problem with using mutable collections, except if it's used to implement DTO.

@paulodamaso Also another thing to take into account here is that it is great to want to reinvent the wheel, but we should be careful not to go too far where we are not able to succeed. Even implementing collections mutable or immutable is a big endeavour, and there exists already great OO libraries such as eclipse-collection (based on smalltalk collection design) and great PDS libraries in Java.

Personally I would continue the way it was planned, as @vzurauskas outlined.

[vzurauskas]

@victornoel Oh, right, my mistake.

[paulodamaso]

@fabriciofx @vzurauskas @victornoel @iakunin Here are my considerations about this ticket:

1. cactoos is, by definition, against the use of mutability (https://www.elegantobjects.org/#principles). So we shouldn't use mutable classes if we want to follow EO principles outlined in this link.
2. Following the extensive discussion in #898, #947 and #1008, the idea of providing the immutability by the use of decorators looks like reasonable to me, even though it goes against the principle outlined in 1
3. I like the idea of implementing PDS too, and I agree with @victornoel when he says that PDS is another problem domain; so, I think we should discuss it in another ticket.

So the real problem here is choosing between 1 and 2. I can't make this decision by myself since it changes the way cactoos follows EO principles. @yegor256 , what's your take on this? Which way should we follow, 1 (enforce immutability in all code blindly) or 2 (provide immutability by using decorators)?

[victornoel]

@paulodamaso this is one thing to have mutability in a class and have the "real world" state that an object represent to be mutable.

So a decorator for collections does not have to enforce immutability on the decorated collection, it should only prevent mutability of the reference to the decorated collection.

IMHO:

1. we shouldn't enforce immutability of decorated collection blindly: a decorator should do one and only one thing (so if it's job is mapping element of the decorated collection, it should only do that)
2. if we want a decorator that enforces immutability on the collection (an ImmutableCollection decorator), then it's a good idea, it can be composed with other when needed.

[fabriciofx]

@vzurauskas As @victornoel said, PDS are a completely different approach. It's made to perform immutable data sets properly.

@victornoel I see completly different. The immutable objects (mainly collections) is the heart of the problem because with mutable objects (or mutable collections) I can't share them properly. If I can shared, I've to copy them or I'll get problems with threads. I consider PDS into Cactoos a breakthrough in its development.

@paulodamaso I agree to discuss it in another ticket.

[skapral]

@paulodamaso @scristalli @victornoel @iakunin @llorllale @vzurauskas @skapral I don't like the idea of mutable collections or even mutable classes in Cactoos. To me, it's thw wrong approach to this problem. My suggestion is to implement a Persistent Data Structure (there's a nice discussion about it here) to make our collections trully immutable. WDYT?

@fabriciofx I'll just answer that I am neutral to this. Generally, I have no certain favourite between mutable or persistent collections, both have a right to live.

here

[iakunin]

@paulodamaso so what’s your final decision? What should I do in this issue?

[paulodamaso]

@yegor256 Ping, I still want your opinion on https://github.com/yegor256/cactoos/issues/898#issuecomment-533117749 question, please

[iakunin]

@yegor256 sorry for being so impatient, could you give your opinion about question mentioned above?

[yegor256]

@paulodamaso I vote for decorators. Keep in mind that 100% immutability is not only impossible, but is against the spirit of OOP. Please, read this: https://www.yegor256.com/2016/09/07/gradients-of-immutability.html

[iakunin]

@paulodamaso is it ok that PR already has been merged, todo has disappeared from the code, but this task is still open?

[0pdd]

The puzzle 829-59f865f8 has disappeared from the source code, that's why I closed this issue.

[0pdd]

@0pdd 5 puzzles #1217, #1218, #1219, #1220, #1221 are still not solved.

[0crat]

The job #898 is now out of scope

[0crat]

@sereshqua/z please review this job completed by @iakunin/z, as in §30; the job will be fully closed and all payments will be made when the quality review is completed

[sereshqua]

@0crat quality good

[0crat]

Order was finished, quality is "good": +35 point(s) just awarded to @iakunin/z

[0crat]

Quality review completed: +4 point(s) just awarded to @sereshqua/z

[0pdd]

@0pdd 5 puzzles #1217, #1218, #1220, #1221, #1230 are still not solved; solved: #1219.

[0pdd]

@0pdd 5 puzzles #1217, #1218, #1220, #1221, #1233 are still not solved; solved: #1219, #1230.

[0pdd]

@0pdd 4 puzzles #1217, #1220, #1221, #1233 are still not solved; solved: #1218, #1219, #1230.

[0pdd]

@0pdd 4 puzzles #1217, #1220, #1221, #1291 are still not solved; solved: #1218, #1219, #1230, #1233.

[0pdd]

@0pdd 3 puzzles #1217, #1220, #1221 are still not solved; solved: #1218, #1219, #1230, #1233, #1291.

[0pdd]

@0pdd 2 puzzles #1217, #1221 are still not solved; solved: #1218, #1219, #1220, #1230, #1233, #1291.

[0pdd]

@0pdd the puzzle #1221 is still not solved; solved: #1217, #1218, #1219, #1220, #1230, #1233, #1291.

[0pdd]

@0pdd the puzzle [#unknown]() is still not solved.

[0pdd]

@0pdd the puzzle #1645 is still not solved; solved: [#unknown]().

[0pdd]

@0pdd the puzzle [#unknown]() is still not solved; solved: #1217, #1218, #1219, #1220, #1221, #1230, #1233, #1291.

[0pdd]

@0pdd the puzzle #1730 is still not solved; solved: #1217, #1218, #1219, #1220, #1221, #1230, #1233, #1291.