Anonymous | Login | 01-26-2021 03:33 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0006535 | [Squeak] Collections | minor | always | 06-09-07 16:45 | 04-18-10 22:04 | ||||
Reporter | R4p70r | View Status | public | ||||||
Assigned To | andreas | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.10 | ||||||
Summary | 0006535: keyBlock and sortBlock are lost when creating a collection of the same species. | ||||||||
Description |
I’m not sure if this is the expected behavior or not... When a method in OrderedCollection or a KeyedSet return a new collection of it’s own kind, that new collection rarely use the keyBlock or sortBlock of the original. |
||||||||
Additional Information |
| element keyedSet | element := Dictionary with: (#a->1). "By default a KeyedSet will hash and compare the return value of #key on its elements. I want it to use (elem at: #a) instead " keyedSet := KeyedSet keyBlock: [:elem | elem at: #a]. keyedSet add: element. "keyedSet>>select attempts to return a new keyedSet without the sortBlock" keyedSet select: [:elem | true]. "Dictionary doesNotUnderstand key" | numbers reverseOrder firstThree | numbers := #(1 2 3 4 5). reverseOrder := SortedCollection sortBlock: [:x :y | x > y]. reverseOrder addAll: numbers. "The elements are inverted" self assert: [reverseOrder asArray = #(5 4 3 2 1)]. "Copy the first 3 elements" firstThree := reverseOrder copyFrom: 1 to: 3. "It appears to work" self assert: [firstThree asArray = #(5 4 3)]. "but we have lost the sort block" firstThree add: 1. " firstThree is now #(1 5 4 3)! " self assert: [firstThree asArray = #(5 4 3 1)] "fails" |
||||||||
Attached Files |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
||||||||
|
![]() |
|
(0012139 - 481 - 541 - 541 - 541 - 541 - 541) nicolas cellier 05-22-08 08:53 |
This is a critical bug and should have deserved more attention. I uploaded a patch based on postCopy paradigm. This patch rely on a shallowCopy... and SequenceableCollection>>shallowCopy would call copyFrom:to: loop infinitely. To circumvent this, i moved Object>>shallowCopy code in basicShallowCopy and called basicShallowCopy. Patch only address SortedCollection kind of copy methods, not KeyedCollection. There might be other senders of species to track and correct. |
(0012140 - 267 - 291 - 291 - 291 - 291 - 291) nicolas cellier 05-22-08 13:00 |
And now a test and patch for KeyedCollection addressing select: bug. Adopted solution is to define and use a copyEmpty in select:, just like OrderedCollection implementation. It would be possible to move select: and copyEmpty implementation at Collection level. |
(0012201 - 378 - 444 - 444 - 444 - 444 - 444) nicolas cellier 05-27-08 20:49 |
"fix begin" Installer mantis bug: 6535 fix:'SortedCollection-LooseSortBlock-Patch-M6535-nice.1.cs'. Installer mantis bug: 6535 fix:'KeyedCollection-LooseBlock-Patch-M6535-nice.1.cs'. "fix test" Installer mantis bug: 6535 fix:'SortedCollection-LooseSortBlock-Test-M6535-nice.1.cs'. Installer mantis bug: 6535 fix:'KeyedCollection-LooseBlock-Test-M6535-nice.1.cs'. "fix end" |
(0012211 - 200 - 218 - 218 - 218 - 218 - 218) nicolas cellier 05-28-08 19:31 |
#(3 3) copyFrom: 2 to: 0 would raise a debugger, and that kind of bug just happens when opening a 'Message Names' interface. So i had to protect OrderedCollection>>postCopyFrom:to: as a workaround. |
(0012212 - 378 - 444 - 444 - 444 - 444 - 444) nicolas cellier 05-28-08 19:32 |
"fix begin" Installer mantis bug: 6535 fix:'SortedCollection-LooseSortBlock-Patch-M6535-nice.2.cs'. Installer mantis bug: 6535 fix:'KeyedCollection-LooseBlock-Patch-M6535-nice.1.cs'. "fix test" Installer mantis bug: 6535 fix:'SortedCollection-LooseSortBlock-Test-M6535-nice.1.cs'. Installer mantis bug: 6535 fix:'KeyedCollection-LooseBlock-Test-M6535-nice.1.cs'. "fix end" |
(0013147 - 261 - 267 - 267 - 267 - 267 - 267) andreas 07-03-09 06:42 |
There is a major problem loading these changes. The change to OrderedCollection>>copyFrom:to: uses postCopyFrom:to: before that method is even defined. This screws up badly if it's ever called. Please split these change sets with the prerequisites coming first. |
(0013148 - 193 - 211 - 363 - 363 - 363 - 363) nicolas cellier 07-03-09 19:37 |
Yes, change sets order is definitely bogus. I realized that recently when porting to http://code.google.com/p/pharo/issues/detail?id=890 [^] But did not have time to provide feedback here yet... |
(0013339 - 396 - 432 - 432 - 432 - 432 - 432) nicolas cellier 10-05-09 00:43 |
I'm not really satisfied with creating an Object>>#basicShallowCopy message. I tested a far better solution: use the postCopy paradigm. Defining #postCopy in a few subclasses, we can abandon SequenceableCollection>>#shallowCopy and thus avoid #basicShallowCopy. This also apply to some unordered collections (Bag etc...) and enable removing a few #copy implementations. I will publish later. |
(0013342 - 475 - 553 - 553 - 553 - 553 - 553) nicolas cellier 10-05-09 08:56 |
"fix begin" Installer mantis ensureFix: 7404. Installer mantis bug: 6535 fix:'M6535-Patch-Prereq-OrderedCollection-postCopyFromto.st'. Installer mantis bug: 6535 fix:'M6535-Patch-OrderedCollection-postCopy.st'. Installer mantis bug: 6535 fix:'M6535-KeyedCollection-Patch.1.cs'. "fix test" Installer mantis bug: 6535 fix:'SortedCollection-LooseSortBlock-Test-M6535-nice.1.cs'. Installer mantis bug: 6535 fix:'KeyedCollection-LooseBlock-Test-M6535-nice.1.cs'. "fix end" |
(0013343 - 64 - 64 - 224 - 224 - 224 - 224) nicolas cellier 10-05-09 08:57 |
Fixed in http://source.squeak.org/trunk/Collections-nice.158.mcz [^] |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
109 total queries executed. 56 unique queries executed. |