list.Joined is uselessly copying data instead of being lazy

[victornoel]

I believe list.Joined could be implemented by storing the underlying Lists and delegating to them in each of the methods of List.

This would in particular be done by storing as a state of Joined an ordered collection (i.e., a list) of the underlying lists and computing the corresponding indexes of the elements dynamically.

There would be the need to introduce maybe some implementations for the iterators to do the same.

[0crat]

@paulodamaso/z please, pay attention to this issue

[paulodamaso]

@victornoel Let's first decide about cactoos lists fate in #1242 right?

[victornoel]

@0crat in

[baudoliver7]

@0crat status

[0crat]

@0crat status (here)

@baudoliver7 This is what I know about this job in C63314D6Z, as in §32:

• The job #1254 is in scope for 7mon
• The role is DEV
• The job is assigned to @baudoliver7/z for 2days
• There is no monetary reward attached, it's a free job
• The job doesn't have any impediments
• The budget is 30 minutes/points
• These users are banned and won't be assigned:
  • @victornoel/z: This user reported the ticket
• Job footprint (restricted area)

[baudoliver7]

@victornoel I dont catch very well what you mean. Could you give me more explanations ?

[victornoel]

@baudoliver7 currently, when you call the constructor of list.Joined, it will build a new list by copying the arguments. Instead, we should implement the List interface (and most certainly ListIterator) to wrap the lists passed as arguments and delegate to them as if they were one list.

[victornoel]

@baudoliver7 thx

[0crat]

@sereshqua/z please review this job completed by @baudoliver7/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

[0pdd]

@victornoel 2 puzzles #1561, #1562 are still not solved.

[0pdd]

@victornoel 2 puzzles #unknown, #unknown are still not solved.