September 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Class>>asRingDescription

by Fernando Olivero

Veronica, i've started to adopt Ring in Gaucho. Very nice work, excellent tests also! A question, why does the following is true? Collection asRingDefinition methods isEmpty = true If you look at the following method, they should be added here right?, on the ring definition creation. Class>>asRingDefinition | ring | ring := (RGFactory current createClassNamed: self name) category: self category; superclassName: self superclass name; traitCompositionSource: self traitCompositionString; addInstanceVariables: self instVarNames; addClassVariables: self classVarNames; addPoolDictionaries: self poolDictionaryNames; comment: self organization classComment; stamp: self organization commentStamp; definitionSource: self definition; withMetaclass. ring theMetaClass traitCompositionSource: self theMetaClass traitCompositionString; definitionSource: self theMetaClass definition; addInstanceVariables: self theMetaClass instVarNames. ^ring I'm using the latest Pharo1.4 from Jenkins. Fernando

Sept. 15, 2011

Re: [Pharo-project] What is an abstract method?

by Alexandre Bergel

I proposed a slice for this. Alexandre On 15 Sep 2011, at 08:55, Igor Stasenko wrote: > On 14 September 2011 19:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> >>> wrote: >>>> Hi! >>>> >>>> Apparently, the following method is abstract: >>>> >>>> ArrayedCollection>>add: newObject >>>> self shouldNotImplement >>>> >>>> If I evaluate: >>>> (ArrayedCollection>>#add:) isAbstract => true >>>> >>>> This is not quite right. A method that is cancelled is not abstract. >>>> >>>> I propose to change >>>> CompiledMethod>>abstractMarkers >>>> ^ #(subclassResponsibility shouldNotImplement) >>>> >>>> into >>>> CompiledMethod>>abstractMarker >>>> ^ #shouldNotImplement >>>> >>>> Does it make sense? >>>> >>> >>> yes >> >> >> Why? It doesn't for me. A method defined as ^ self subclassResponsibility >> is "abstract" from my point of view. >> >> > > To make it clear, i thinking that: > #subclassResponsibility > is abstract > > #shouldNotImplement > > is concrete (and actually completely opposite to 'abstract', because > it prohibits subclasses from overriding this method, > while #subclassResponsibility doest opposite - it tells that > subclasses _should_ override this method, unless they are abstract. > > -- > Best regards, > Igor Stasenko. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 15, 2011

Re: [Pharo-project] What is an abstract method?

by Igor Stasenko

On 14 September 2011 19:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Sep 14, 2011 at 1:20 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 13 September 2011 19:52, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > Hi! >> > >> > Apparently, the following method is abstract: >> > >> > ArrayedCollection>>add: newObject >> > Â Â Â Â self shouldNotImplement >> > >> > If I evaluate: >> > (ArrayedCollection>>#add:) isAbstract => true >> > >> > This is not quite right. A method that is cancelled is not abstract. >> > >> > I propose to change >> > CompiledMethod>>abstractMarkers >> > Â Â Â Â ^ #(subclassResponsibility shouldNotImplement) >> > >> > into >> > CompiledMethod>>abstractMarker >> > Â Â Â Â ^ #shouldNotImplement >> > >> > Does it make sense? >> > >> >> yes > > > Why? It doesn't for me. A method defined as ^ self subclassResponsibility > is "abstract" from my point of view. > > To make it clear, i thinking that: #subclassResponsibility is abstract #shouldNotImplement is concrete (and actually completely opposite to 'abstract', because it prohibits subclasses from overriding this method, while #subclassResponsibility doest opposite - it tells that subclasses _should_ override this method, unless they are abstract. -- Best regards, Igor Stasenko.

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Alexandre Bergel

No, decrease. Scheme forces you to have short functions, which usually begin with a condition or a case statement. Alexandre On 15 Sep 2011, at 08:49, Damien Cassou wrote: > On Thu, Sep 15, 2011 at 1:36 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Removing it from the language, will probably significantly reduce the average method size. > > you mean "increase the average method size", right? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Damien Cassou

On Thu, Sep 15, 2011 at 1:36 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Removing it from the language, will probably significantly reduce the average method size. you mean "increase the average method size", right? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 15, 2011

Re: [Pharo-project] [update 1.4] #14141

by Marcus Denker

On Sep 15, 2011, at 1:40 PM, Gary Chambers wrote: > Somewhat... > The change in PluggableTextMorph>>initialize to a proportional layout > affects the minExtent calculation, hence splitters for text will not allow shrinkage any more... > Maybe we should just undo all the changes... -- Marcus Denker -- http://marcusdenker.de

Sept. 15, 2011

Re: [Pharo-project] [update 1.4] #14141

by Gary Chambers

Somewhat... The change in PluggableTextMorph>>initialize to a proportional layout affects the minExtent calculation, hence splitters for text will not allow shrinkage any more... Regards, Gary ----- Original Message ----- From: "Marcus Denker" <marcus.denker(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 15, 2011 12:22 PM Subject: Re: [Pharo-project] [update 1.4] #14141 On Sep 15, 2011, at 1:01 PM, Marcus Denker wrote: > > On Sep 15, 2011, at 12:53 PM, Marcus Denker wrote: > >> >> On Sep 15, 2011, at 12:24 PM, Gary Chambers wrote: >> >>> Unfortunately major breakage when I update. >>> PluggableTextMorph initialize seems to indicate that AdorementMorph is >>> nil >>> Hence MNU for UndefinedObject does not uunderstand #on: >>> (shouldn't it be named AdornmentMorph anyway...) >>> >> Aargh.. the class was in a system category that is not a Package, so it >> did not get saved... >> >> I will fix it by adding a changeset to the update stream... > > > 14142 provides the missing class (we can rename it later). Now Morphic is > dirty, which will > be fixed in 14143. > Ok, 14243 is done and it seems all to be fixed (I hope) -- Marcus Denker -- http://marcusdenker.de

Sept. 15, 2011

Re: [Pharo-project] Explicit return in []

by Alexandre Bergel

Scheme does not have a return statement, so, no, ^ is not absolutely necessary. Removing it from the language, will probably significantly reduce the average method size. Alexandre On 15 Sep 2011, at 03:01, StÃ©phane Ducasse wrote: > Hi > > this is early (at least to me) and I was asking myself a probably stupid question. But I would like to get your smart answers :) > > does a smalltalk like language really need explicit return in []? > > Q1 When are they absolutely required? > Q2 What replacing mechanisms would be needed? > Q3 What would we gain from an implementation stand point? > It seems that in resilience lars removed them and more. > > Stef > > for Q1 I see > > foo > x isZero ifTrue: [^ 33]. > self continue -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 15, 2011

Re: [Pharo-project] [update 1.4] #14141

by Marcus Denker

On Sep 15, 2011, at 1:01 PM, Marcus Denker wrote: > > On Sep 15, 2011, at 12:53 PM, Marcus Denker wrote: > >> >> On Sep 15, 2011, at 12:24 PM, Gary Chambers wrote: >> >>> Unfortunately major breakage when I update. >>> PluggableTextMorph initialize seems to indicate that AdorementMorph is nil >>> Hence MNU for UndefinedObject does not uunderstand #on: >>> (shouldn't it be named AdornmentMorph anyway...) >>> >> Aargh.. the class was in a system category that is not a Package, so it did not get saved... >> >> I will fix it by adding a changeset to the update stream... > > > 14142 provides the missing class (we can rename it later). Now Morphic is dirty, which will > be fixed in 14143. > Ok, 14243 is done and it seems all to be fixed (I hope) -- Marcus Denker -- http://marcusdenker.de

Sept. 15, 2011

Re: [Pharo-project] [update 1.4] #14141

by Marcus Denker

On Sep 15, 2011, at 12:53 PM, Marcus Denker wrote: > > On Sep 15, 2011, at 12:24 PM, Gary Chambers wrote: > >> Unfortunately major breakage when I update. >> PluggableTextMorph initialize seems to indicate that AdorementMorph is nil >> Hence MNU for UndefinedObject does not uunderstand #on: >> (shouldn't it be named AdornmentMorph anyway...) >> > Aargh.. the class was in a system category that is not a Package, so it did not get saved... > > I will fix it by adding a changeset to the update stream... 14142 provides the missing class (we can rename it later). Now Morphic is dirty, which will be fixed in 14143. -- Marcus Denker -- http://marcusdenker.de

Sept. 15, 2011