- Pharo-users - lists.pharo.org

[update 1.2] #12117

by StÃ©phane Ducasse

12117 ----- Mistake in deprecating removeClassVarNamed:. Stef

Aug. 27, 2010

Package organization: from structural to ...

by StÃ©phane Ducasse

Hi guys I'm starting to work on http://code.google.com/p/pharo/issues/detail?id=2635 which I split into http://code.google.com/p/pharo/issues/detail?id=2875 Now after I will apply Seaside decomposition to have Test "in their package" Tests-ToolBuilder -> ToolBuilder-Test Now in addition I would like to have Kernel the right stuff there Collection-Kernel Containing what is needed for the core I prefer that to Kernel-Collection since people that want to look at collection will fin it grouped in Collection but the kernel means that we know that they will be for the kernel Now for Array we will have Array will be in Collection-Kernel Collection-Kernel-Test Stef

Aug. 27, 2010

Re: [Pharo-users] Robust flatten for collection?

by Simon Denier

Yep flatten calls gather:, and flatCollect: has a different implementation, but all expects a recursive collection, not a flat one. Well we will find a workaround for now. On 27 aoÃ»t 2010, at 15:23, StÃ©phane Ducasse wrote: > yes this is the same as flatCollect: in moose. > > > gather: aBlock > ^ Array streamContents: > [:stream | > self do: [:ea | stream nextPutAll: (aBlock value: ea)]] > > On Aug 27, 2010, at 3:13 PM, Igor Stasenko wrote: > >> There is a #gather: >> which takes a collection of collections and answers a single collection. >> (if i remember correctly). >> >> On 27 August 2010 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> flatCollect: ? >>> >>> Stef >>> >>> On Aug 27, 2010, at 2:06 PM, Simon Denier wrote: >>> >>>> Hi there >>>> >>>> A question to test your sagacity :) >>>> >>>> I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not. >>>> >>>> >>>> that is: >>>> #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6) >>>> >>>> #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6) >>>> >>>> #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6) >>>> >>>> >>>> Any idea about the best implementation for this? >>>> >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> Pharo-users(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Simon

Aug. 27, 2010

Re: [Pharo-users] Robust flatten for collection?

by StÃ©phane Ducasse

yes this is the same as flatCollect: in moose. gather: aBlock ^ Array streamContents: [:stream | self do: [:ea | stream nextPutAll: (aBlock value: ea)]] On Aug 27, 2010, at 3:13 PM, Igor Stasenko wrote: > There is a #gather: > which takes a collection of collections and answers a single collection. > (if i remember correctly). > > On 27 August 2010 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> flatCollect: ? >> >> Stef >> >> On Aug 27, 2010, at 2:06 PM, Simon Denier wrote: >> >>> Hi there >>> >>> A question to test your sagacity :) >>> >>> I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not. >>> >>> >>> that is: >>> #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6) >>> >>> #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6) >>> >>> #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6) >>> >>> >>> Any idea about the best implementation for this? >>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 27, 2010

Re: [Pharo-users] Robust flatten for collection?

by Igor Stasenko

There is a #gather: which takes a collection of collections and answers a single collection. (if i remember correctly). On 27 August 2010 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > flatCollect: ? > > Stef > > On Aug 27, 2010, at 2:06 PM, Simon Denier wrote: > >> Hi there >> >> A question to test your sagacity :) >> >> I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not. >> >> >> that is: >> #((1 2 3) (4 5 6)) flatten Â --> #(1 2 3 4 5 6) >> >> #(1 2 3 4 5 6) flatten Â --> #(1 2 3 4 5 6) >> >> #((1 2 3) 4 5 6) flatten Â --> #(1 2 3 4 5 6) >> >> >> Any idea about the best implementation for this? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

Aug. 27, 2010

Re: [Pharo-users] Robust flatten for collection?

by StÃ©phane Ducasse

no flatCollect does not work. > that is: > #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6) > > #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6) > > #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6) > > > Any idea about the best implementation for this? > > > -- > Simon > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 27, 2010

Re: [Pharo-users] Robust flatten for collection?

by StÃ©phane Ducasse

flatCollect: ? Stef On Aug 27, 2010, at 2:06 PM, Simon Denier wrote: > Hi there > > A question to test your sagacity :) > > I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not. > > > that is: > #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6) > > #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6) > > #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6) > > > Any idea about the best implementation for this? > > > -- > Simon > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 27, 2010

Robust flatten for collection?

by Simon Denier

Hi there A question to test your sagacity :) I'm looking for a method which would flatten a collection, regardless of whether the collection is already flat or not. that is: #((1 2 3) (4 5 6)) flatten --> #(1 2 3 4 5 6) #(1 2 3 4 5 6) flatten --> #(1 2 3 4 5 6) #((1 2 3) 4 5 6) flatten --> #(1 2 3 4 5 6) Any idea about the best implementation for this? -- Simon

Aug. 27, 2010

by StÃ©phane Ducasse

reply to YCH(a)gconsept.com > -------- Original Message -------- > Subject: Recherche des ingÃ©nieurs en dÃ©veloppement Smalltalk > Date: Thu, 26 Aug 2010 16:42:27 +0200 > From: Yohan CHOQUER <YCH(a)gconsept.com> > To: herve.verjus(a)univ-savoie.fr <herve.verjus(a)univ-savoie.fr> > > > > Bonjour Monsieur Verjus, > > Je suis Ã la recherche dâingÃ©nieurs en dÃ©veloppement Smalltalk et Ã la > lecture de diffÃ©rents forums et sites, je me suis aperÃ§u que vous > connaissiez bien ce langage. > > Peut-Ãªtre avez-vous dans votre entourage ou relations > scolaires/professionnelles des personnes pouvant Ãªtre intÃ©ressÃ©es par > cette demande. > > NâhÃ©sitez pas Ã revenir vers moi. > > Restant Ã votre disposition, > > Cordialement. > > * * > > *Yohan Choquer* > > IngÃ©nieur Commercial > *___________________________________________________________* > > GroupeConsept > > Informatique - Bureau d'Etudes > > Assistance Technique - Conseil - IngÃ©nierie - Formation > > ZAC Les Hauts de CouÃ«ron, Rue des forgerons, > > 44220 CouÃ«ron, France Plan d'accÃ¨s > <http://maps.google.fr/maps?f=q&hl=fr&geocode=&q=rue+des+forgerons+44220+cou…> > TÃ©l : +33 (0)2 51 83 03 00 > > Mob : +33 (0)6 03 18 60 82 > > Fax : +33 (0)2 51 83 03 01 > www.gconsept.com <http://www.gconsept.com/> > > *___________________________________________________________* > >

Aug. 27, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Marcin Tustin

I don't think that we have a problem with cohesion at present (as cohesion is not a quantity, I would not say we have more or less, but a more or less problematic situation). Cohesion does not promote uniformity. It promotes simplicity in tracking the dependencies between functions (messages) and mutable state in objects. This is a different kind of simplicity from the simplicity that having a single protocol provides us. On Thu, Aug 26, 2010 at 6:18 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > > > On Thu, Aug 26, 2010 at 2:02 PM, Marcin Tustin <mm3(a)zepler.net> wrote: > >> Uniformity is when we represent our various significands using the same >> data type >> > > well... I don't agree... starting from the fact that there are no data > types in the object paradigm, just objects. > > >> (in smalltalk using objects with the same protocol). For example, this >> allows us to treat all things in our image as objects, which gives us the >> flexibility to do everything in the object protocol to every kind of thing, >> without having to decide that we do only some things to classes, only other >> things to objects, and only other things again to constants (as in Java). >> > > sorry, I don't understand. > > >> >> This change will introduce heterogeneity, which prevents us using the (now >> two) things in the same way. >> > > but, for me, a symbol is not a selector. What is the meaning of asking a > selector for its size? for me makes more sense to ask the selector's name > for its size. > what is the meaning of asking a symbol for the number of arguments? if that > symbol does not represent a selector there is no reason for the symbol to > respond that question. > > >> The reason to do this is if it would be a category error to do symbol >> operations on a selector, as it locks us into a particular view of the way >> the world should work, which is what the designers of java did when they >> posited classes, objects, and constants as being entirely separate. >> > > I dont understand if this is good or bad for you... for me the separation > that java does with object, classes and data types is a mess, it is just not > uniform, I prefer the smalltalk way :-) > > >> This has the "advantage" that you can't accidentally put a constant in an >> array, for example, because they wanted to restrict flexibility, in order to >> protect users from mistakes. >> > > I never made that mistake in Smalltalk and Smalltalk does not prevent me > for that... > > >> >> I don't see a risk of our current approach causing errors, and I don't see >> that it creates unnecessary complexity, so I am confused as to why this >> change is desirable. >> > > ok, we don't have to agree, but just answer yourself this question: the > proposed change is more cohesive or not? and remember that more cohesive > objects means more simplicity and uniformity... if you don't agree that > cohesion implies that, well.... we should be discussing other things first > :-) > > >> >> On Thu, Aug 26, 2010 at 5:52 PM, Hernan Wilkinson < >> hernan.wilkinson(a)10pines.com> wrote: >> >>> an optimisation? for me this change looks for exactly what you plea, >>> simplicity and uniformity... at the end this change makes symbol and >>> selector more cohesive, and we all know that the more cohesive an object is >>> the more simply and uniform it is, because it represents just one thing, no >>> like symbols now that they can be symbols or selectors (therefore they are >>> not as cohesive as having two different abstractions) and we, human, have to >>> decide what they are instead of letting the objects decide... >>> >>> >>> On Thu, Aug 26, 2010 at 8:43 AM, Marcin Tustin <mm3(a)zepler.net> wrote: >>> >>>> Can I make a last plea for the simplicity and uniformity of the current >>>> model? I suspect that this change is a premature optimisation that will lose >>>> us flexibility, for no apparent benefit. >>>> >>>> [snip] >>>> >>>

Aug. 26, 2010