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. > > 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 > > >
