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.
Cheers, Doru On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <[email protected]> wrote: > Sounds good to me. > > On 26 бер. 2013, at 23:00, Camillo Bruni <[email protected]> wrote: > >> >> On 2013-03-26, at 19:45, Denis Kudriashov <[email protected]> wrote: >> >>> 2013/3/26 Yuriy Tymchuk <[email protected]> >>> >>>> 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 <[email protected]> wrote: >>>> >>>> Hello >>>> 2013/3/26 Camillo Bruni <[email protected]> >>>> >>>>> 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."
