The Inbox: Collections-pre.838.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Collections-pre.838.mcz

commits-2
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+ "Based on Dictionary>>#printElementsOn:"
+
+ aStream nextPut: $(.
+ self size > 100
+ ifTrue: [aStream nextPutAll: 'size '.
+ self size printOn: aStream]
+ ifFalse: [order do: [:assoc | assoc ifNotNil: [
+ assoc printOn: aStream. aStream space]]].
+ aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+ | interval result |
+ result := OrderedDictionary new.
+ 1 to: self size do: [:i |
+ (self at: i) do: [:value |
+ interval := result at: value ifAbsentPut: (i to: i).
+ result at: value put: (interval start to: i)]].
+ ^ result
+ !


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

Chris Muller-3
Hi Patrick,

Would you be willing to employ the highest-level methods possible?   "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?

It looks like it would put a space before the last paren.  Picky, I know, but there is #do:separatedBy: to the rescue.  I guess you could pre-allocate the OrderedDictionary to the proper size.

For the RunArray, could #runsAndValuesDo: help here?  I'm having trouble following this code.  At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.

Best,
  Chris









On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+       "Based on Dictionary>>#printElementsOn:"
+       
+       aStream nextPut: $(.
+       self size > 100
+               ifTrue: [aStream nextPutAll: 'size '.
+                       self size printOn: aStream]
+               ifFalse: [order do: [:assoc | assoc ifNotNil: [
+                                       assoc printOn: aStream. aStream space]]].
+       aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+       | interval result |
+       result := OrderedDictionary new.
+       1 to: self size do: [:i |
+               (self at: i) do: [:value |
+                       interval := result at: value ifAbsentPut: (i to: i).
+                       result at: value put: (interval start to: i)]].
+       ^ result
+       !




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

marcel.taeumel
Hi, there.

From the client's perspective, isn't #do: already an abstraction level higher than #assocationsDo:? It is so on the implementation side, too - at least in Collection. Swapped in Dictionary and OrderedDictionary, though.

Collection >> associationsDo: aBlock
"Evaluate aBlock for each of the receiver's elements (key/value 
associations).  If any non-association is within, the error is not caught now,
but later, when a key or value message is sent to it."

self do: aBlock

Dictionary >> associationsDo: aBlock 
"Evaluate aBlock for each of the receiver's elements (key/value 
associations)."

tally = 0 ifTrue: [ ^self].
1 to: array size do: [ :index |
(array at: index) ifNotNil: [ :element |
aBlock value: element ] ]

OrderedDictionary >> associationsDo: aBlock
"Iterate over the order instead of the internal array."

order from: 1 to: tally do: aBlock

Best,
Marcel

Am 01.07.2019 02:47:26 schrieb Chris Muller <[hidden email]>:

Hi Patrick,

Would you be willing to employ the highest-level methods possible?   "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?

It looks like it would put a space before the last paren.  Picky, I know, but there is #do:separatedBy: to the rescue.  I guess you could pre-allocate the OrderedDictionary to the proper size.

For the RunArray, could #runsAndValuesDo: help here?  I'm having trouble following this code.  At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.

Best,
  Chris









On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+       "Based on Dictionary>>#printElementsOn:"
+       
+       aStream nextPut: $(.
+       self size > 100
+               ifTrue: [aStream nextPutAll: 'size '.
+                       self size printOn: aStream]
+               ifFalse: [order do: [:assoc | assoc ifNotNil: [
+                                       assoc printOn: aStream. aStream space]]].
+       aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+       | interval result |
+       result := OrderedDictionary new.
+       1 to: self size do: [:i |
+               (self at: i) do: [:value |
+                       interval := result at: value ifAbsentPut: (i to: i).
+                       result at: value put: (interval start to: i)]].
+       ^ result
+       !




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

Chris Muller-3

Hi, there.

From the client's perspective, isn't #do: already an abstraction level higher than #assocationsDo:?

Not when one accounts for the receiver.  

    order do: [ ... ]

has to make assumptions about the internal representation, and it duplicates the responsibility for enumerating the receiver just to do some broader function (printing elements), even though the receiver already has a method to do that enumeration.

   self associationsDo: [ ... ]

Best,
  Chris


 
It is so on the implementation side, too - at least in Collection. Swapped in Dictionary and OrderedDictionary, though.



 

Collection >> associationsDo: aBlock
"Evaluate aBlock for each of the receiver's elements (key/value 
associations).  If any non-association is within, the error is not caught now,
but later, when a key or value message is sent to it."

self do: aBlock

Dictionary >> associationsDo: aBlock 
"Evaluate aBlock for each of the receiver's elements (key/value 
associations)."

tally = 0 ifTrue: [ ^self].
1 to: array size do: [ :index |
(array at: index) ifNotNil: [ :element |
aBlock value: element ] ]

OrderedDictionary >> associationsDo: aBlock
"Iterate over the order instead of the internal array."

order from: 1 to: tally do: aBlock

Best,
Marcel

Am 01.07.2019 02:47:26 schrieb Chris Muller <[hidden email]>:

Hi Patrick,

Would you be willing to employ the highest-level methods possible?   "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?

It looks like it would put a space before the last paren.  Picky, I know, but there is #do:separatedBy: to the rescue.  I guess you could pre-allocate the OrderedDictionary to the proper size.

For the RunArray, could #runsAndValuesDo: help here?  I'm having trouble following this code.  At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.

Best,
  Chris









On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+       "Based on Dictionary>>#printElementsOn:"
+       
+       aStream nextPut: $(.
+       self size > 100
+               ifTrue: [aStream nextPutAll: 'size '.
+                       self size printOn: aStream]
+               ifFalse: [order do: [:assoc | assoc ifNotNil: [
+                                       assoc printOn: aStream. aStream space]]].
+       aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+       | interval result |
+       result := OrderedDictionary new.
+       1 to: self size do: [:i |
+               (self at: i) do: [:value |
+                       interval := result at: value ifAbsentPut: (i to: i).
+                       result at: value put: (interval start to: i)]].
+       ^ result
+       !





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

marcel.taeumel
...and if you avoid looking at the implementation of #do: and #associationsDo:? The term "associations" leaks some internal representation detail. :-)

Best,
Marcel

Am 01.07.2019 21:29:20 schrieb Chris Muller <[hidden email]>:


Hi, there.

From the client's perspective, isn't #do: already an abstraction level higher than #assocationsDo:?

Not when one accounts for the receiver.  

    order do: [ ... ]

has to make assumptions about the internal representation, and it duplicates the responsibility for enumerating the receiver just to do some broader function (printing elements), even though the receiver already has a method to do that enumeration.

   self associationsDo: [ ... ]

Best,
  Chris


 
It is so on the implementation side, too - at least in Collection. Swapped in Dictionary and OrderedDictionary, though.



 

Collection >> associationsDo: aBlock
"Evaluate aBlock for each of the receiver's elements (key/value 
associations).  If any non-association is within, the error is not caught now,
but later, when a key or value message is sent to it."

self do: aBlock

Dictionary >> associationsDo: aBlock 
"Evaluate aBlock for each of the receiver's elements (key/value 
associations)."

tally = 0 ifTrue: [ ^self].
1 to: array size do: [ :index |
(array at: index) ifNotNil: [ :element |
aBlock value: element ] ]

OrderedDictionary >> associationsDo: aBlock
"Iterate over the order instead of the internal array."

order from: 1 to: tally do: aBlock

Best,
Marcel

Am 01.07.2019 02:47:26 schrieb Chris Muller <[hidden email]>:

Hi Patrick,

Would you be willing to employ the highest-level methods possible?   "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?

It looks like it would put a space before the last paren.  Picky, I know, but there is #do:separatedBy: to the rescue.  I guess you could pre-allocate the OrderedDictionary to the proper size.

For the RunArray, could #runsAndValuesDo: help here?  I'm having trouble following this code.  At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.

Best,
  Chris









On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+       "Based on Dictionary>>#printElementsOn:"
+       
+       aStream nextPut: $(.
+       self size > 100
+               ifTrue: [aStream nextPutAll: 'size '.
+                       self size printOn: aStream]
+               ifFalse: [order do: [:assoc | assoc ifNotNil: [
+                                       assoc printOn: aStream. aStream space]]].
+       aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+       | interval result |
+       result := OrderedDictionary new.
+       1 to: self size do: [:i |
+               (self at: i) do: [:value |
+                       interval := result at: value ifAbsentPut: (i to: i).
+                       result at: value put: (interval start to: i)]].
+       ^ result
+       !





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

marcel.taeumel
Hi Chris,

sorry, I did oversee the "self vs. order" aspect. Need more coffee. :-) 

Yes, I would also prefer to use a public interface (here: self) over an implementation detail (here: order). Consequently, "self do: ..." would not work because we need the associations for this printing method and #do: maps to #valuesDo: for dictionaries. 

So, I am in favor of "self associationsDo:" instead of "order do:".

Thanks for your patience. :-D

Best,
Marcel

Am 02.07.2019 08:58:10 schrieb Marcel Taeumel <[hidden email]>:

...and if you avoid looking at the implementation of #do: and #associationsDo:? The term "associations" leaks some internal representation detail. :-)

Best,
Marcel

Am 01.07.2019 21:29:20 schrieb Chris Muller <[hidden email]>:


Hi, there.

From the client's perspective, isn't #do: already an abstraction level higher than #assocationsDo:?

Not when one accounts for the receiver.  

    order do: [ ... ]

has to make assumptions about the internal representation, and it duplicates the responsibility for enumerating the receiver just to do some broader function (printing elements), even though the receiver already has a method to do that enumeration.

   self associationsDo: [ ... ]

Best,
  Chris


 
It is so on the implementation side, too - at least in Collection. Swapped in Dictionary and OrderedDictionary, though.



 

Collection >> associationsDo: aBlock
"Evaluate aBlock for each of the receiver's elements (key/value 
associations).  If any non-association is within, the error is not caught now,
but later, when a key or value message is sent to it."

self do: aBlock

Dictionary >> associationsDo: aBlock 
"Evaluate aBlock for each of the receiver's elements (key/value 
associations)."

tally = 0 ifTrue: [ ^self].
1 to: array size do: [ :index |
(array at: index) ifNotNil: [ :element |
aBlock value: element ] ]

OrderedDictionary >> associationsDo: aBlock
"Iterate over the order instead of the internal array."

order from: 1 to: tally do: aBlock

Best,
Marcel

Am 01.07.2019 02:47:26 schrieb Chris Muller <[hidden email]>:

Hi Patrick,

Would you be willing to employ the highest-level methods possible?   "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?

It looks like it would put a space before the last paren.  Picky, I know, but there is #do:separatedBy: to the rescue.  I guess you could pre-allocate the OrderedDictionary to the proper size.

For the RunArray, could #runsAndValuesDo: help here?  I'm having trouble following this code.  At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.

Best,
  Chris









On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
Patrick Rein uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-pre.838.mcz

==================== Summary ====================

Name: Collections-pre.838
Author: pre
Time: 28 June 2019, 12:11:16.302033 pm
UUID: db29f1b2-09b5-f045-aa21-9379185664df
Ancestors: Collections-pre.837

Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.

=============== Diff against Collections-pre.837 ===============

Item was added:
+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
+ printElementsOn: aStream
+       "Based on Dictionary>>#printElementsOn:"
+       
+       aStream nextPut: $(.
+       self size > 100
+               ifTrue: [aStream nextPutAll: 'size '.
+                       self size printOn: aStream]
+               ifFalse: [order do: [:assoc | assoc ifNotNil: [
+                                       assoc printOn: aStream. aStream space]]].
+       aStream nextPut: $)!

Item was added:
+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
+ asValuesAndIntervals
+
+       | interval result |
+       result := OrderedDictionary new.
+       1 to: self size do: [:i |
+               (self at: i) do: [:value |
+                       interval := result at: value ifAbsentPut: (i to: i).
+                       result at: value put: (interval start to: i)]].
+       ^ result
+       !





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-pre.838.mcz

patrick.rein
Hi Marcel, Hi Chris,

I have updated the printString method for OrderedDictionary. I also removed the RunArray method for now as I realized it is tightly bound to the way it is used in Text objects.

When this is merged into trunk I also have a test case for this to contribute.

VG
Patrick

>Hi Chris,
>sorry, I did oversee the "self vs. order" aspect. Need more coffee. :-)
>Yes, I would also prefer to use a public interface (here: self) over an implementation detail (here: order). Consequently, "self do: ..." would not work because we need the associations for this printing method and #do: maps to #valuesDo: for dictionaries.
>So, I am in favor of "self associationsDo:" instead of "order do:".
>Thanks for your patience. :-D
>Best,Marcel
>
>Am 02.07.2019 08:58:10 schrieb Marcel Taeumel <[hidden email]>: ...and if you avoid looking at the implementation of #do: and #associationsDo:? The term "associations" leaks some internal representation detail. :-)
>Best,Marcel
>
>Am 01.07.2019 21:29:20 schrieb Chris Muller <[hidden email]>:
>
>
>Hi, there.
>From the client's perspective, isn't #do: already an abstraction level higher than #assocationsDo:?
>
>
>Not when one accounts for the receiver.
>order do: [ ... ]
>has to make assumptions about the internal representation, and it duplicates the responsibility for enumerating the receiver just to do some broader function (printing elements), even though the receiver already has a method to do that enumeration.
>self associationsDo: [ ... ]
>
>Best, Chris
>
>It is so on the implementation side, too - at least in Collection. Swapped in Dictionary and OrderedDictionary, though.
>
>
>
>
>
>Collection >> associationsDo: aBlock"Evaluate aBlock for each of the receiver's elements (key/value associations). If any non-association is within, the error is not caught now,but later, when a key or value message is sent to it."
>self do: aBlock
>Dictionary >> associationsDo: aBlock "Evaluate aBlock for each of the receiver's elements (key/value associations)."
>tally = 0 ifTrue: [ ^self].1 to: array size do: [ :index |(array at: index) ifNotNil: [ :element |aBlock value: element ] ]
>OrderedDictionary >> associationsDo: aBlock"Iterate over the order instead of the internal array."
>order from: 1 to: tally do: aBlock
>Best,Marcel
>
>Am 01.07.2019 02:47:26 schrieb Chris Muller <[hidden email]>: Hi Patrick,
>Would you be willing to employ the highest-level methods possible? "order do: [ .... ", creates an unnecessary dependency on the implementation when it appears #associationsDo: would work fine..?
>It looks like it would put a space before the last paren. Picky, I know, but there is #do:separatedBy: to the rescue. I guess you could pre-allocate the OrderedDictionary to the proper size.
>For the RunArray, could #runsAndValuesDo: help here? I'm having trouble following this code. At least in core code, #at:ifAbsentPut: should take a block for the second argument, IMO.
>Best, Chris
>
>
>
>
>
>
>
>
>On Fri, Jun 28, 2019 at 5:11 AM <[hidden email]> wrote:
>
>Patrick Rein uploaded a new version of Collections to project The Inbox:
>http://source.squeak.org/inbox/Collections-pre.838.mcz
>
>==================== Summary ====================
>
>Name: Collections-pre.838
>Author: pre
>Time: 28 June 2019, 12:11:16.302033 pm
>UUID: db29f1b2-09b5-f045-aa21-9379185664df
>Ancestors: Collections-pre.837
>
>Two method additions to Collection. The first adds ordered printing to OrderedDictionaries, to allow users to actually see the ordering. The second adds a method to convert a run array into an expanded version of the runs.
>
>=============== Diff against Collections-pre.837 ===============
>
>Item was added:
>+ ----- Method: OrderedDictionary>>printElementsOn: (in category 'printing') -----
>+ printElementsOn: aStream
>+ "Based on Dictionary>>#printElementsOn:"
>+
>+ aStream nextPut: $(.
>+ self size > 100
>+ ifTrue: [aStream nextPutAll: 'size '.
>+ self size printOn: aStream]
>+ ifFalse: [order do: [:assoc | assoc ifNotNil: [
>+ assoc printOn: aStream. aStream space]]].
>+ aStream nextPut: $)!
>
>Item was added:
>+ ----- Method: RunArray>>asValuesAndIntervals (in category 'converting') -----
>+ asValuesAndIntervals
>+
>+ | interval result |
>+ result := OrderedDictionary new.
>+ 1 to: self size do: [:i |
>+ (self at: i) do: [:value |
>+ interval := result at: value ifAbsentPut: (i to: i).
>+ result at: value put: (interval start to: i)]].
>+ ^ result
>+ !
>
>
>
>------=_NextPart_57207943.746499292039--