- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PhExample, because well designed tests expand on one another (Sneak Preview)

by Dennis Schetinin

2009/10/29 Adrian Kuhn <akuhn(a)iam.unibe.ch> > Dennis Schetinin <chaetal@...> writes: > > > stack := self given: #shouldBeEmpty. > > I'd suggest this to be: > > > > stack := self given: [self shouldBeEmpty]. > > This way it's easier to follow what happenning, and refactoring can be > applied. > > Refactoring should not be a problem, it treats symbols the same way as > message > sends. For example, when you rename a method, nut just senders but also all > symbols are renamed. > That's right, my mistake. Anyway IMHO using explicit message sends is preferable, no? -- Dennis Schetinin

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Nicolas Cellier

2009/10/28 <csrabak(a)bol.com.br>: > Em 28/10/2009 17:52, Lukas Renggli <renggli(a)gmail.com> escreveu: > >> >> >> What would be your isAbstract be useful for? >> > To know whether it is wise to instantiate a class or not > >> That would be a pure guess Â then. Presumably you will still have to >> look at Â the implementation, at Â the documentation, at its Â users or >> study the coding conventions of the project to know for sure what to >> do with the thing. > > Yes. > > Thinking aloud: if we want to insure a class shall not be instantiated, shouldn't we put an error in #new of that class? That would be the shortest way to freeze you image: Object>>#freezeMyImage ^self subclassResponsibility ...and you could not create any instance of Object and its subclasses anymore (but via a few primitives bypassing this mechanism). Beside, do you want a runtime check at each creation ? We would have to cache the information at least... Nicolas > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Lukas Renggli

> I'm not that against the idea proposed by alex. I am not against it either. > I think that knowing that a class is abstract is important to have and > this is > not because Smalltalk original language was weak that we could not > define now a clear definition. My complaint is more against: - Why is it useful, if the information is a pure guess and depends on what the author thinks is abstract? - Why should it be added to the core, if it is not used by anything it the core? Who would be using it? > I do not like the definition of RB people because I have class that > are not abstract > and that are not referenced because I just did not load the package > that use them. True, but the definition of Alex is no better. He made up an implementation that is useful in one of his contexts, but it certainly isn't applicable everywhere. Also there might be people that consider classes that send #requirement, #explicitRequirement, or #shouldBeImplemented as abstract. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 29, 2009

Re: [Pharo-project] PhExample, because well designed tests expand on one another (Sneak Preview)

by Adrian Kuhn

Dennis Schetinin <chaetal@...> writes: > Â Â Â Â stack := self given: #shouldBeEmpty. > I'd suggest this to be:Â > > Â Â Â Â stack := self given: [self shouldBeEmpty]. > This way it's easier to follow what happenning, and refactoring can be applied. Refactoring should not be a problem, it treats symbols the same way as message sends. For example, when you rename a method, nut just senders but also all symbols are renamed. cheers, AA

Oct. 29, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by Nicolas Cellier

After-thoughts: my opinion is: Martin solution is more pragmatical : it is tailored for getting most improvment with minimal change in system. But formally, I prefer Andres design for it's clarity. - I do not like the idea that #identityHash and #primIdentityHash do behave differently - #scaledIdentityHash does clearly express itself on the contrary But that turns into german discussions ;) Nicolas 2009/10/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Martin >> >> are these changes related to the graphs you sent? >> I will have a look after my hospital check. >> Andres? Nicolas? >> Any feedback? >> Martin I imagine that I can package the changes :) >> >> >> Stef >> > > This has been pretty well explained by Martin and Andres. > The decision you have to make is : > > - choose Martin change, make speed improvment for most senders of > #identityHash, but eventually break a few senders Â and let package > maintainers fix it (example Magma) > - choose Andres change, assure 100% compatibility, let the > responsibility to package maintainers to use new message for improving > speed. > > In both cases, package maintainer might have to maintain different > branch for Squeak and Pharo, but I guess the solution would be adopted > soon in Squeak/trunk. > > I would tend to be conservative, but I recently took the opposite path > with #keys and #selectors in trunk, so I just can't give you my > personal preference, it's 50-50... > Whatever the choice, #identityHash usage is worth a review by package > maintainers anyway. > > Note that this is closely related to > http://bugs.squeak.org/view.php?id=1876 and > http://code.google.com/p/pharo/issues/detail?id=213 > Amazing the issue is still there when workarounds are known for so > long... So please do something! > > Nicolas >

Oct. 29, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by Nicolas Cellier

2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Martin > > are these changes related to the graphs you sent? > I will have a look after my hospital check. > Andres? Nicolas? > Any feedback? > Martin I imagine that I can package the changes :) > > > Stef > This has been pretty well explained by Martin and Andres. The decision you have to make is : - choose Martin change, make speed improvment for most senders of #identityHash, but eventually break a few senders and let package maintainers fix it (example Magma) - choose Andres change, assure 100% compatibility, let the responsibility to package maintainers to use new message for improving speed. In both cases, package maintainer might have to maintain different branch for Squeak and Pharo, but I guess the solution would be adopted soon in Squeak/trunk. I would tend to be conservative, but I recently took the opposite path with #keys and #selectors in trunk, so I just can't give you my personal preference, it's 50-50... Whatever the choice, #identityHash usage is worth a review by package maintainers anyway. Note that this is closely related to http://bugs.squeak.org/view.php?id=1876 and http://code.google.com/p/pharo/issues/detail?id=213 Amazing the issue is still there when workarounds are known for so long... So please do something! Nicolas

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Nicolas Cellier

2009/10/28 Alexandre Bergel <alexandre(a)bergel.eu>: >> What would be your isAbstract be useful for? > > To know whether it is wise to instantiate a class or not > > Alexandre > I often instantiate Object marker := Object new. Nicolas > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Nicolas Cellier

Thank you. Note that this test uses recently controversed (TestCase>>#assert:) with a Block argument. Maybe you should add the #value everywhere... Nicolas 2009/10/28 Adrian Lienhard <adi(a)netstyle.ch>: > Thanks, Nicolas > > We integrated your fix and now it does not fail anymore. Just have to > remove it from expectedFailures. > > Cheers > Adrian > > On Oct 27, 2009, at 17:58 , Nicolas Cellier wrote: > >> 2009/10/27 Adrian Lienhard <adi(a)netstyle.ch>: >>> Pharo-core tests failing >>> ------------------------ >>> - FontTest>>testFallback (assumes different font, to be removed) >>> - FontTest>>testParagraphFallback (assumes different font, to be >>> removed) >>> - FontTest>>testResetAfterEmphasized (assumes different font, to be >>> removed) >>> - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different >>> font, to be removed) >>> - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes >>> different font, to be removed) >>> - TestIndenting>>testSetUp (assumes different font, to be removed) >>> - LocaleTest>>testIsFontAvailable (some Japanese font checking that >>> fails with DejaVu, to be removed) >>> - testFinalizationOfEquals (was on my to do list, but works again: >>> remove expected failure tag) >> >> This remind me discussions with Norbert http://bugs.squeak.org/view.php?id=6347 >> and also http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/13165… >> >> Nicolas >> >>> - testObsoleteClasses: again includes classes from MC and others >>> (have >>> to be checked) >>> >>> MorphExamplesAndDemos >>> --------------------- >>> - undeclared references to DescriptionForPartsBin and ScreeningMorph >>> >>> Cheers, >>> Adrian >>> >>> BTW, Damien, do we know for each package who the maintainer is? Does >>> each package have one? >>> >>> >>> _______________________________________________ >>> 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. 29, 2009

Re: [Pharo-project] Abstract classes

by StÃ©phane Ducasse

Lukas I'm not that against the idea proposed by alex. I think that knowing that a class is abstract is important to have and this is not because Smalltalk original language was weak that we could not define now a clear definition. I do not like the definition of RB people because I have class that are not abstract and that are not referenced because I just did not load the package that use them. Now if magritte needed to know that a class should show up in a UI then may be it should be called differently because an abstract class is clearly a class that we should/cannot instantiate. If you take ***any*** book on OOP this is a basic concept. Stef On Oct 28, 2009, at 8:52 PM, Lukas Renggli wrote: >>> What would be your isAbstract be useful for? >> >> To know whether it is wise to instantiate a class or not > > That would be a pure guess then. Presumably you will still have to > look at the implementation, at the documentation, at its users or > study the coding conventions of the project to know for sure what to > do with the thing. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 29, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Alain Plantec

Hi Jannik and all, Laval Jannik a Ã©crit : > On Oct 29, 2009, at 04:27 , Serge Stinckwich wrote: > >> Are you sure, this is not used anywhere ? >> Sometimes you need to draw a morph with a specific heading. >> ... > Now, do you use, sometimes, this functionality in pharoCore ? or do > you think this behavior should be offer by pharoCore ? > > heading is a number which is only use in the rotation behavior. > > I think it must be provided by eToy, not by Core. > This was brought by etoy but it is not etoy specific. Of course the heading message is present in the Morph class, which is not good but I see it more as a TransformationMorph /MatrixTransformationMorph functionality. As this, for now, I think it is not so bad. And what about the scaling behavior for example ? Cheers Alain > No ? > > Cheers, > Jannik > > >> Best regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Smalltalkers do: [:it | All with: Class, (And love: it)] >> 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 >> > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 29, 2009