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