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