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
