2013/3/27 Tudor Girba <[email protected]> > Perhaps Mocketry would be a good topic for a "Show us your projects" > session. Then we can try to go into a couple of more details. > > Unfortunately I can't participate conference this year
> Cheers, > Doru > > > On Mar 27, 2013, at 12:42 AM, Yuriy Tymchuk <[email protected]> wrote: > > > 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 > >>>> > >>>> > >>>> > >> > >> > > > > > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > >
