Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
Reverting EyeInspector>>#updateList revealed the error when Phexample is used in latest Pharo 3.0...

PhexMatcher uses #= as part of it's DSL e.g. "1 should = 1". Because it doesn't respond normally to #=, #hash is implemented to signal an error (self error: 'Don''t put a matcher into a dictionary. It does not behave ordinarily on ='). I guess the receiver inspector on the bottom left of the debugger keeps the items in a dictionary, so #hash gets called and everything blows up.

The first thought that comes to my mind is that #= is "too cute" as a DSL. #= is too deep of a smalltalk concept to justify hijacking, AFAICT to avoid writing equals:.

I removed #= and #hash from PhexMatcher, adding an #equals: with the former #= implementation, and everything seems to work.

I don't have write access to http://smalltalkhub.com/mc/Phexample/Phexample/main/ and realize it's a big API change, so I committed the fix to http://smalltalkhub.com/mc/SeanDeNigris/SeansOutbox/main/ :
Name: Phexample-SeanDeNigris.71

MAJOR API CHANGE:
- change matcher #= to #equal: e.g. "1 should = 1" would now be written "1 should equal: 1"
- update all code to use new API

Motivation: the #= magic made it impossible to store matchers in dictionaries, and #hash was implemented to signal an error explaining as much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts, and are assumed to work as expected. In Pharo 3.0, the debugger tried to put matchers in a dictionary, causing an infinite error loop whenever a matcher failed.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Stefan Marr-3
Hi Sean:

First of all, I enabled public write access on the repository.
While I am the admin on the project, I took it over from Niko and Adrian, and at this point, I would consider it ‘community maintained’.

The rest inline:

On 22 Apr 2014, at 16:40, Sean P. DeNigris <[hidden email]> wrote:

> - change matcher #= to #equal: e.g. "1 should = 1" would now be written "1
> should equal: 1"
>
> Motivation: the #= magic made it impossible to store matchers in
> dictionaries, and #hash was implemented to signal an error explaining as
> much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts,
> and are assumed to work as expected. In Pharo 3.0, the debugger tried to put
> matchers in a dictionary, causing an infinite error loop whenever a matcher
> failed.

I personally don’t have a qualified opinion, in the sense that I do not actively use Phexample at the moment.
Still, I will state it anyway: I don’t like the change.

So, just for the sake of argument, are there other ways?
Are matchers reused, or are they one-shot things?
If the later is true, perhaps, we could maintain the ‘cuteness’ of #= by making the matchers a little more cooperative?
If they are one-shot objects, how about using their standard behavior only on the first access, and then switch their state so that #= and #hash respond normally?

Thanks
Stefan



--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/




Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
Stefan Marr-3 wrote
Still, I will state it anyway: I don’t like the change.
I expected it to be unpopular ;)

Stefan Marr-3 wrote
So, just for the sake of argument, are there other ways?
I don't know. I'm open...

As far as making #= mean something different the first time, I think this gets us further down the difficult-to-understand rabbit hole. Also, #= is not always sent; it's one of several options, like #beFalse. I guess maybe you could say "as soon as any expectation is set up, revert to a traditional #=. But philosophically, hijacking #= disrupts the uniformity of the system and adds to the user's cognitive load. Hijacking it only some of the time makes it even less predictable.

And, what's the specific argument for keeping the behavior of #=? Am I missing some value that makes it worth all of the above? I think it's important to separate the logic from the inertia inevitably accompanying this kind of change.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Eliot Miranda-2



On Tue, Apr 22, 2014 at 7:26 PM, Sean P. DeNigris <[hidden email]> wrote:
Stefan Marr-3 wrote
> Still, I will state it anyway: I don’t like the change.

I expected it to be unpopular ;)


Stefan Marr-3 wrote
> So, just for the sake of argument, are there other ways?

I don't know. I'm open...

As far as making #= mean something different the first time, I think this
gets us further down the difficult-to-understand rabbit hole. Also, #= is
not always sent; it's one of several options, like #beFalse. I guess maybe
you could say "as soon as any expectation is set up, revert to a traditional
#=. But philosophically, hijacking #= disrupts the uniformity of the system
and adds to the user's cognitive load. Hijacking it only some of the time
makes it even less predictable.

+1.

And, what's the specific argument for keeping the behavior of #=? Am I
missing some value that makes it worth all of the above? I think it's
important to separate the logic from the inertia inevitably accompanying
this kind of change.



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Destroying-Bug-tp4755787p4755919.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.




--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
In reply to this post by Stefan Marr-3
Stefan Marr-3 wrote
First of all, I enabled public write access on the repository.
It doesn't look like it has public write access. Notice the difference compared to the Pharo Inbox:

Phexample repo
vs.
Pharo Inbox repo
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Stefan Marr-3
Hi Sean:

On 24 Apr 2014, at 02:49, Sean P. DeNigris <[hidden email]> wrote:

> Stefan Marr-3 wrote
>> First of all, I enabled public write access on the repository.
>
> It doesn’t look like it has public write access.

Guess the error is between chair and screen. I probably forgot to save the change or something…
Now it should be enabled.

Could you try again?

Thanks
Stefan



--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/




Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
Stefan Marr-3 wrote
Now it should be enabled.
Looks good, thanks!
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
In reply to this post by Stefan Marr-3
Stefan Marr-3 wrote
> It doesn’t look like it has public write access.

Guess the error is between chair and screen. I probably forgot to save the change or something…
Now it should be enabled.
It may have reverted during the recent sthub problems. Would you try one more time, or add me as a developer? Thanks again.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Stefan Marr-3
Hi Sean:

On 29 Aug 2014, at 03:17, Sean P. DeNigris <[hidden email]> wrote:

> Stefan Marr-3 wrote
>>> It doesn’t look like it has public write access.
>>
>> Guess the error is between chair and screen. I probably forgot to save the
>> change or something…
>> Now it should be enabled.
>
> It may have reverted during the recent sthub problems. Would you try one
> more time, or add me as a developer? Thanks again.

I added you.

Best regards
Stefan

--
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/




Reply | Threaded
Open this post in threaded view
|

Re: Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

Sean P. DeNigris
Administrator
In reply to this post by Sean P. DeNigris
Sean P. DeNigris wrote
MAJOR API CHANGE:
- change matcher #= to #equal: e.g. "1 should = 1" would now be written "1 should equal: 1"
- update all code to use new API

Motivation: the #= magic made it impossible to store matchers in dictionaries, and #hash was implemented to signal an error explaining as much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts, and are assumed to work as expected. In Pharo 3.0, the debugger tried to put matchers in a dictionary, causing an infinite error loop whenever a matcher failed.
I bumped the version from 1.2 -> 2.0 per semantic versioning (non-backward-compatible bumps major) and copied the config to MetaRepFor30
Cheers,
Sean