Ok. I can do this. I think showing examples from project wiki page is enough. Plus demo of how extend syntax sugar and how to use stubs. What people really want to see about mock objects framework?
2013/3/27 Yuriy Tymchuk <yuriy.tymc...@me.com> > If you can write step by step instruction what to show, I can do it. Right > now all my time is used to prepare my own presentation, so I can't do it > myself. > > uko > > > > On 27 бер. 2013, at 18:41, Denis Kudriashov <dionisi...@gmail.com> wrote: > > 2013/3/27 Tudor Girba <tu...@tudorgirba.com> > >> Perhaps Mocketry would be a good topic for a "Show us your projects" >> session. Then we can try to go into a couple of more details. >> >> > Unfortunately I can't participate conference this year > > >> Cheers, >> Doru >> >> >> On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <yuriy.tymc...@me.com> wrote: >> >> > Sounds good to me. >> > >> > On 26 бер. 2013, at 23:00, Camillo Bruni <camillobr...@gmail.com> >> wrote: >> > >> >> >> >> On 2013-03-26, at 19:45, Denis Kudriashov <dionisi...@gmail.com> >> wrote: >> >> >> >>> 2013/3/26 Yuriy Tymchuk <yuriy.tymc...@me.com> >> >>> >> >>>> Ok, and what if we will change behavior a bit so if no definitions >> were >> >>>> found it will send the incoming message to enclosed object? This way >> it >> >>>> will work like phexample but will also allow to define some fancy >> DSL. >> >>>> >> >>> >> >>> We can copy all phexample syntax methods into single class inside >> >>> StateSpecs package but replace implementation with pragmas approach. >> So >> >>> anybody can browse implementors like usual and it will not required >> any >> >>> special cases. >> >>> >> >>> How I can influence your interest, guys? I can provide cleaning, >> comments, >> >>> improvements to StateSpecs. I opened for your requirements. >> >>> Phexample become quite popular and can be part of Pharo sometimes. >> >>> Mocketry/StateSpecs used by people too. >> >>> It would be bad if this packages can't be used together. >> >> >> >> sorry for starting the whole rant :) I am veery busy at least until >> tomorrow >> >> >> >> Yuriy we can discuss that after tomorrow? >> >> I would as well appreciate some common solution to avoid the selector >> clash. >> >> >> >> >> >> >> >>>> On 26 бер. 2013, at 07:46, Denis Kudriashov <dionisi...@gmail.com> >> wrote: >> >>>> >> >>>> Hello >> >>>> 2013/3/26 Camillo Bruni <camillobr...@gmail.com> >> >>>> >> >>>>> Definitely StateSpec looks more mature and can be used in a more >> flexible >> >>>>> way. >> >>>>> But I am not a big fan of the pragma magic. Why? >> >>>>> It breaks all tools for me :/. If I see a message send I want to be >> able >> >>>>> to: >> >>>>> - browse it, so I can see who implements it? >> >>>>> - debug it directly to get to the real method. >> >>>>> >> >>>>> SateSpec does indeed help writing readable code by allowing almost >> >>>>> grammatically >> >>>>> correct sentences. However I don't think this is the way to >> program. I am >> >>>>> a big >> >>>>> fan of stupid english: >> >>>>> >> >>>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> >>>>> >> >>>>> If I want to figure out how the first one works, I can simply >> browse the >> >>>>> implementors of #should and/or #isKindOf: where is the StateSpec >> version >> >>>>> I am >> >>>>> lost. I have to rely on "contains string literal" to get the >> sources, for >> >>>>> me >> >>>>> that is very strange. >> >>>>> >> >>>> >> >>>> I think main thing you want is easilly explore all available should >> >>>> syntax. And StateSpecs can be easilly adopted for such task. We can >> just >> >>>> move all methods with syntax pragmas to single class. So you can >> open this >> >>>> class and see what available. >> >>>> >> >>>> To get implementors of some "should expression" you should use >> senders >> >>>> search of syntax words instead of implementors. Syntax words in >> StateSpecs >> >>>> is just method literals ( <syntax: #(be an instance of:)>, #() is >> just >> >>>> array of symbols). >> >>>> >> >>>> Interesting that StateSpecs has more explicit syntax system. How you >> can >> >>>> explore in Phexample expression: >> >>>> >> >>>> object should be true >> >>>> ? >> >>>> >> >>>> You have separate PheMatcher>>be and PheMatcher>>true methods and >> there is >> >>>> no places in code where you can see that this messages can and >> should be >> >>>> used together. >> >>>> But with StateSpecs you should put pragma with explicit expression >> like: >> >>>> >> >>>> Equal>>true: anObject >> >>>> <syntax: #(be true)> >> >>>> ^self return: (IdentitySpec pattern: true) >> >>>> >> >>>> So with StateSpecs you have full syntax expression at one place >> which can >> >>>> be easy explored. >> >>>> And for example to support Phexample mesage #beTrue you should just >> add >> >>>> another pragma: >> >>>> >> >>>> Equal>>true: anObject >> >>>> <syntax: #(be true)> >> >>>> <syntax: #(beTrue)> >> >>>> ^self return: (IdentitySpec pattern: true) >> >>>> >> >>>> So with Phexample you can browse implementors of "single word should >> >>>> expressions". But with Phexample if you browse implementors of #be >> like >> >>>> messages you have no idea how it can be used. >> >>>> In StateSpecs you should use senders. And with StateSpecs if you >> browse >> >>>> "any syntax word implementors" by senders seach you will see all >> possible >> >>>> usage cases. And if I move all methods with syntax pragmas to single >> class >> >>>> you can easilly see all possible expressions in one place. >> >>>> >> >>>> `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` >> >>>>> >> >>>> >> >>>> With StateSpecs it should be >> >>>> >> >>>> foo should be a kind of: Bar >> >>>> >> >>>> And as I said before It is simple task to support all Phexample >> >>>> expressions by StateSpecs pragmas >> >>>> >> >>>> Best regards, >> >>>> Denis >> >>>> >> >>>> >> >>>> >> >> >> >> >> > >> > >> >> -- >> www.tudorgirba.com >> >> "Sometimes the best solution is not the best solution." >> >> >> > >
