June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Do we have better collections design library?

by Stephane Ducasse

;) this is nice to write papers just to remember and document our experiments. On Sun, Jun 4, 2017 at 10:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-06-04 19:32 GMT+02:00 webwarrior <reg(a)webwarrior.ws>: > >> I think design deficiencies of Pharo collections can be addressed with >> traits. >> > > There was some work around it: https://hal.inria.fr/ > inria-00511902/file/main.pdf. > (funny that it it was named Bloc ) >

June 4, 2017

Re: [Pharo-dev] Do we have better collections design library?

by Denis Kudriashov

2017-06-04 19:32 GMT+02:00 webwarrior <reg(a)webwarrior.ws>: > I think design deficiencies of Pharo collections can be addressed with > traits. > There was some work around it: https://hal.inria.fr/inria-00511902/file/main.pdf. (funny that it it was named Bloc )

June 4, 2017

Re: [Pharo-dev] Do we have better collections design library?

by webwarrior

Denis Kudriashov wrote > 2017-06-04 19:32 GMT+02:00 webwarrior < > reg@ > >: > >> I think design deficiencies of Pharo collections can be addressed with >> traits. >> > > There was some work around it: > https://hal.inria.fr/inria-00511902/file/main.pdf. > (funny that it it was named Bloc ) Why has it been abandoned? -- View this message in context: http://forum.world.st/Do-we-have-better-collections-design-library-tp494893… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Cyril Ferlicot D.

Le 04/06/2017 Ã 21:26, Cyril Ferlicot D. a Ã©crit : > For this problem I would like to see all the smalltalks using SUnit > change this behaviour. I really do not want to break compatibility and I > think this change is important for the usability of SUnit. I don't have > much contact with other smalltalk communities but I would be happy if we > can seek a consensus. > > If you have an idea of the best way to communicate with all the > communities on this subject I would like to hear it. > Maybe we can talk about it at ESUG? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Cyril Ferlicot D.

Le 04/06/2017 Ã 18:20, Eliot Miranda a Ã©crit : > Hi Cyril, > Hi Eliot, > > As Minty points out, this unintuitive behaviour exists fur a reason and there is a work around. > > SUnit is a community wide package existing in all the dialects of Smalltalk I'm aware of. If you change the semantics then every time a test suite is exchanged it will need to be rewritten, and by someone who understands the divergence, otherwise the test suite won't work as intended. > > Is is worth diverging from a community wide standard when there is a rationale for the design and there is a work around? > When I discovered this behaviour I was really surprised by it. (apparently I am not the only one) And if I did not checked the number of tests I think I would have never know that my tests are not executed in all the hierarchy. Also, abstract tests classes is something I use a lot since I am in the community. Now I know that I'll need to change many of the projects I contributed to in order to activate all the tests I wanted. And I think a lot of newcomers will not know this behaviour because it is counter intuitive. IMO, it goes against the principle of inheritance. > Is it puss bow to seek a wider consensus and see what e.g. the VisualWorks, VisualAge and GemStone communities think? > For this problem I would like to see all the smalltalks using SUnit change this behaviour. I really do not want to break compatibility and I think this change is important for the usability of SUnit. I don't have much contact with other smalltalk communities but I would be happy if we can seek a consensus. If you have an idea of the best way to communicate with all the communities on this subject I would like to hear it. > Is it possible that better documenting the work around would be better? > Personally I think that even with a good documentation, this is not the kind of thing everyone will remember. But this is only my opinion. :) > > _,,,^..^,,,_ (phone) > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

June 4, 2017

Re: [Pharo-dev] Do we have better collections design library?

by webwarrior

Denis Kudriashov wrote > Hi. > > I just found that there is no WeakIdentityValueDictionary. But we have > WeakValueDictionary, WeakKeyDictionary, WeakIdentityKeyDictionary. > > And to implement missing class I need to copy overrides from > IdentityDictionary. And weak key dictionaries are implemented same way by > duplicating code. > > And generally identity collections are not much different from equal > collections but they still duplicate a lot of code with little difference: > #hash or #identityHash, #= or #==. > > So I am wondering do we have alternative implementation with proper > design? > There are wishes to replace streams by XSteams. What about collections? > > Best regards, > Denis I think design deficiencies of Pharo collections can be addressed with traits. Now Pharo has classes that mix: - public interface of some type of collection - implementation of numerous operations on collections (e.g. #collect:) - implementation of collection's interface (e.g. #do:) Also different interfaces (iteration, mutation) are mixed together as well. For example, Collection could be replaced by TIterable (iteration and other methods from Collection that don't require mutation) and TCollection (TIterable + adding and removing). TIterable then can also be used for things like iterators/views/slices. Similarly, SequenceableCollection -> TSequenceable (uses TIterable) and TSequenceableCollection (uses TCollection + TSequenceable). Dictionary -> TMap (uses TIterable) and TDictionary (uses TCollection + TMap). Perhaps also separate traits for immutable collections, that use iteration traits and know how to make modified versions of themselves and how to construct instance from stream. For hashed collections, separate traits could be made for equality- and identity-based collections. Perhaps they can even be made right now, without reorganizing whole collections hierarchy - just by moving corresponding methods into them. -- View this message in context: http://forum.world.st/Do-we-have-better-collections-design-library-tp494893… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Nicolas Cellier

2017-06-04 15:32 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-06-04 15:03 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > >> If most people agree that we should inherit the tests by default I think >> this is a change that should be done very early in the Pharo 7 dev. Thus >> it would let time to people to adapt their project. >> > > I agree :) > +1 for inheriting by default. If ever we don't want to inherit, it's as simple as implementing shouldInheritSelectors ^false It's far more simple than implementing isAbstract at class side as we have to do now. 99% of the time we want to inherit, and what we see in order to avoid isAbstract dance is shouldInheritSelectors ^true One more word about Pharo version. In original SUnit we control with these simple two methods: buildSuiteFromSelectors ^self shouldInheritSelectors ifTrue: [self buildSuiteFromAllSelectors] ifFalse: [self buildSuiteFromLocalSelectors] shouldInheritSelectors ^self superclass isAbstract or: [self testSelectors isEmpty] In Pharo this has been refactored: - buildSuiteFromAllSelectors is not sent, but duplicated in buildSuiteFromSelectors - buildSuiteFromLocalSelectors is not sent either, - all happens in allTestSelectors, which has changed of semantic and does not allways answer all tests selectors :( But the logic seems to remain the same: if the superclass is abstract OR if the set of selectors is empty, then the class will inherit... If my opinion ever counts, what I see is refactoring for refactoring. I don't see any new feature, just more unsent selectors, more garbage, and unclear semantic. I call this runaway refactoring. There's enough thing to clean in Squeak to avoid "cleaning" what works well no?

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Eliot Miranda

Hi Cyril, > On Jun 3, 2017, at 5:50 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > >> Le 04/06/2017 Ã 02:26, monty a Ã©crit : >> I've seen this before, and I'm not sure it's a bug. >> >> A testless, non-abstract subclass of a TestCase is useless unless it inherits test methods. But if it defines its own test methods, then it isn't clear if it was made a subclass to inherit test methods, or if it was made a subclass to inherit non-test helper methods, or both. I think to be safe it assumes the second. >> >> Implement #shouldInheritSelectors in the superclass to get your intended behavior. >> >> > > I think that in most case we want the tests from the superclass. At > least this is what I expect. > > A subclass of an object keep the behaviour of its superclass when the > methods are not overridden. Why should it be different for tests? > > I see your point but if that is the case I think it should inherit the > tests by default and we could had a way to prevent this behaviour in > some cases. > > It is very awkward to get less tests after adding a new test in a class. > I think it reduce the power of the tests. As Minty points out, this unintuitive behaviour exists fur a reason and there is a work around. SUnit is a community wide package existing in all the dialects of Smalltalk I'm aware of. If you change the semantics then every time a test suite is exchanged it will need to be rewritten, and by someone who understands the divergence, otherwise the test suite won't work as intended. Is is worth diverging from a community wide standard when there is a rationale for the design and there is a work around? Is it puss bow to seek a wider consensus and see what e.g. the VisualWorks, VisualAge and GemStone communities think? Is it possible that better documenting the work around would be better? > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France _,,,^..^,,,_ (phone)

June 4, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by K K Subbu

> On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote: > Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download I uploaded some fixes for review after clearing them through testrunner. But Validation builds failed because of network timeouts, e.g: [ ConnectionTimedOut signal: 'Cannot connect to ', (NetNameResolver stringFromAddress: hostAddress) , ':', port asString ] in Socket as in https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator-simple/15867/artifa… Is this a temporary issue? When should I retry for review? Thanks and Regards .. Subbu

June 4, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Denis Kudriashov

2017-06-04 15:03 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > If most people agree that we should inherit the tests by default I think > this is a change that should be done very early in the Pharo 7 dev. Thus > it would let time to people to adapt their project. > I agree :)

June 4, 2017