October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

> > There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. > > > That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: > 1) they are stateless > 2) they are different from classes > 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) 1) we build some code to see if we really need state and this is not that obvious and adding state is not trivial 2) well, this is difficult to get the money for the butter and the butter - we are trying. 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. So for now identifying traits and learning is the way. Then we can refactor, redesign Stef

Oct. 23, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

This is in 1.2 :) Stef On Oct 23, 2010, at 4:55 PM, jaayer wrote: > > > > > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- > >> Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. >> >> >> So I looked that the documentation of each of these classes: >> >> >> Association: I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. >> >> >> Magnitude: I'm the abstract class Magnitude that provides common protocol for objects that have >> the ability to be compared along a linear dimension, such as dates or times. >> Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >> Character and LookupKey. >> >> >> >> Based on this, I think this relation is conceptually WRONG. >> If the idea is to reuse code then composition should be used instead of inheritance. >> >> >> >> >> What do you think? >> >> Saludos! >> Nico. >> blog: nicopaez.wordpress.com > > There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

I think you were having a problem with the internet connection. Here it is fine. Try again ;) 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> > Hi all, > i was trying to make Moose loadable into a 1.2 i did try to run the > configuration of Moose and i got an error at the very beginning caused by > the configuration of metacello. Am i missing something or it actually should > work? I did expect to have problem but not with the configuration of > metacello. > > I'm using a > > Pharo image 12203 on a Squeak4.2.5beta1U VM > > To reproduce the error just open the image and execute in a workspace: > > Gofer new > squeaksource: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault > > Attached the log. > > Thanks, > Fabrizio > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

[Pharo-project] [ANN] pre-build Core#12210

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27677/PharoCore-1.2-12210.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Mariano Martinez Peck

2010/10/23 Guillermo Polito <guillermopolito(a)gmail.com> > Why not deprecate/remove the #deprecate: without the useful parameters? :D > > I said that few months ago: http://forum.world.st/what-about-deprecating-deprecated-td2306905.html#a230… :) > 2010/10/23 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> On Sat, Oct 23, 2010 at 1:32 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Ok we can deprecate it. >>> >>> >> ys, but please please please use deprecated: anExplanationString on: date >> in: version >> >> cheers >> >> mariano >> >> >>> On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: >>> >>> > In a 1.1 image I have, the class HttpRequest is using that message... >>> > >>> > On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse < >>> stephane.ducasse(a)free.fr> wrote: >>> > I would like to deprecate the following method since nobody use it. >>> > What do you think? >>> > >>> > Stef >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > >>> > >>> > -- >>> > HernÃ¡n Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: hernan.wilkinson(a)10Pines.com >>> > site: http://www.10Pines.com >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] [update 1.2] #12209

by Alain Plantec

Le 23/10/2010 16:51, Marcus Denker a Ã©crit : > 12209 > ----- > > Issue 2525: SystemWindow out of focus color wrong hey! too fast ! :) I was just testing it and the fixe is not ok. I'm preparing the good one now. Alain

Oct. 23, 2010

Re: [Pharo-project] [update 1.2] #12209

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 4:51 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 12209 > ----- > > Issue 3049: ClassBuilderTest > Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing > Issue 1981: Raising DuplicateError Exception in class builder > Issue 2525: SystemWindow out of focus color wrong > Issue 3143: To mark a test as an expected failure, one has to overwrite > expectedFailures > A test can now be marked as an expected failure by adding an annotation <expectedFailure>. Good step! > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] [update 1.2] #12210

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 5:16 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 12210 > ----- > > Issue 2653: Editor cursor fix > Issue 3015: When a test is restarted in the debugger, #tearDown and > #setUp and not send > This is excellent and I suffer this problem several times. Thanks Hernan!!! > Issue 1853: NetNameResolver localHostAddress returns public or private > address instead of loopback address. > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sat, 23 Oct 2010, jaayer wrote: > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- >Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. > > >So I looked that the documentation of each of these classes: > > >Association:Â I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. > > >Magnitude:Â I'm the abstract class Magnitude that provides common protocol for objects that have >the ability to be compared along a linear dimension, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >Character and LookupKey. > > > >Based on this, I think this relation is conceptually WRONG. >If the idea is to reuse code then composition should be used instead of inheritance. > > > > >What do you think? > >Saludos! >Nico. >blog: nicopaez.wordpress.com There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: 1) they are stateless 2) they are different from classes 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) Levente _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

Re: [Pharo-project] fixed issue 3025

by Marcus Denker

On Oct 23, 2010, at 5:05 PM, Fabrizio Perin wrote: > fixed 3025 > > http://code.google.com/p/pharo/issues/detail?id=3025. > > code in slice SLICE-Issue-3025-removedtest-FabrizioPerin.1.mcz in pharoinbox. > > The Slice seems to be empty -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010