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

Re: [Pharo-project] Abstract classes

by csrabak＠bol.com.br

Em 29/10/2009 08:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> escreveu: > 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 That was not the way I envisaged. . . see below. > ...and you could not create any instance of Object and its > subclasses anymore (but via a few primitives bypassing this > mechanism). Again what I was thinking aloud (and continuing) is less of putting some 'magical' method in Object that detects if it's abstract or not but a reasonable way of the programmer when constructing the class put int in the code: Say we had: Object>>isAbstract ^false When a class is added to the system the one would do: SomeClass class>>new ^self raise: Error. SomeClass>>isAbstract ^true > Beside, do you want a runtime check at each creation? We would > have to cache the information at least... I don't any use of the mechanism if it is not enforceable automatically. Otherwise, I could cynically say that the easiest way to attain the objective would have the programmer inspect the class code [s]he is thinking of instantiating! OTOH, notice that mainstream languages use explicit declarations to have its classes Abstract, not the way around (I mean having the programming environment detect using its characteristics). my 0.01999999.... -- Cesar Rabak

Oct. 29, 2009

Re: [Pharo-project] Code Critic

by Simon Denier

On 29 oct. 2009, at 14:37, Andrew P. Black wrote: > Can someone please explain to me how to run code critic on a single > class or a single package? In short, use refactoring scope (environment browser) Follow the nice screencast of Lukas http://www.lukas-renggli.ch/blog/ob-rb-3 > > I managed to run it (overnight) on Smalltalk. It found 70189 > problems, many of them jaw-dropping. But I would like to focus it > on my code! > > Andrew > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 29, 2009

[Pharo-project] Is serving files different in Pharo?

by Mart-Mari Breedt

Hallo, I have just install and started playing a bit with Pharo today. The first thing I tried was to take one of my Seaside projects from Squeak and see if I can get it going in Pharo? Everything went very smoothly, except for the following annoying problem - which I - rather embarrassingly - can't seem to figure out myself. Any help/hints/pointers will be greatly appreciated. For my Squeak/Seaside project I've subclassed WAKomEncoded and have overridden the createService selector to allow for a custom entry point and the ability to serve files from this point. createService | basePath seaside assembly | basePath := 'encore'. seaside := self entryPoint: (WADispatcher default setName: basePath). assembly := ModuleAssembly core. assembly serverRoot: FileDirectory default fullName. assembly alias: '/' , basePath to: [assembly addPlug: [:request | seaside process: request]]. assembly documentRoot: FileDirectory default fullName. assembly directoryIndex: 'index.html index.htm'. assembly serveFiles. ^ (HttpService startOn: port named: 'comanche') plug: assembly rootModule; yourself. The custom entry point still works fine, but for some strange reason none of my files are served correctly. Is there a different approach to serving files from within Pharo/Seaside that I should make use of? I have downloaded and used this Pharo package: pharo1.0-10491-rc1dev09.10.5.zip. And installed these additional packages: DynamicBindings-GiovanniCorriga.10.mcz KomHttpServer-GiovanniCorriga.50.mcz KomServices-gc.19.mcz OSProcess-dtl.53.mcz Seaside2.8a1-lr.594.mcz Scriptaculous-lr.250.mcz HTML5-mb.10.mcz Thanks in advance! Kind regards, Mart-Mari LTE USA â09, 4-5 November (non exhibitor) Click mailto:events@aircominternational.com?subject=LTE%20USA%20'09%20%20meeting%20request to book a meeting AfricaComâ09, 11-12 November stand C13, Cape Town, South Africa Click mailto:events@aircominternational.com?subject=AfricaCom%20meeting%20request to book a meeting Disclaimer: This e-mail message is confidential and should not be used by, or disclosed to, anyone except the addressee. If you receive this message in error, please advise the sender immediately.. Since e-mail transmission is not secure or error free, we do not accept responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your systems. You should therefore virus-check all attachments before opening. AIRCOM may monitor incoming and outgoing emails through its networks and by responding to this email, you consent to such monitoring. The views and opinions expressed in this e-mail are those of the author only and not of AIRCOM. We do not intend to enter into any legal commitments or contracts by e-mail. P Save a tree. Don't print this e-mail unless it's really necessary

Oct. 29, 2009

[Pharo-project] Code Critic

by Andrew P. Black

Can someone please explain to me how to run code critic on a single class or a single package? I managed to run it (overnight) on Smalltalk. It found 70189 problems, many of them jaw-dropping. But I would like to focus it on my code! Andrew

Oct. 29, 2009

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

by Dennis Schetinin

2009/10/29 George Herolyants <george.herolyants(a)gmail.com> > 2009/10/29 Dennis Schetinin <chaetal(a)gmail.com>: > > For me it's not clear at all. But this is much more obvious: > > > > stack := self resultOf: [self shouldBeEmpty]. > > > > So why to use a block then? And stop, why to use "resultOf:"??? > For the same reason the execution of the test was being wrapped by original #given: (maybe we have to ask author?) > >> And by "declarative" I meant > >> the way you specify dependencies between your tests. If it was done > >> your way, test would be performed twice. > > > > Why? > > Don't you expect the block to be evaluated? > > >> > >> If you use symbol, you don't > >> have to do it (haven't seen the library yet, just guessing :). > > > > Don't have to do what? > > Don't have to execute method shouldBeEmpty twice. > Sorry, I don't understand. My variant was exactly the same as (unknown:) original one but using explicit message send instead of hiding it by selector passing. Including number of #shouldBeEmpty executions. -- Dennis Schetinin

Oct. 29, 2009

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>: > For me it's not clear at all. But this is much more obvious: > > Â Â Â Â Â stack := self resultOf: [self shouldBeEmpty]. > So why to use a block then? And stop, why to use "resultOf:"??? >> And by "declarative" I meant >> the way you specify dependencies between your tests. If it was done >> your way, test would be performed twice. > > Why? Don't you expect the block to be evaluated? >> >> If you use symbol, you don't >> have to do it (haven't seen the library yet, just guessing :). > > Don't have to do what? Don't have to execute method shouldBeEmpty twice.

Oct. 29, 2009

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

by Dennis Schetinin

... BTW, it's very similar to mocks implementations. The 1-st version was (as in SMocks) something like: mock expect: #messageSend. ... self checkExpectations. But it's much more intension-revealing and convinient to use mocks another way (as in Mocketry for example): [sut doSomethings] checking: [mock messageSend]. I think in the case of example-driving tests it's still actual... -- Dennis Schetinin

Oct. 29, 2009

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

by Dennis Schetinin

2009/10/29 George Herolyants <george.herolyants(a)gmail.com> > 2009/10/29 Dennis Schetinin <chaetal(a)gmail.com>: > > Using symbols (i.e. "almost" constants) instead of explicitly telling > what > > is happenning (sending a message) is more clean?! :) Ok then... (Not > sure > > what you mean by "declarative" here) > > The message "given:" tells that to you. For me it's not clear at all. But this is much more obvious: stack := self resultOf: [self shouldBeEmpty]. And by "declarative" I meant > the way you specify dependencies between your tests. If it was done > your way, test would be performed twice. Why? > If you use symbol, you don't > have to do it (haven't seen the library yet, just guessing :). > Don't have to do what? -- Dennis Schetinin

Oct. 29, 2009

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>: > Using symbols (i.e. "almost" constants) instead of explicitly telling what > is happenning (sending a message)Â is more clean?! :) Ok then... (Not sure > what you mean by "declarative" here) The message "given:" tells that to you. And by "declarative" I meant the way you specify dependencies between your tests. If it was done your way, test would be performed twice. If you use symbol, you don't have to do it (haven't seen the library yet, just guessing :).

Oct. 29, 2009

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

by Dennis Schetinin

2009/10/29 George Herolyants <george.herolyants(a)gmail.com> > 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. > Using symbols (i.e. "almost" constants) instead of explicitly telling what is happenning (sending a message) is more clean?! :) Ok then... (Not sure what you mean by "declarative" here) -- Dennis Schetinin

Oct. 29, 2009