On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <
yuriy.tymchuk@me.com> wrote:
> Sounds good to me.
>
> On 26 ������. 2013, at 23:00, Camillo Bruni <
camillobruni@gmail.com> wrote:
>
>>
>> On 2013-03-26, at 19:45, Denis Kudriashov <
dionisiydk@gmail.com> wrote:
>>
>>> 2013/3/26 Yuriy Tymchuk <
yuriy.tymchuk@me.com>
>>>
>>>> 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 <
dionisiydk@gmail.com> wrote:
>>>>
>>>> Hello
>>>> 2013/3/26 Camillo Bruni <
camillobruni@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
>>>>
>>>>
>>>>
>>
>>
>
>