Closed 0pdd closed 5 years ago
Job gh:yegor256/cactoos#898
is not assigned, can't get performer
@0crat waiting on outcome of #1008
@0crat waiting on outcome of #947
@0crat refuse
@0crat refuse
Job gh:yegor256/cactoos#898
already assigned to @longstone, can't assign to @longstone
@0crat refuse
@0crat refuse
@0crat waiting for #947
@0crat refuse
@0crat refuse, this task depends on https://github.com/yegor256/cactoos/issues/947
@0crat refuse, this task depends on https://github.com/yegor256/cactoos/issues/947 (here)
@vzurauskas Can't understand "refuse,", try one of these:
assign
Assign a performer to this issueboost
Set a boost for the jobcontinue
Remove a job's impedimenthello
Just say helloin
Register this issue in scope (WBS)out
Close the order and remove this job from scopepay
Pay a user some extra cashquality
Review a taskresign
Resign from this issuestatus
Check the status of the jobversion
Print current version of the botwait
Register an impediment for a job@0crat refuse this task, what's wrong with you? :)
@0crat waiting for #947
@llorllale this task requires a mutable collection by its description and previous comments, topic that is already present in #1008, addressed as a duplicate of #947, and postponed after release 1.0. Is the release expected soon? Otherwise, is there any chance this task can be closed and put out of scope for now? It seems that it can't be solved at the moment and it only blocks slots for other jobs.
Thank you.
@llorllale can I ask for an update on this? I'd just like to know what timeframe is expected for release 1.0, so that mutable collections can be discussed. I'd like not to refuse tasks, but depending on the actual feasability of this I don't want to hold it for months either.
@scristalli just do this for now:
Remove the use of the static method
Collections.synchronizedList
. Replace by an object-oriented approach.
@llorllale I don't think the task can be split like so: an object-oriented approach would require a class like Collections.SynchronizedList
(which is the one used by the static method), too bad it's private.
Unless of course leaving simple, unwrapped ArrayList
, but that would make the code not thread-safe anymore.
The tests here create a collection, and then modify it by adding elements to it.
The only options I see:
Synced
. If this will be probably allowed after release 1.0, then I would like to know how far the project is from it.Have I missed something?
@scristalli you can proceed with Synced
@llorllale thanks for unblocking this. I'm following discussion in #947, which I think needs to be solved before this. I would happily avoid to Create a class similar to SyncCollection but mutable
if a more general solution is approved in the project.
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.