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