- Pharo-dev - lists.pharo.org

Re: [Pharo-project] some patterns I would like to **kill**

by Schwab,Wilhelm K

Stef, #respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak. Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill** Hi I was reading Pluggable and friends I identified some patterns. The respondsTo plague Examples: color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState] (self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean]. (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. Using submorphs to avoid one single inst var makes code quite ugly to read: labelMorph "Answer the actual label morph." self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2010

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

by Hernan Wilkinson

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 <http://www.10pines.com/>*

Oct. 22, 2010

Re: [Pharo-project] About Object and Model

by Hernan Wilkinson

I like the idea... a lot of methods should be removed from Object and the idea of using traits for that is interesting. I support the motion! :-) On Thu, Oct 21, 2010 at 5:06 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > I'm reading Object and I have the impression that some methods are in > Object while there should be on Model. > > when: anEventSelector > send: aMessageSelector > to: anObject > exclusive: aValueHolder > > okToClose.... > taskbarIcon > taskbarLabel > > May be some of these methods should grouped in traits, then applied to > Model. > Then if the user wants something else than Model to play the game he can > simply apply a trait. > > I think that this hierarchical decomposition is often forcing us to stack > methods in the wrong place > I think that the composition is way stronger and much more flexible than > hierarchical ordering. > tell me what you think. I would like to have a nice Object class. > > 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 <http://www.10pines.com/>*

Oct. 22, 2010

Re: [Pharo-project] What is a primitive method?

by Mariano Martinez Peck

2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/10/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > THanks Eliot for the explanation. >> So....The compiler checks and for these kind of special quick methods it >> creates a CompiledMethod that has in its header, a primitive value ? >> > > A number, yes. The number answered by CompiledMethod>primitive. > > Ok...thanks Eliot. > >> So...if I would be able to put a "self halt" (but I cannot do it becaue >> otherwise it won't be quick anymore) in Number>>isNumber, the debugger >> would never stop there? >> > > > > The way to put a break-point around a primitive is to rewrite it as a > wrapper method around the actual primitive, e.g. > > SmallInteger>>+ aNumber > <primitive: 1> > ^super + aNumber > > => SmallInteger>>primitivePlus: aNumber > <primitive: 1> > ^super + aNumber > > SmallInteger>>+ aNumber > FirstTime == nil ifTrue: [FirstTime := false. self halt]. > ^self primitivePlus: aNumber > Ahhh that's true :) I forget about that...once I did exactly this for FFI calls. > > you absolutely need the FirstTime approach (where FirstTie is some global > you define for the purpose) to cause the halt to fire once if you're trying > to break-point a method that is in wide-spread use. Otherwise the system > will die a recursive death ;) > > I guess we can also use self haltOnce ? which implementations does exactly that you suggested :) Thanks! mariano > best > Eliot > > >> >> Interesting! Thanks Oscar for the question, it make me learn. >> >> Mariano >> >> 2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> Hi Oscar, >>> >>> see Object class>>whatIsAPrimitive. Further, most of the primitive >>> methods you're seeing are methods that answer self, nil, true false or an >>> inst var. See the difference between these: >>> >>> SystemNavigation new browseAllSelect: [:m| m isQuick] >>> >>> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m >>> isQuick not]] >>> >>> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m >>> isQuick not and: [(#(117 120) includes: m primitive) not]]] >>> >>> HTH >>> Eliot >>> >>> >>> On Thu, Oct 21, 2010 at 9:18 AM, Oscar E A Callau < >>> oalvarez(a)dcc.uchile.cl> wrote: >>> >>>> >>>> Hi all, >>>> >>>> I have a (basic) question: >>>> >>>> What is a primitive method? >>>> >>>> In pharo 1.1.1, we have CompiledMethod>>primitive that basically return: >>>> >>>> 0 if the method is not a primitive method >>>> >0 otherwise >>>> >>>> But if you execute this on i.e. Number>>isNumber or Morph>>#model >>>> compiled methods you get that these two are primitive methods. Are they >>>> primitive methods? >>>> >>>> Other (related) question is: When I executed the expression: >>>> >>>> SystemNavigation default allPrimitiveMethods >>>> >>>> , I get a OrderedCollection with 5581 elements. Are all those methods, >>>> primitive methods? >>>> >>>> >>>> Thanks in advance >>>> _______________________________________________ >>>> 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. 22, 2010

[Pharo-project] a useful check

by Eliot Miranda

Hi All, I just stumbled across a bug of mine which is a rare but easy-to-make slip, that of an unused block, e.g. expr ifTrue: [[something that doesn't get done]]. Here's a check for it (I'll check it in as a SysdtemNavigation method and perhaps the RB includes it in its lint tests). There's one method in Squeak trunk that falls foul of this. "Scan for the byte following each block creation being the pop bytecode." SystemNavigation new browseAllSelect: [:m| | is | is := InstructionStream on: m. is scanFor: [:b| b = 143 and: [(m at: is thirdByte * 256 + is fourthByte + is pc + 4) = 135]]]

Oct. 22, 2010

Re: [Pharo-project] What is a primitive method?

by Eliot Miranda

2010/10/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > THanks Eliot for the explanation. > So....The compiler checks and for these kind of special quick methods it > creates a CompiledMethod that has in its header, a primitive value ? > A number, yes. The number answered by CompiledMethod>primitive. > So...if I would be able to put a "self halt" (but I cannot do it becaue > otherwise it won't be quick anymore) in Number>>isNumber, the debugger > would never stop there? > The way to put a break-point around a primitive is to rewrite it as a wrapper method around the actual primitive, e.g. SmallInteger>>+ aNumber <primitive: 1> ^super + aNumber => SmallInteger>>primitivePlus: aNumber <primitive: 1> ^super + aNumber SmallInteger>>+ aNumber FirstTime == nil ifTrue: [FirstTime := false. self halt]. ^self primitivePlus: aNumber you absolutely need the FirstTime approach (where FirstTie is some global you define for the purpose) to cause the halt to fire once if you're trying to break-point a method that is in wide-spread use. Otherwise the system will die a recursive death ;) best Eliot > > Interesting! Thanks Oscar for the question, it make me learn. > > Mariano > > 2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> > > Hi Oscar, >> >> see Object class>>whatIsAPrimitive. Further, most of the primitive >> methods you're seeing are methods that answer self, nil, true false or an >> inst var. See the difference between these: >> >> SystemNavigation new browseAllSelect: [:m| m isQuick] >> >> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m isQuick >> not]] >> >> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m isQuick >> not and: [(#(117 120) includes: m primitive) not]]] >> >> HTH >> Eliot >> >> >> On Thu, Oct 21, 2010 at 9:18 AM, Oscar E A Callau <oalvarez(a)dcc.uchile.cl >> > wrote: >> >>> >>> Hi all, >>> >>> I have a (basic) question: >>> >>> What is a primitive method? >>> >>> In pharo 1.1.1, we have CompiledMethod>>primitive that basically return: >>> >>> 0 if the method is not a primitive method >>> >0 otherwise >>> >>> But if you execute this on i.e. Number>>isNumber or Morph>>#model >>> compiled methods you get that these two are primitive methods. Are they >>> primitive methods? >>> >>> Other (related) question is: When I executed the expression: >>> >>> SystemNavigation default allPrimitiveMethods >>> >>> , I get a OrderedCollection with 5581 elements. Are all those methods, >>> primitive methods? >>> >>> >>> Thanks in advance >>> _______________________________________________ >>> 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. 22, 2010

Re: [Pharo-project] Latest OB, category autocompletion does always a lowercase

by Tobias Pape

Am 2010-10-22 um 14:48 schrieb Lukas Renggli: > Protocols are lowercase by convention,[â¦] Just wanted to add, that this depends on platform and environment. For example, the GemStone protocols are Initial Uppercase by default. Personally, I find extension protocols exactly matching their packages more exact and clear, especially when I combine them with actual "protocol names" as in: *SqueakSource-Notification-Email-accessing where âSqueakSource-Notification-Emailâ is the the package and âaccessingâ the category I actually intend. So Long, -Tobias

Oct. 22, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by GermÃ¡n Arduino

Yes, very interesting. Here at Argentina we have an annual event about free software, this year schedule is: http://www.jornadasregionales.org/jrsl2010v2/schedule/index Could be interesting to present Pharo/Seaside/Pier here, may be next year..... 2010/10/22 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Great ! > > 2010/10/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >> Just to say that recently, there were/are 2 articles about Pharo in GNU >> Linux Magazine (http://www.gnulinuxmag.com/) a french mag. >> One was publish in the n130, about a presentation of Pharo. >> One will be published in one week in the n132, about Gofer. >> Cheers, >> --- >> JannikÂ Laval >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2010

Re: [Pharo-project] Smells looking at collections

by Mariano Martinez Peck

Maybe I am so naive, but what are the advantages of such Inheritance? The only thing I see is that in all your code of Association you can do "self " and access to all the behavior of Magnitude. But it is not that difficult to use composition, and write "self aMagnitude" replace aMagnitude for whatever name you want. Cheers mariano 2010/10/22 Levente Uzonyi <leves(a)elte.hu> > On Fri, 22 Oct 2010, 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? >> > > This was the original hierarchy: Magnitude -> LookupKey -> Association. > Someone removed LookupKey from the chain. This was LookupKey's comment: > > "I represent a key for looking up entries in a data structure. Subclasses > of me, such as Association, typically represent dictionary entries." > > > Levente > > > >> Saludos! >> Nico. >> blog: nicopaez.wordpress.com >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by Serge Stinckwich

Great ! 2010/10/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Just to say that recently, there were/are 2 articles about Pharo in GNU > Linux Magazine (http://www.gnulinuxmag.com/) a french mag. > One was publish in the n130, about a presentation of Pharo. > One will be published in one week in the n132, about Gofer. > Cheers, > --- > JannikÂ Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Oct. 22, 2010