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

Re: [Pharo-project] About (backwards) Compatibility

by Eliot Miranda

On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > H. Hirzel wrote > > As Chris points out, the difference is minimal. > > > > Sean, it looks like you need better examples to show how you perceive > > the benefits of the FileSystem design > > While you ignored the point of my followup post, which is that beauty and > simplicity lead to more than the sum of a few keywords, here are a few > basic > examples... > > Example #1: > file := FileDirectory directoryEntryFor: '/path/to/file'. > FileDirectory extensionFor: file name. > > vs. > > file2 := '/path/to/file' asFileReference. > file2 extension. > > #2: > (FileDirectory on: 'path') entryAt: 'nohup.out'. > vs. > 'path' asFileReference / 'filename' > > "Most operations routed through one massive FD class" vs. "immediate access > to the domain object you want"; not to mention the appreciated absence of > parens. > > No difference?? > > But with String methods for *FileSystem-utilities / aPath ^self asFileReference / aPath you get 'path' / 'filename' and that's *really* nice. Does anyone think that '123' / '45' is good?? This is a compromise: / arg self size = 0 ifTrue: [self error: 'cannot coerce the empty string]. ^('+-01234456789' incudes: self first) ifTrue: [arg adaptToString: self andSend: #/] ifFalse: [self asFileReference / arg] the issue here being whether FileSystem wants '.profile' or '.hg' et al or math wants '.123'. If FileSystem provides path-name checking then the above could include a specific legality check instead of the naive discrimination. Personally I find the prospect of a concise file scripting api much more appealing than lazy numeric conversion. The absence of the former is why so much of my life involves bash scripts. The latter isn't necessary if one starts off with numbers in the first place, and being literals they're as easy, no, easier than denoting numbers using strings (1 + 1 is shorter than '1' + 1). I hope Squeak integrates FileSystem in 4.4 for 4.5. -- best, Eliot

Dec. 22, 2012

[Pharo-project] [update 2.0] #20450

by Marcus Denker

20450 ----- Issue 7162: clean dead code Form/DisplayObject/Quadrangle http://code.google.com/p/pharo/issues/detail?id=7162 Issue 7168: Newlis>>listForSearching has undeclared var getItemAtIndexSelector http://code.google.com/p/pharo/issues/detail?id=7168 Issue 7166: CompiledMethod>>#getSource should be #sourceCode http://code.google.com/p/pharo/issues/detail?id=7166& Issue 7165: CleanUp MethodChangeRecord (part 1) http://code.google.com/p/pharo/issues/detail?id=7165 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.194.diff http://ss3.gemstone.com/ss/Pharo20/NewList-MarcusDenker.14.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1275.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.101.diff http://ss3.gemstone.com/ss/Pharo20/FuelMetalevelTests-MarcusDenker.52.diff http://ss3.gemstone.com/ss/Pharo20/FuelMetalevel-MarcusDenker.62.diff

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by StÃ©phane Ducasse

On Dec 22, 2012, at 2:44 PM, Igor Stasenko wrote: > On 22 December 2012 14:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> What I love is the impact of not having cool invariant. >> Imagine a world where every morph would have a owner, suddenly the logic of morphic >> would be cut by two :) >> > > Well, for some morphs, nil is the only owner which they deserve to have :) lol :) Indeed :) Stef

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Camillo Bruni

On 2012-12-22, at 09:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 22 Dec 2012, Fernando Olivero wrote: > >> Well, the assignment within the and: block says it allâ¦ > > Yeah, blame and flame everyone who doesn't write code the way you do... > But before you do that, tell me what's wrong with that assignment. why do I always have the impression you're at extinction when I read an email from you? I know I can be very annoying as well :D but you should consider a friendlier tone ;)

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Igor Stasenko

On 22 December 2012 14:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What I love is the impact of not having cool invariant. > Imagine a world where every morph would have a owner, suddenly the logic of morphic > would be cut by two :) > Well, for some morphs, nil is the only owner which they deserve to have :) > Stef -- Best regards, Igor Stasenko.

Dec. 22, 2012

Re: [Pharo-project] To Quadrangle or not Quadrangle?

by Igor Stasenko

On 22 December 2012 14:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > you mean bounds, inner bounds, inset bounds, outer boundsâ¦ > > :) > yeah.. morph's bounds is a jungle. we should think how to reduce them, because it makes model unbearable: Morph methodDict keys select: [:each | each endsWith: 'Bounds' ] #(#focusBounds #layoutBounds #fullBounds #adjustLayoutBounds #defaultBounds #worldBounds #flashBounds #submorphBounds #clippingBounds #privateFullBounds #outerBounds #preferredKeyboardBounds #innerBounds) -- Best regards, Igor Stasenko.

Dec. 22, 2012

Re: [Pharo-project] A tantalizing path of dealing with multiple concerns...

by StÃ©phane Ducasse

Igor may be having good design could help with little objects having responsibilities and plugging the right ones :) We should create "The club of gentleman against little kitties killing code" and save the kitties by refactoring the killing code :) Stef > areasRemainingToFill: aRectangle > "Pushed up from BorderedMorph, all cases tested for there are > supported by basic Morph." > "Morphs which achieve translucency by other means than fillStyle will have > to reimplement this" > "Fixed here to test the fillStyle rather than color for translucency. > Since can have a translucent fillStyle while the (calculated) color is not." > self fillStyle isTranslucent > ifTrue: [^ Array with: aRectangle]. > self wantsRoundedCorners > ifTrue: [(self borderWidth > 0 > and: [self borderColor isColor > and: [self borderColor isTranslucent]]) > ifTrue: [^ aRectangle > areasOutside: (self innerBounds intersect: self boundsWithinCorners)] > ifFalse: [^ aRectangle areasOutside: self boundsWithinCorners]] > ifFalse: [(self borderWidth > 0 > and: [self borderColor isColor > and: [self borderColor isTranslucent]]) > ifTrue: [^ aRectangle areasOutside: self innerBounds] > ifFalse: [^ aRectangle areasOutside: self bounds]] > > > ... the whole Morphic code fall victim of rounded corners (and borders > , of course). > > I wonder, is there any way to > a) have multiple concerns > b) at same time, have a clean code > ? > But i suspect that smalltalk is not powerful enough for that. :)

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by StÃ©phane Ducasse

What I love is the impact of not having cool invariant. Imagine a world where every morph would have a owner, suddenly the logic of morphic would be cut by two :) Stef On Dec 22, 2012, at 2:57 AM, Igor Stasenko wrote: > StringMorph>>boundsForBalloon > "Some morphs have bounds that are way too big. This is a contorted > way of making things work okay in PluggableListMorphs, whose list > elements historically have huge widths" > > | ownerOwner | > ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) and: > [ownerOwner isKindOf: PluggableListMorph]) > ifTrue: > [self boundsInWorld intersect: ownerOwner boundsInWorld] > ifFalse: > [super boundsForBalloon] > > -- > Best regards, > Igor Stasenko. >

Dec. 22, 2012

Re: [Pharo-project] To Quadrangle or not Quadrangle?

by StÃ©phane Ducasse

you mean bounds, inner bounds, inset bounds, outer boundsâ¦ :) On Dec 22, 2012, at 2:41 AM, Igor Stasenko wrote: > Class comment reads: > > I represent a particular kind of Rectangle that has a border and inside color. > > - 0 users in image, except strange test case in RPackage, and totally > unrelated to actual class. > > Now, lets count how many "bordered" stuff we have: > - Morph borderStyle > which using BorderStyle > - BorderedMorph, which has borderWidth borderColor (and if you > combine it with color inherited from Morph, > you get exactly what Quadrangle has).. > - Canvas protocol , supports #borderXYZ everywhere... > > > it is funny, how much attention this visual property drawn from developers :) > (not mentioning an amazing amount of efforts making rounded corners > (and of course drawing rounded borders there as well)) > > -- > Best regards, > Igor Stasenko. >

Dec. 22, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Igor Stasenko

On 22 December 2012 13:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 22 Dec 2012, Fernando Olivero wrote: > >> Well, the assignment within the and: block says it allâ¦ > > > Yeah, blame and flame everyone who doesn't write code the way you do... > But before you do that, tell me what's wrong with that assignment. > No need to take it so seriously. I do not know what's wrong with assignment, but taking special action depending on specific class of outer morph smells bad. I'm not saying that i know the right solution to deal with such situation, but apparently it should not be like that. > > Levente > > >> >> Fernando >> >> >> On Sat, Dec 22, 2012 at 2:57 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> StringMorph>>boundsForBalloon >> "Some morphs have bounds that are way too big. This is a >> contorted >> way of making things work okay in PluggableListMorphs, whose list >> elements historically have huge widths" >> >> | ownerOwner | >> ^ ((owner notNil and: [(ownerOwner := owner owner) notNil]) >> and: >> [ownerOwner isKindOf: PluggableListMorph]) >> ifTrue: >> [self boundsInWorld intersect: ownerOwner >> boundsInWorld] >> ifFalse: >> [super boundsForBalloon] >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > -- Best regards, Igor Stasenko.

Dec. 22, 2012