- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MessageNotUnderstood: SmallInteger>>isEmpty

by Eliot Miranda

Hi Dario, On Tue, Dec 10, 2013 at 8:12 AM, Dario Trussardi <dario.trussardi(a)tiscali.it > wrote: > Ciao, > > i work with a new Pharo 2.0 20628 image. > > I do first : > A) Gofer new url: ' > http://smalltalkhub.com/mc/DiegoLont/QCMagritte/main'; package: > 'ConfigurationOfQCMagritte'; load. > > and: > B) ((Smalltalk at: #ConfigurationOfQCMagritte) project > version: '0.2') load: #( 'Demo' ). > > After some works the system when Fetching 1.0.2.1 of > ConfigurationOfTwitteBootstrap > > erase the error: > > > SmallInteger(Object)>>doesNotUnderstand: #isEmpty > MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: > MetacelloMCVersionSpec>>resolveToLoadableSpecs: > MetacelloMCVersionSpec>>expandToLoadableSpecNames: in Block: [:cache | ... > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > in Block: [:dict | ... > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > in Block: [^ aBlock value: dict] > BlockClosure>>on:do: > > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:at:doing: > MetacelloMCVersionSpec>>expandToLoadableSpecNames: > MetacelloMCVersion>>expandToLoadableSpecNames: > MetacelloMCProjectSpec>>relativeCurrentVersion in Block: [vrsn > expandToLoadableSpecNames: (loadList := self...etc... > BlockClosure>>on:do: > MetacelloMCProjectSpec>>relativeCurrentVersion > MetacelloProjectReferenceSpec>>relativeCurrentVersion > MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: in Block: [:prj | ... > MetacelloProjectReferenceSpec>>projectDo:packageDo:groupDo: > MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: in Block: > [:name | | pkgSpec | (pkgSpec := map... > Array(SequenceableCollection)>>do: > MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: > MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: > MetacelloMCVersionSpec>>isPartiallyCurrent > MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: > [:version | ... > Array(SequenceableCollection)>>do: > MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: > [:cache | ... > MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: > in Block: [:dict | ... > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > in Block: [^ aBlock value: dict] > BlockClosure>>on:do: > > MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: > > Any idea? > I suspect you have an older, buggy, VM. What does the VM say to -version? > Thanks, > > Dario > -- HTH, Eliot

Dec. 10, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by Sven Van Caekenberghe

On 10 Dec 2013, at 17:48, phil(a)highoctane.be wrote: > Looks useful indeed. Thx. Thanks. > I like the useSemaphore thing. If you need it, it is necessary. Otherwise it slows things down. > Question: what does Neo stands for as prefix? I wonder. Makes me think of The Matrix and Red Pills. Ah, itâs just the name of a namespace, I usually think of it as âNewâ, but yes there is a Matrix link also ;-) > Phil > > > > > On Tue, Dec 10, 2013 at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Caching is an important technique to trade time (speed of execution) for space (memory consumption) in computation. Used correctly, caching can significantly improve an applicationâs performance. > > Given the key/value nature of a cache, a Dictionary is often the first data structure used for implementing it. This is however not a good idea since a simple Dictionary is unbounded by definition and can/will lead to explosive cache growth. > > Quick and dirty hacks to turn a Dictionary into a least-recently-used (LRU) and/or time-to-live (TTL) based limited cache are often incorrect and inefficient. > > The LRUCache implementation currently in Pharo is too simple and not efficient, being O(n) on its main operation. > > Pharo deserves and needs a good LRU/TTL cache implementation that can/should be used uniformly in various places of the system and in code built on top of it. That is why I implemented a proposal. > > Neo-Caching is an implementation of both a good LRU cache as well as a TTL extension of it. The caches are easy to use, yet have a number of interesting features. The implementation is properly O(1) on its main operations and is 2 to 3 times faster than LRUCache. The package also contains a double linked list implementation. The code comes with a full set of unit tests. There are class and method comments and the code is easy to read. > > The code (which has no dependencies) can be found here > > http://mc.stfx.eu/Neo > http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/Neo/main > > There is only one package to load. The code has been written in Pharo 3.0 but it should run on older versions as well. > > > Code > > > Letâs create a 16K ordered collection of keys that have some repetitions in them with a reasonable distribution: > > data := Array streamContents: [ :out | > 1 to: 4096 do: [ :each | > each primeFactorsOn: out. > out nextPut: each ] ]. > data := data collect: [ :each | each asWords ]. > > By using #asWords the keys have better hash properties. Now, we put all this in a cache: > > cache := NeoLRUCache new. > cache maximumWeight: 512. > cache factory: [ :key | key ]. > data do: [ :each | cache at: each ]. > cache. > > ==> a NeoLRUCache(#512 512/512 [ 1 ] [ :key | key ] 72%) > > We had a 72% hit ratio, which is good. The cache is of course full, 512/512 with 512 entries (not necessarily the same thing, see further). > > We can now benchmark this: > > [ data do: [ :each | cache at: each ] ] bench. > > ==> '35.8 per second.â > > And compare it to LRUCache: > > cache := LRUCache size: 512 factory: [ :key | key ]. > > [ data do: [ :each | cache at: each ] ] bench. > > ==> '12.6 per second.â > > > Features > > > Instead of just counting the number of entries, which is the default behaviour, the concept of weight is used to determine when a cache is full. For each cached value, a block or selector is used to compute its weight. When adding a new entry causes the weight to exceed a maximum, eviction of the least recently used item(s) takes place, until the weight is again below the maximum. > > cache > computeWeight: #sizeInMemory; > maximumWeight: 16*1024. > > Will keep the cache below 16Kb in real memory usage. This can be very useful when caching various sized images or MC packages, for example. > > By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. > > cache useSemaphore. > > NeoTTLCache extends NeoLRUCache by maintaining a timestamp for each cached value. Upon cache hit, there is a check to see if this timestamp is not older than the allowed time to live. If so, the value is stale and will be recomputed. > > (cache := NeoTTLCache new) > timeToLive: 10 minutes; > factory: [ :key | ZnEasy get: key ]; > maximumWeight: 32*1024; > computeWeight: #contentLength. > > cache at: âhttp://zn.stfx.eu/zn/numbers.txt'. > > ==> a ZnResponse(200 OK text/plain;charset=utf-8 71B) > > cache > > ==> a NeoTTLCache(#1 71/32768 #contentLength [ :key | ZnEasy get: key ] 0% 0:00:10:00) > > Would be a simple HTTP cache, keeping resolved URLs in memory for 10 minutes maximum before refreshing them. It uses #contentLength on ZnResponse to compute the weight. You can see from the print string that there is now 1 entry, while the weight is 17 bytes out of 32768. > > > These are the main points, please have a look at the code. Feedback is welcome. > > Regards, > > Sven > > >

Dec. 10, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by phil＠highoctane.be

Looks useful indeed. Thx. I like the useSemaphore thing. Question: what does Neo stands for as prefix? I wonder. Makes me think of The Matrix and Red Pills. Phil On Tue, Dec 10, 2013 at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Caching is an important technique to trade time (speed of execution) for > space (memory consumption) in computation. Used correctly, caching can > significantly improve an applicationâs performance. > > Given the key/value nature of a cache, a Dictionary is often the first > data structure used for implementing it. This is however not a good idea > since a simple Dictionary is unbounded by definition and can/will lead to > explosive cache growth. > > Quick and dirty hacks to turn a Dictionary into a least-recently-used > (LRU) and/or time-to-live (TTL) based limited cache are often incorrect and > inefficient. > > The LRUCache implementation currently in Pharo is too simple and not > efficient, being O(n) on its main operation. > > Pharo deserves and needs a good LRU/TTL cache implementation that > can/should be used uniformly in various places of the system and in code > built on top of it. That is why I implemented a proposal. > > Neo-Caching is an implementation of both a good LRU cache as well as a TTL > extension of it. The caches are easy to use, yet have a number of > interesting features. The implementation is properly O(1) on its main > operations and is 2 to 3 times faster than LRUCache. The package also > contains a double linked list implementation. The code comes with a full > set of unit tests. There are class and method comments and the code is easy > to read. > > The code (which has no dependencies) can be found here > > http://mc.stfx.eu/Neo > http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/Neo/main > > There is only one package to load. The code has been written in Pharo 3.0 > but it should run on older versions as well. > > > Code > > > Letâs create a 16K ordered collection of keys that have some repetitions > in them with a reasonable distribution: > > data := Array streamContents: [ :out | > 1 to: 4096 do: [ :each | > each primeFactorsOn: out. > out nextPut: each ] ]. > data := data collect: [ :each | each asWords ]. > > By using #asWords the keys have better hash properties. Now, we put all > this in a cache: > > cache := NeoLRUCache new. > cache maximumWeight: 512. > cache factory: [ :key | key ]. > data do: [ :each | cache at: each ]. > cache. > > ==> a NeoLRUCache(#512 512/512 [ 1 ] [ :key | key ] 72%) > > We had a 72% hit ratio, which is good. The cache is of course full, > 512/512 with 512 entries (not necessarily the same thing, see further). > > We can now benchmark this: > > [ data do: [ :each | cache at: each ] ] bench. > > ==> '35.8 per second.â > > And compare it to LRUCache: > > cache := LRUCache size: 512 factory: [ :key | key ]. > > [ data do: [ :each | cache at: each ] ] bench. > > ==> '12.6 per second.â > > > Features > > > Instead of just counting the number of entries, which is the default > behaviour, the concept of weight is used to determine when a cache is full. > For each cached value, a block or selector is used to compute its weight. > When adding a new entry causes the weight to exceed a maximum, eviction of > the least recently used item(s) takes place, until the weight is again > below the maximum. > > cache > computeWeight: #sizeInMemory; > maximumWeight: 16*1024. > > Will keep the cache below 16Kb in real memory usage. This can be very > useful when caching various sized images or MC packages, for example. > > By default, no concurrent access protection takes place, but optionally a > semaphore for mutual exclusion can be used. This slows down access. > > cache useSemaphore. > > NeoTTLCache extends NeoLRUCache by maintaining a timestamp for each cached > value. Upon cache hit, there is a check to see if this timestamp is not > older than the allowed time to live. If so, the value is stale and will be > recomputed. > > (cache := NeoTTLCache new) > timeToLive: 10 minutes; > factory: [ :key | ZnEasy get: key ]; > maximumWeight: 32*1024; > computeWeight: #contentLength. > > cache at: âhttp://zn.stfx.eu/zn/numbers.txt'. > > ==> a ZnResponse(200 OK text/plain;charset=utf-8 71B) > > cache > > ==> a NeoTTLCache(#1 71/32768 #contentLength [ :key | ZnEasy get: key ] 0% > 0:00:10:00) > > Would be a simple HTTP cache, keeping resolved URLs in memory for 10 > minutes maximum before refreshing them. It uses #contentLength on > ZnResponse to compute the weight. You can see from the print string that > there is now 1 entry, while the weight is 17 bytes out of 32768. > > > These are the main points, please have a look at the code. Feedback is > welcome. > > Regards, > > Sven > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Roberto Minelli

On Dec 10, 2013, at 5:09 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > A threat? You're completely miss-understanding me, I was kidding ;) > it just that it gave me some time to answer you. > As long as it's your images, you're free man, implement whatever you like. > Weren't we speaking of incorporating some messages in trunk development? > Then you have to deal with other's opinion. Mine does not count that much. > At the end, anyway, Steph and Marcus decide. > > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > > On Dec 10, 2013, at 4:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Do I really need to respond to this? > > No. > > > Well you're lucky, my child not yet awoke: > > Is this a threat? :lol: > > > 1) size is often implemented O(1) above is O(n) > > 2) typing size is very short compared to open code you provided > > 3) size has many senders which makes it worth > > 4) size is part of ANSI > > Which of these points apply to (someCollection collectAsSet: #asUppercase) vs (someCollection collect: #asUppercase as: Set). > > Anyway, this is an endless discussion. You have your point. I have mine. I have my own #collectAsSet: and I am fine with that and I will never use #collect:as: > > > But you could find better example of some more questionable methods in Squeak/Pharo. > > > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > > So if "self do: [:each | tally := tally + 1]" computes the size of a collection, why do we need the #size selector? > > > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > So if collect:as: does the job why the hell add yet another selector? > > > > > > > > >

Dec. 10, 2013

MessageNotUnderstood: SmallInteger>>isEmpty

by Dario Trussardi

Ciao, i work with a new Pharo 2.0 20628 image. I do first : A) Gofer new url: 'http://smalltalkhub.com/mc/DiegoLont/QCMagritte/main'; package: 'ConfigurationOfQCMagritte'; load. and: B) ((Smalltalk at: #ConfigurationOfQCMagritte) project version: '0.2') load: #( 'Demo' ). After some works the system when Fetching 1.0.2.1 of ConfigurationOfTwitteBootstrap erase the error: SmallInteger(Object)>>doesNotUnderstand: #isEmpty MetacelloMCVersionSpec>>resolveToLoadableSpecs:map: MetacelloMCVersionSpec>>resolveToLoadableSpecs: MetacelloMCVersionSpec>>expandToLoadableSpecNames: in Block: [:cache | ... MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: in Block: [:dict | ... MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [^ aBlock value: dict] BlockClosure>>on:do: MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:at:doing: MetacelloMCVersionSpec>>expandToLoadableSpecNames: MetacelloMCVersion>>expandToLoadableSpecNames: MetacelloMCProjectSpec>>relativeCurrentVersion in Block: [vrsn expandToLoadableSpecNames: (loadList := self...etc... BlockClosure>>on:do: MetacelloMCProjectSpec>>relativeCurrentVersion MetacelloProjectReferenceSpec>>relativeCurrentVersion MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: in Block: [:prj | ... MetacelloProjectReferenceSpec>>projectDo:packageDo:groupDo: MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: in Block: [:name | | pkgSpec | (pkgSpec := map... Array(SequenceableCollection)>>do: MetacelloMCVersionSpec>>specsNamed:projectDo:packageDo:groupDo: MetacelloMCVersionSpec>>isPartiallyCurrentAgainst: MetacelloMCVersionSpec>>isPartiallyCurrent MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: [:version | ... Array(SequenceableCollection)>>do: MetacelloMCProject(MetacelloProject)>>currentVersionAgainst: in Block: [:cache | ... MetacelloPharoPlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: in Block: [:dict | ... MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [^ aBlock value: dict] BlockClosure>>on:do: MetacelloPharoPlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: Any idea? Thanks, Dario

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Nicolas Cellier

A threat? You're completely miss-understanding me, it just that it gave me some time to answer you. As long as it's your images, you're free man, implement whatever you like. Weren't we speaking of incorporating some messages in trunk development? Then you have to deal with other's opinion. Mine does not count that much. At the end, anyway, Steph and Marcus decide. 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > > On Dec 10, 2013, at 4:19 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Do I really need to respond to this? > > No. > > > Well you're lucky, my child not yet awoke: > > Is this a threat? :lol: > > > 1) size is often implemented O(1) above is O(n) > > 2) typing size is very short compared to open code you provided > > 3) size has many senders which makes it worth > > 4) size is part of ANSI > > Which of these points apply to (someCollection collectAsSet: > #asUppercase) vs (someCollection collect: #asUppercase as: Set). > > Anyway, this is an endless discussion. You have your point. I have mine. I > have my own #collectAsSet: and I am fine with that and I will never use > #collect:as: > > > But you could find better example of some more questionable methods in > Squeak/Pharo. > > > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > > So if "self do: [:each | tally := tally + 1]" computes the size of a > collection, why do we need the #size selector? > > > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > So if collect:as: does the job why the hell add yet another selector? > > > > > > > > >

Dec. 10, 2013

Re: [Pharo-dev] Voronoi diagram

by NISHIHARA Satoshi

Voronoi-2d-Diagram, you can install from Configuration browser of 2.0. ;-) 2013/12/8 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Check this out > > http://www.smalltalkhub.com/#!/~goonsh/Voronoi-2d-Diagram > http://www.squeaksource.com/VoronoiDiagram.html > > There is also an old package implementing Voronoi diagrams also, I can have > a look if you those are not enough for your needs. > Cheers > > HernÃ¡n > > El 07/12/2013 13:59, Natalia Tymchuk escribiÃ³: > >> Hello. >> I started implementing visualization of Voronoi diagrams and I need to >> do a lot of operations on the lines and polygons. I have some questions: >> Is it implemented somewhere? >> Did somebody do something with the Voronoi diagrams? >> >> Best regards, >> Natalia >> >> > > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

Dec. 10, 2013

[ANN] Neo-Caching

by Sven Van Caekenberghe

Hi, Caching is an important technique to trade time (speed of execution) for space (memory consumption) in computation. Used correctly, caching can significantly improve an applicationâs performance. Given the key/value nature of a cache, a Dictionary is often the first data structure used for implementing it. This is however not a good idea since a simple Dictionary is unbounded by definition and can/will lead to explosive cache growth. Quick and dirty hacks to turn a Dictionary into a least-recently-used (LRU) and/or time-to-live (TTL) based limited cache are often incorrect and inefficient. The LRUCache implementation currently in Pharo is too simple and not efficient, being O(n) on its main operation. Pharo deserves and needs a good LRU/TTL cache implementation that can/should be used uniformly in various places of the system and in code built on top of it. That is why I implemented a proposal. Neo-Caching is an implementation of both a good LRU cache as well as a TTL extension of it. The caches are easy to use, yet have a number of interesting features. The implementation is properly O(1) on its main operations and is 2 to 3 times faster than LRUCache. The package also contains a double linked list implementation. The code comes with a full set of unit tests. There are class and method comments and the code is easy to read. The code (which has no dependencies) can be found here http://mc.stfx.eu/Neo http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/Neo/main There is only one package to load. The code has been written in Pharo 3.0 but it should run on older versions as well. Code Letâs create a 16K ordered collection of keys that have some repetitions in them with a reasonable distribution: data := Array streamContents: [ :out | 1 to: 4096 do: [ :each | each primeFactorsOn: out. out nextPut: each ] ]. data := data collect: [ :each | each asWords ]. By using #asWords the keys have better hash properties. Now, we put all this in a cache: cache := NeoLRUCache new. cache maximumWeight: 512. cache factory: [ :key | key ]. data do: [ :each | cache at: each ]. cache. ==> a NeoLRUCache(#512 512/512 [ 1 ] [ :key | key ] 72%) We had a 72% hit ratio, which is good. The cache is of course full, 512/512 with 512 entries (not necessarily the same thing, see further). We can now benchmark this: [ data do: [ :each | cache at: each ] ] bench. ==> '35.8 per second.â And compare it to LRUCache: cache := LRUCache size: 512 factory: [ :key | key ]. [ data do: [ :each | cache at: each ] ] bench. ==> '12.6 per second.â Features Instead of just counting the number of entries, which is the default behaviour, the concept of weight is used to determine when a cache is full. For each cached value, a block or selector is used to compute its weight. When adding a new entry causes the weight to exceed a maximum, eviction of the least recently used item(s) takes place, until the weight is again below the maximum. cache computeWeight: #sizeInMemory; maximumWeight: 16*1024. Will keep the cache below 16Kb in real memory usage. This can be very useful when caching various sized images or MC packages, for example. By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. cache useSemaphore. NeoTTLCache extends NeoLRUCache by maintaining a timestamp for each cached value. Upon cache hit, there is a check to see if this timestamp is not older than the allowed time to live. If so, the value is stale and will be recomputed. (cache := NeoTTLCache new) timeToLive: 10 minutes; factory: [ :key | ZnEasy get: key ]; maximumWeight: 32*1024; computeWeight: #contentLength. cache at: âhttp://zn.stfx.eu/zn/numbers.txt'. ==> a ZnResponse(200 OK text/plain;charset=utf-8 71B) cache ==> a NeoTTLCache(#1 71/32768 #contentLength [ :key | ZnEasy get: key ] 0% 0:00:10:00) Would be a simple HTTP cache, keeping resolved URLs in memory for 10 minutes maximum before refreshing them. It uses #contentLength on ZnResponse to compute the weight. You can see from the print string that there is now 1 entry, while the weight is 17 bytes out of 32768. These are the main points, please have a look at the code. Feedback is welcome. Regards, Sven

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Roberto Minelli

On Dec 10, 2013, at 4:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Do I really need to respond to this? No. > Well you're lucky, my child not yet awoke: Is this a threat? :lol: > 1) size is often implemented O(1) above is O(n) > 2) typing size is very short compared to open code you provided > 3) size has many senders which makes it worth > 4) size is part of ANSI > Which of these points apply to (someCollection collectAsSet: #asUppercase) vs (someCollection collect: #asUppercase as: Set). Anyway, this is an endless discussion. You have your point. I have mine. I have my own #collectAsSet: and I am fine with that and I will never use #collect:as: > But you could find better example of some more questionable methods in Squeak/Pharo. > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > So if "self do: [:each | tally := tally + 1]" computes the size of a collection, why do we need the #size selector? > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > So if collect:as: does the job why the hell add yet another selector? > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Nicolas Cellier

Do I really need to respond to this? Well you're lucky, my child not yet awoke: 1) size is often implemented O(1) above is O(n) 2) typing size is very short compared to open code you provided 3) size has many senders which makes it worth 4) size is part of ANSI Which of these points apply to (someCollection collectAsSet: #asUppercase) vs (someCollection collect: #asUppercase as: Set). But you could find better example of some more questionable methods in Squeak/Pharo. 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > So if "self do: [:each | tally := tally + 1]" computes the size of a > collection, why do we need the #size selector? > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > So if collect:as: does the job why the hell add yet another selector? > > >

Dec. 10, 2013