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

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

by George Herolyants

2009/10/29 Dennis Schetinin <chaetal(a)gmail.com>: > That's right, my mistake. Anyway IMHO using explicit message sends is > preferable, no? I think not in this case. It looks more clean and declaratively when you use symbols here.

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

Object does not "contain" any abstract method. Alexandre On 29 Oct 2009, at 05:31, Nicolas Cellier wrote: > 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 29, 2009

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