December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

Hi Stef, I am thinking about the -Point suggestion. Why this? Why not to use Cmd+f,cmd+c (find class), or shift+enter (spotlight)? Thanks for the discussion. Jura El 08-12-2013, a las 12:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > > On Dec 8, 2013, at 4:33 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi All, >> >> You may have noticed that Nautilus now has a search bar next to the list of packages. I personally find this extremely useful. This is the work of Juraj and he is interested in hearing your feedback. >> >> The textfield accepts regular expression. It means that entering âRoassalâ will display all the packages having the word âRoassalâ in it (e.g., RoassalExtra, ConfigurationOfRoassal). If I enter â^Roassalâ, it displays all the packages that begin with âRoassalâ. (e.g., RoassalExtra). >> >> Any idea how to make this feature more apparent? Anything else you want to see with the searching in the browser? > > I would love to have the search bar searching also based on class name > Maybe -Point > could select the package that contains the class Point > -Point* > could select the package that contains the classes *Point* >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

Dec. 10, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

This is fixed: https://pharo.fogbugz.com/f/cases/12383/Loose-package-selection-on-using-pa… El 08-12-2013, a las 14:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > Another pponit about the search > > it would be good to have the following behavior > I type TOOLS > > I see all the packages with TOOLS > > I select one > > then I removed TOOLS from the search bar > > -> the selected package stays selected > > Stef >

Dec. 10, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Damien Cassou

On Dec 5, 2013 10:50 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > > There are several different approaches in different places: > > - FileStream reads strings by default. #binary and #ascii switch between formats. File streams use an internal buffer which is either a String (default) or a ByteArray. Itâs even possible to switch between binary and ascii midstream without losing information (if done right) because it only affects the buffer. > - ReadStream and WriteStream cannot change their format. Their behavior is determined by the underlying collection. Forcing conversions (e.g. by #asString) can lead to loss of information > - RWBinaryOrTextStream (and other subclasses of ReadWriteStream) also support the #binary #ascii method of switching format. Default is #ascii > - SocketStream uses the same #binary / #ascii mechanism. Default is #ascii > - ZnLimitedReadStream uses the same #binary / #ascii mechanism. Default is #binary (implicit); depends on the underlying stream > > I think the pattern to follow is clear: ReadStream and WriteStream should allow switching format with #ascii and #binary, default should be #ascii. However, I suspect thereâs a reason that these classes donât support switching, namely that switching makes the implementation more complicated and also slower because more checks need to be made. > > The easiest solution I see would be to implement something like this: > > ReadStream>>next > ^ self isBinary > ifTrue: [ self basicNext asCharacter ] > ifFalse: [ self basicNext ] > > However, #next et al. are implemented in a plugin and the primitive method looks like this: > > ReadStream>>next > <primitive: 65> > position >= readLimit > ifTrue: [^nil] > ifFalse: [^collection at: (position := position + 1)] > > This means the collection instance variable has to hold either a binary or a string collection. > > Iâve found a solution which would work and Iâve whipped up a working way (thereâs space for improvementâ¦): > > ReadStream>>binary > collection isString ifFalse: [ ^ self ]. > collection := (ByteArray new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > ReadStrem>>ascii > collection isString ifTrue: [ ^ self ]. > collection := (String new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > @Damien > opposed to what I wrote earlier, #asString does *not* destroy non-printable characters. Instead, every byte (from 0 to 255) is encoded as a character and thus the string can be converted back to a ByteArray *without* loss of information. Sorry about that. Thank you very much for your analysis. I'm a bit reluctant to change ReadStream now, but I could be ok with enough unit tests. Another potential solution: What about adding a #binaryReadStream method to the memory file system as a workaround before the introduction of xstreams ? > With this change in place the 12259 would become obsolete. > > Please let me know what you think. This is a pretty big change that might have a lot of consequences in the image. > > Cheers, > Max > > On 04.12.2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > >> Let me see what I can come up with. >> >> >> On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content >>> >>> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: >>>> >>>> Damien, Marcus >>>> >>>> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. >>>> >>>> Cheers, >>>> Max >> >> >

Dec. 10, 2013

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

by Esteban A. Maringolo

Thank you Sven! As I always say, I'm a big fan of all your contributions. They certainly close the gap we have with the mainstream solutions. Can I know what do you use it for? 2013/12/10 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 10 Dec 2013, at 17:48, phil(a)highoctane.be wrote: >> 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 ;-) Because we all know Smalltalk is the red pill... ;-) Esteban A. Maringolo

Dec. 10, 2013

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