- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 20:51, stepharo wrote: > I like the idea that you package to postcondition, invariant and > precondition > not in the methods themselves but in separate methods. > I did not think about that but this is nice because you do not pollute > the code > and we could put them in a precondition protocols. Yes that was the idea. to think about what your code should do without being in code logic or reading to much the code ie. keep it separated from the implementation . even with another browser like the tools pointed to by Stephan which looks really cool (the screen shots a least) > > About the pragma why not > > isEmpty > > <preconditionOf: #add:> > > I think that it is nicer than > > <contract: #postcondition ....> > > Yes much nicer ... And the same with <postconditionOf:..> much clearer > Now can you support the old value? yes, I think no problem to support both that's a part I'll refactor anyway, it is a bit ugly because I changed several times and wanted to make my tests pass. Another point is that I would like to use it on itself, see how it runs on itself, but also how I can express it in terms of contracts ... > > Stef > > -- Alain

Feb. 26, 2016

Re: [Pharo-dev] [bloc] when saving bloc and relaunching I get

by Aliaksei Syrel

The same for me... Looks like something spur related. I could not find what causes an issue :( On Feb 26, 2016 8:39 PM, "stepharo" <stepharo(a)free.fr> wrote: >

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 26/02/2016 20:47, stepharo wrote: > You see if me and alex got confused and we know quite well what is > design by contract > then better changed the syntax > > Stef > Yes, of course, that's what I thought. This is done and on smalltalkhub now. As soon as Marcus implement the return node in MetaLink as he said, I add the ability to test the returned values. There is lot left to do, I'll add more tests and refactor in the meanwhile. I'm eager to see the result of this poc. :) -- Alain

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

I like the idea that you package to postcondition, invariant and precondition not in the methods themselves but in separate methods. I did not think about that but this is nice because you do not pollute the code and we could put them in a precondition protocols. About the pragma why not isEmpty <preconditionOf: #add:> I think that it is nicer than <contract: #postcondition ....> Now can you support the old value? Stef

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

You see if me and alex got confused and we know quite well what is design by contract then better changed the syntax Stef Le 26/2/16 11:50, Alain Rastoul a Ã©crit : > On 26/02/2016 11:26, Alexandre Bergel wrote: >> Hi Alain, >> >> Having contract is a valuable effort! >> >>> On Feb 26, 2016, at 11:12 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> >>> wrote: >>> >>> <contract: #ensured appliedTo: #( #add: )> >> >> What does that mean? >> <contract: #ensured appliedTo: #( #add: )> >> >> Alexandre >> > Hi Alexandre, > > a method with a pragma > <contract: #ensured appliedTo: #( #add: ) > > means it is a check that must be ensured by (enforced by) the method > to which it applies (here add:). > The add: method of the object *must* verify this check, when the check > is executed, it must return true. > > May be the terms I've choosed are confusing at first, but it was > voluntary, preCondition, postCondition are too much program execution > oriented IMHO, not enough assertive . > > btw it is easy to change: > one could say here: > <contract: postcondition on: #( #add: )> > > may be better ? > > or may be better to support both ... :) > > > Alain > > >

Feb. 26, 2016

Re: [Pharo-dev] Setting the font for a spec button

by stepharo

Stephan I created a Spec tutorial on github and the goal is to gather all the material on Spec. Do you want to add your example in a file? So that it does not get lost Stef Le 26/2/16 17:45, Stephan Eggermont a Ã©crit : > Makes it possible to use icon fonts > > Stephan

Feb. 26, 2016

[bloc] when saving bloc and relaunching I get

by stepharo

Feb. 26, 2016

Re: [Pharo-dev] Setting the font for a spec button

by Alexandre Bergel

Impressive! Alexandre > On Feb 26, 2016, at 5:45 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Makes it possible to use icon fonts > > Stephan > <Screenshot from 2016-02-26 17-43-19.png> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 25/02/2016 23:48, Alain Rastoul wrote: @Stef, Alexandre, Damien, Nicolai, Stephan, Thank you for the discussions, pointing me errors and interesting link. I understood that the concept and/or it's implementation seems a bit obscure, partly because of the syntax I've chosen for pragmas. I will conform to some naming standards : #invariant/#pre/#post/on: will be clearer than #required/#ensured/appliedTo:. <contract: #invariant> ... <contract: #pre on: #aMethod> ... <contract: #pre on: #( #aMethod1 ... #aMethodn)> ... idem post: <contract: #post on: #aMethod> ... <contract: #post on: #( #aMethod1 ... #aMethodn)> ... I also note the suggestion of Damien (putting the pragma contracts in the methods) but I am not truly convinced and it would imply some rework, so I will not do that now - perhaps after a try. examples fooContract1 <contract: #invariant> ^ myState notNil. fooContract2 <contract: #post on: #foo> ... postAdd: anObject <contract: #post on: #(add: #addLast:)> ^ self includes: anObject etc. -- Alain

Feb. 26, 2016

Re: [Pharo-dev] Recursion inside #doesNotUnderstand: method. Why?

by Eliot Miranda

> On Feb 26, 2016, at 9:12 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-02-25 18:24 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> It's so that when a doesNotUnderstand: occurs and one implements the method in the debugger one can proceed. The sentTo: at the end will now invoke the newly defined method and one can continue programming. > > But as I said I make experiment. And in Pharo this recursion is not needed to implement unknown messages in Debugger. But for case of Vincent it is needed Which implies that the debugger is doing something unnecessary. Instead of creating an activation of the newly defined message it could simply proceed? _,,,^..^,,,_ (phone)

Feb. 26, 2016