Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

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

Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

abergel
Hi!

Just to share some thought.
I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):

        self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error

I have to shut down the method #validateShouldntException:

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Camillo Bruni-3
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
it looks unsuspicous until the moment you try understand such a failing assertion.

On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote:

> Hi!
>
> Just to share some thought.
> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
>
> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>
> I have to shut down the method #validateShouldntException:
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>


signature.asc (457 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

abergel
Instead of using shouldnt:raise:, you can simply remove the assertion, as in:

-=-=-=-=-=-=-=-=-=
testNoErrorWhenDrawing
        self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
-=-=-=-=-=-=-=-=-=

||
V

-=-=-=-=-=-=-=-=-=
testNoErrorWhenDrawing
        view raw drawOn: tracingCanvas
-=-=-=-=-=-=-=-=-=

With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
I read your post and I kind of agree.
I will fix my tests then.

Alexandre


On Oct 22, 2013, at 12:08 AM, Camillo Bruni <[hidden email]> wrote:

> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
> it looks unsuspicous until the moment you try understand such a failing assertion.
>
> On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote:
>
>> Hi!
>>
>> Just to share some thought.
>> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
>>
>> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>>
>> I have to shut down the method #validateShouldntException:
>>
>> Cheers,
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Camillo Bruni-3

On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote:

> Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
>
> -=-=-=-=-=-=-=-=-=
> testNoErrorWhenDrawing
> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
> -=-=-=-=-=-=-=-=-=
>
> ||
> V
>
> -=-=-=-=-=-=-=-=-=
> testNoErrorWhenDrawing
> view raw drawOn: tracingCanvas
> -=-=-=-=-=-=-=-=-=
>
> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors
does not make much sense. It makes a little bit more sense when using a specific Error, and it
makes sense when testing for Notifications, which would go otherwise unnoticed.

Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets
you use anything else.

> I read your post and I kind of agree.
> I will fix my tests then.

nice :)

signature.asc (457 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Stéphane Ducasse
In reply to this post by Camillo Bruni-3
I will add a discussion to the SUnit Chapter about this point.

Stef

On Oct 22, 2013, at 12:08 AM, Camillo Bruni <[hidden email]> wrote:

> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
> it looks unsuspicous until the moment you try understand such a failing assertion.
>
> On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote:
>
>> Hi!
>>
>> Just to share some thought.
>> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
>>
>> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>>
>> I have to shut down the method #validateShouldntException:
>>
>> Cheers,
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Johan Brichau-2
In reply to this post by Camillo Bruni-3
In Seaside, there are a couple of tests that now fail because of this change.

Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho.

I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end.
I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause.

Johan

On 22 Oct 2013, at 00:26, Camillo Bruni <[hidden email]> wrote:

>
> On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote:
>
>> Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
>>
>> -=-=-=-=-=-=-=-=-=
>> testNoErrorWhenDrawing
>> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>> -=-=-=-=-=-=-=-=-=
>>
>> ||
>> V
>>
>> -=-=-=-=-=-=-=-=-=
>> testNoErrorWhenDrawing
>> view raw drawOn: tracingCanvas
>> -=-=-=-=-=-=-=-=-=
>>
>> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
>
> Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors
> does not make much sense. It makes a little bit more sense when using a specific Error, and it
> makes sense when testing for Notifications, which would go otherwise unnoticed.
>
> Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets
> you use anything else.
>
>> I read your post and I kind of agree.
>> I will fix my tests then.
>
> nice :)


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Camillo Bruni-3
On 2013-10-22, at 09:46, Johan Brichau <[hidden email]> wrote:
> In Seaside, there are a couple of tests that now fail because of this change.
>
> Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho.

That's not true, that is the default behavior that you test for not Errors.
I mean every code that is run must work and testing that it does not raise
and Error is duplicated efforts. As I said, checking for any other error makes
somehow sense, but not for Error itself. Because that basically means that you
ignore what the test does since you are not specific at all. The test framework
takes already care of that part, if you have an error the test fails. I think
that is the goal. I do not understand why you would have to explain this to the
user of the tests, since for him the result does not change. Yes it is red
instead of yellow, but does that matter? I mean you just transformed at will an
error into an assertion failure, to me this sounds very bogus. Just because you
transform the error to an assertion, you did not anticipated anything, since you
cannot be sure at all where the error happened, since you do not test for an
explicit error. On the other hand if you call a method that is very small to check
if it really works, you know which errors are signaled and you test explicitly
for those.

I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error
to a refactored version that even includes a comment.

> I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end.
> I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause.

But if you just use the expression directly, the debugger pops up in the place where
the error was signaled. Not somewhere in deep in the assertion framework. Furthermore
if you run the test under jenkins you will get no reasonable feedback (yes this should
be changed as well). Just try to debug the following statement in a test:

        self shouldnt: [ 0/0 ] raise: Error

vs.
        0/0.


Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error.

> Johan
>
> On 22 Oct 2013, at 00:26, Camillo Bruni <[hidden email]> wrote:
>
>>
>> On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote:
>>
>>> Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
>>>
>>> -=-=-=-=-=-=-=-=-=
>>> testNoErrorWhenDrawing
>>> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>>> -=-=-=-=-=-=-=-=-=
>>>
>>> ||
>>> V
>>>
>>> -=-=-=-=-=-=-=-=-=
>>> testNoErrorWhenDrawing
>>> view raw drawOn: tracingCanvas
>>> -=-=-=-=-=-=-=-=-=
>>>
>>> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
>>
>> Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors
>> does not make much sense. It makes a little bit more sense when using a specific Error, and it
>> makes sense when testing for Notifications, which would go otherwise unnoticed.
>>
>> Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets
>> you use anything else.
>>
>>> I read your post and I kind of agree.
>>> I will fix my tests then.
>>
>> nice :)
>
>


signature.asc (457 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Igor Stasenko



On 22 October 2013 10:02, Camillo Bruni <[hidden email]> wrote:
On 2013-10-22, at 09:46, Johan Brichau <[hidden email]> wrote:
> In Seaside, there are a couple of tests that now fail because of this change.
>
> Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho.

That's not true, that is the default behavior that you test for not Errors.
I mean every code that is run must work and testing that it does not raise
and Error is duplicated efforts.
 
+1
'shouldn't raise' is bogus and as you said, it is default expectation for any code
you run that it doesn't throws any errors.
(that's why exceptions called so and that's why error is exception).

i can understand why i would want to use 'should raise' to check that my code
throws appropriate error when i using wrong data etc.. but not this one.
 
As I said, checking for any other error makes
somehow sense, but not for Error itself. Because that basically means that you
ignore what the test does since you are not specific at all. The test framework
takes already care of that part, if you have an error the test fails. I think
that is the goal. I do not understand why you would have to explain this to the
user of the tests, since for him the result does not change. Yes it is red
instead of yellow, but does that matter? I mean you just transformed at will an
error into an assertion failure, to me this sounds very bogus. Just because you
transform the error to an assertion, you did not anticipated anything, since you
cannot be sure at all where the error happened, since you do not test for an
explicit error. On the other hand if you call a method that is very small to check
if it really works, you know which errors are signaled and you test explicitly
for those.

I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error
to a refactored version that even includes a comment.

> I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end.
> I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause.

But if you just use the expression directly, the debugger pops up in the place where
the error was signaled. Not somewhere in deep in the assertion framework. Furthermore
if you run the test under jenkins you will get no reasonable feedback (yes this should
be changed as well). Just try to debug the following statement in a test:

        self shouldnt: [ 0/0 ] raise: Error

vs.
        0/0.


Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error.

> Johan
>
> On 22 Oct 2013, at 00:26, Camillo Bruni <[hidden email]> wrote:
>
>>
>> On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote:
>>
>>> Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
>>>
>>> -=-=-=-=-=-=-=-=-=
>>> testNoErrorWhenDrawing
>>>     self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
>>> -=-=-=-=-=-=-=-=-=
>>>
>>> ||
>>> V
>>>
>>> -=-=-=-=-=-=-=-=-=
>>> testNoErrorWhenDrawing
>>>     view raw drawOn: tracingCanvas
>>> -=-=-=-=-=-=-=-=-=
>>>
>>> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
>>
>> Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors
>> does not make much sense. It makes a little bit more sense when using a specific Error, and it
>> makes sense when testing for Notifications, which would go otherwise unnoticed.
>>
>> Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets
>> you use anything else.
>>
>>> I read your post and I kind of agree.
>>> I will fix my tests then.
>>
>> nice :)
>
>




--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Philippe Marschall-2
In reply to this post by Camillo Bruni-3
On 22.10.13 00:08, Camillo Bruni wrote:
> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
> it looks unsuspicous until the moment you try understand such a failing assertion.

This isn't moving Pharo foward. This doesn't make the system any more
flexible, adaptable, modular or malleable. This doesn't make the system
any easier to maintain. This doesn't make the system any smaller,
faster, scalable or secure. This doesn't make the system any easier to
maintain. This doesn't make life easier for anybody developing Pharo or
using Pharo. This doesn't improve Pharo in any way.

This only adds code who's sole purpose is to break people's existing code.

If you disagree with such a way of writing tests then the right solution
IMHO is to write a SLint rule.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Sven Van Caekenberghe-2
While I agree that we shouldn’t unnecessary make life more difficult for external frameworks/libraries when that can be avoided, we do have to reserve the right to be able to make changes that break things.

Like with #includesSubstring: the actual intention of the change is valid and sound, but the process could have been smoother.

Issue 11876 does have a point and it does simplify the system, IMHO.

On 24 Oct 2013, at 08:17, Philippe Marschall <[hidden email]> wrote:

> On 22.10.13 00:08, Camillo Bruni wrote:
>> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
>> it looks unsuspicous until the moment you try understand such a failing assertion.
>
> This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
>
> This only adds code who's sole purpose is to break people's existing code.
>
> If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
>
> Cheers
> Philippe
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Igor Stasenko
In reply to this post by Philippe Marschall-2



On 24 October 2013 08:17, Philippe Marschall <[hidden email]> wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
it looks unsuspicous until the moment you try understand such a failing assertion.

This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.

This only adds code who's sole purpose is to break people's existing code.

If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.


Running SLint over tests? I could agree the working code should be checked for rules.. but tests?
Useful, to some pedantic souls i guess , but not me :)

But anyways, i agree with you, we should not dictate what is 'best' rules and 'how you should do the coding',
we shall let people discover own and let them shoot into their own foot, if they insisting to.
 
Cheers
Philippe





--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Philippe Marschall-2
On 24.10.13 15:24, Igor Stasenko wrote:

>
>
>
> On 24 October 2013 08:17, Philippe Marschall
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 22.10.13 00:08, Camillo Bruni wrote:
>
>         see my long explanation here
>         https://pharo.fogbugz.com/__default.asp?11876#87218
>         <https://pharo.fogbugz.com/default.asp?11876#87218>
>         it looks unsuspicous until the moment you try understand such a
>         failing assertion.
>
>
>     This isn't moving Pharo foward. This doesn't make the system any
>     more flexible, adaptable, modular or malleable. This doesn't make
>     the system any easier to maintain. This doesn't make the system any
>     smaller, faster, scalable or secure. This doesn't make the system
>     any easier to maintain. This doesn't make life easier for anybody
>     developing Pharo or using Pharo. This doesn't improve Pharo in any way.
>
>     This only adds code who's sole purpose is to break people's existing
>     code.
>
>     If you disagree with such a way of writing tests then the right
>     solution IMHO is to write a SLint rule.
>
>
> Running SLint over tests? I could agree the working code should be
> checked for rules.. but tests?

Yes. Test should have the same quality standards as the rest of the code
because you'll have to maintain them just the same. Our tests have to be
portable like the rest of our code.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Igor Stasenko



On 24 October 2013 15:40, Philippe Marschall <[hidden email]> wrote:
On 24.10.13 15:24, Igor Stasenko wrote:



On 24 October 2013 08:17, Philippe Marschall
<[hidden email]
<mailto:[hidden email]>> wrote:

    On 22.10.13 00:08, Camillo Bruni wrote:

        see my long explanation here
        https://pharo.fogbugz.com/__default.asp?11876#87218

        <https://pharo.fogbugz.com/default.asp?11876#87218>
        it looks unsuspicous until the moment you try understand such a
        failing assertion.


    This isn't moving Pharo foward. This doesn't make the system any
    more flexible, adaptable, modular or malleable. This doesn't make
    the system any easier to maintain. This doesn't make the system any
    smaller, faster, scalable or secure. This doesn't make the system
    any easier to maintain. This doesn't make life easier for anybody
    developing Pharo or using Pharo. This doesn't improve Pharo in any way.

    This only adds code who's sole purpose is to break people's existing
    code.

    If you disagree with such a way of writing tests then the right
    solution IMHO is to write a SLint rule.


Running SLint over tests? I could agree the working code should be
checked for rules.. but tests?

Yes. Test should have the same quality standards as the rest of the code because you'll have to maintain them just the same. Our tests have to be portable like the rest of our code.


Well, if you putting such high quality standards on Seaside, then logically i would expect more understanding from your side that people here also want to have
quality standards for Pharo as well. And this issue with #shouldn't lies exactly in this plane.
Because rephrasing you, running SLint on tests << doesn't make the system any
    smaller, faster, scalable or secure. This doesn't make the system
    any easier to maintain.>>
 :)

Cheers
Philippe





--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Levente Uzonyi-2
In reply to this post by Philippe Marschall-2
On Thu, 24 Oct 2013, Philippe Marschall wrote:

> On 22.10.13 00:08, Camillo Bruni wrote:
>> see my long explanation here
>> https://pharo.fogbugz.com/default.asp?11876#87218
>> it looks unsuspicous until the moment you try understand such a failing
>> assertion.
>
> This isn't moving Pharo foward. This doesn't make the system any more
> flexible, adaptable, modular or malleable. This doesn't make the system any
> easier to maintain. This doesn't make the system any smaller, faster,
> scalable or secure. This doesn't make the system any easier to maintain. This
> doesn't make life easier for anybody developing Pharo or using Pharo. This
> doesn't improve Pharo in any way.
>
> This only adds code who's sole purpose is to break people's existing code.

<rant>
It's part of the Pharo manifesto: "Not backward compatible"
</rant>


Levente

>
> If you disagree with such a way of writing tests then the right solution IMHO
> is to write a SLint rule.
>
> Cheers
> Philippe
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Marcus Denker-4

On 24 Oct 2013, at 18:32, Levente Uzonyi <[hidden email]> wrote:

> On Thu, 24 Oct 2013, Philippe Marschall wrote:
>
>> On 22.10.13 00:08, Camillo Bruni wrote:
>>> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
>>> it looks unsuspicous until the moment you try understand such a failing assertion.
>>
>> This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
>>
>> This only adds code who's sole purpose is to break people's existing code.
>
> <rant>
> It's part of the Pharo manifesto: "Not backward compatible"
> </rant>
>

And I still think that this was the best decision we ever took. It will allow us to have a future.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Sven Van Caekenberghe-2
In reply to this post by Levente Uzonyi-2

On 24 Oct 2013, at 18:32, Levente Uzonyi <[hidden email]> wrote:

> On Thu, 24 Oct 2013, Philippe Marschall wrote:
>
>> On 22.10.13 00:08, Camillo Bruni wrote:
>>> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
>>> it looks unsuspicous until the moment you try understand such a failing assertion.
>>
>> This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
>>
>> This only adds code who's sole purpose is to break people's existing code.
>
> <rant>
> It's part of the Pharo manifesto: "Not backward compatible"
> </rant>

<annoyed>
Please go write those kind of comments on squeak-dev,
nobody from Pharo ever does this on squeak-dev, ever.
</annoyed>

>
> Levente
>
>>
>> If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
>>
>> Cheers
>> Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Stéphane Ducasse
In reply to this post by Levente Uzonyi-2
> <rant>
> It's part of the Pharo manifesto: "Not backward compatible"
> </rant>

Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point.
But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious
If I can laugh from them this is that I should be quite strong no?

We are all committed to build a robust and clean system that people can use to
create their own wealth and feed their family. We are
making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
It is not easy but people like marcus, sven, esteban, igor, camillo and many many others
are dedicated to that goal.
All the rest does not matter :)

I'm just sad that other smart people do not understand that we want to create a future to everybody not just
a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future.
Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it
and I thank them for that.

Stef


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Levente Uzonyi-2
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:

>> <rant>
>> It's part of the Pharo manifesto: "Not backward compatible"
>> </rant>
>
> Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point.
> But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious
> If I can laugh from them this is that I should be quite strong no?

I'm sorry if you guys didn't get my message, but it was as serious as it
could be. I understand that you don't what to be backwards compatible,
because it makes it easier to change stuff.
As I see, people need various levels of backwards compatibility. Currently
the package maintainers are the most affected, who would like to provide
the same codebase for various versions of Pharo, and/or other Smalltalk
dialects.
As time passes, and the number of users increases, you'll have to give in,
and provide it some way.

>
> We are all committed to build a robust and clean system that people can use to
> create their own wealth and feed their family. We are
> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.

I'm not following the developement of Pharo closely anymore, mainly
because it's not transparent enough for my taste. I see that you're making
big changes, but I still haven't seen the breakthrough: I don't see the
advantage of using Pharo over another open source Smalltalk dialect, from
business point of view.


Levente

> It is not easy but people like marcus, sven, esteban, igor, camillo and many many others
> are dedicated to that goal.
> All the rest does not matter :)
>
> I'm just sad that other smart people do not understand that we want to create a future to everybody not just
> a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future.
> Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it
> and I thank them for that.
>
> Stef
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Stéphane Ducasse

> I'm sorry if you guys didn't get my message, but it was as serious as it could be.

Ok fair :)

> I understand that you don't what to be backwards compatible, because it makes it easier to change stuff.
> As I see, people need various levels of backwards compatibility.

Indeed but the right level is important ;)
I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages
so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW)

> Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects.

there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in
a system slowly improving. I can control when I want to migrate my apps.

> As time passes, and the number of users increases, you'll have to give in, and provide it some way.

What I was thinking for example (and I will build it) is an automatic stub creation to support the
loading of package where a class is missing in the existing system.
I also love the evolution analysis made by andre that generates rules to check migration
we should add automatic code transformation. I would like to keep refactoring that we can apply
when people want to migrate. And we will get there because we start to have a good infrastructure.
So once the infrastructure does not suck all our time then we will build the next generation tools.
And this is starting :)


>> We are all committed to build a robust and clean system that people can use to
>> create their own wealth and feed their family. We are
>> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
>
> I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste.
You will complain about the fogbuz stuff and we will answer that we hate that google forced us
to move. And this is like that.

> I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view.

It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http
server and many more is enough. And in addition the consortium means that slowly
we will give an autonomous live to Pharo not based on free time of people.

Stef


Reply | Threaded
Open this post in threaded view
|

Re: Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

Levente Uzonyi-2
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:

>
>> I'm sorry if you guys didn't get my message, but it was as serious as it could be.
>
> Ok fair :)
>
>> I understand that you don't what to be backwards compatible, because it makes it easier to change stuff.
>> As I see, people need various levels of backwards compatibility.
>
> Indeed but the right level is important ;)
> I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages
> so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW)
That's nice, but AFAIK Moose is Pharo-only, so you only have to follow
your own changes.

>
>> Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects.
>
> there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in
> a system slowly improving. I can control when I want to migrate my apps.

This is where the level of backwards compatibility comes into the picture.
For example the official release of Seaside is still based on Pharo 1.3,
and the reason for that is the frequent changes of core functionality.

>
>> As time passes, and the number of users increases, you'll have to give in, and provide it some way.
>
> What I was thinking for example (and I will build it) is an automatic stub creation to support the
> loading of package where a class is missing in the existing system.

I don't see how this is benefical, or how it addresses the increasing
demand for backwards compatibility.

> I also love the evolution analysis made by andre that generates rules to check migration
> we should add automatic code transformation. I would like to keep refactoring that we can apply
> when people want to migrate. And we will get there because we start to have a good infrastructure.
> So once the infrastructure does not suck all our time then we will build the next generation tools.
> And this is starting :)
>
>
>>> We are all committed to build a robust and clean system that people can use to
>>> create their own wealth and feed their family. We are
>>> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
>>
>> I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste.
> You will complain about the fogbuz stuff and we will answer that we hate that google forced us
> to move. And this is like that.
Well, fogbugz is just part of it, and somewhat less important than actual
code changes.
There are two kind of diffs posted to this mailing list. One for the
changes on smalltalkhub, and the other is from github. The latter is
totally useless, because it contains no code, just the name of the methods
in the changed packages. The former is totally broken, because
smalltalkhub can't create the diff, if the direct ancestor of the package
is missing, and in 90%+ of the cases, you jump more than one mcz versions.

>
>> I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view.
>
> It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http
> server and many more is enough. And in addition the consortium means that slowly
> we will give an autonomous live to Pharo not based on free time of people.

I can only repeat myself; these changes are great, but it's not a
breakthrough.


Levente

>
> Stef
>
>
>
12