Hi I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it. BlockClosure>>ifError: errorHandlerBlock ^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver] Why people doing that? Many users of it just pass given error like [...] ifError: [:msg :rcv | ... rcv error: msg]. Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance. What you think? Can be put it in Pharo 5? Such change can touch some packages
On 07 Jan 2016, at 13:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ... rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question.
I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
If think it makes more sense to #cull: the exception instance, it is more object oriented. And it is what I would expect.
Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis? Stef Le 7/1/16 13:11, Denis Kudriashov a écrit :
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ...
rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
Hi, Denis says that right now, to use ifError: you do: [...] ifError: [:msg :rcv | ⦠] and he would like to write this: [...] ifError: [:error | ⦠] I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly. Does it make more sense now? Or did I get it wrong? Cheers, Doru
On Jan 8, 2016, at 10:05 PM, stepharo <stepharo@free.fr> wrote:
Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis?
Stef
Le 7/1/16 13:11, Denis Kudriashov a écrit :
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ... rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question.
I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
-- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
Hi, 8. 1. 2016 v 17:11, Tudor Girba <tudor@tudorgirba.com>:
Hi,
Denis says that right now, to use ifError: you do:
[...] ifError: [:msg :rcv | ⦠]
and he would like to write this:
[...] ifError: [:error | ⦠]
But for this we have on:do: message, right? Do we need ifError:? Cheers, Juraj
I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly.
Does it make more sense now? Or did I get it wrong?
Cheers, Doru
On Jan 8, 2016, at 10:05 PM, stepharo <stepharo@free.fr> wrote:
Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis?
Stef
Le 7/1/16 13:11, Denis Kudriashov a écrit :
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ... rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question.
I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
Indeed people like to play with better API and sometimes this is not better. I prefer on:do: because like that I know that this is about Exception handling. Stef
Hi,
8. 1. 2016 v 17:11, Tudor Girba <tudor@tudorgirba.com>:
Hi,
Denis says that right now, to use ifError: you do:
[...] ifError: [:msg :rcv | ⦠]
and he would like to write this:
[...] ifError: [:error | ⦠] But for this we have on:do: message, right? Do we need ifError:?
Cheers, Juraj
I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly.
Does it make more sense now? Or did I get it wrong?
Cheers, Doru
On Jan 8, 2016, at 10:05 PM, stepharo <stepharo@free.fr> wrote:
Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis?
Stef
Le 7/1/16 13:11, Denis Kudriashov a écrit :
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ... rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question.
I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages -- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
2016-01-08 21:17 GMT+01:00 Juraj Kubelka <juraj.kubelka@icloud.com>:
Hi,
8. 1. 2016 v 17:11, Tudor Girba <tudor@tudorgirba.com>:
Hi,
Denis says that right now, to use ifError: you do:
[...] ifError: [:msg :rcv | ⦠]
and he would like to write this:
[...] ifError: [:error | ⦠]
But for this we have on:do: message, right? Do we need ifError:?
It is nice convenient method for the case when you don't care what exact error happens. It is very useful for scripting. sum := 0. #(1 asd 4534 5423 sdfs) do: [:each | [sum := sum + each] ifError: []] Actually I never use argument version of block. But it definitely should be error instance and not of one of it properties.
2016-01-08 21:11 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Denis says that right now, to use ifError: you do:
[...] ifError: [:msg :rcv | ⦠]
and he would like to write this:
[...] ifError: [:error | ⦠]
I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly.
Does it make more sense now? Or did I get it wrong?
Exactly Tudor. My cry was about why man who implement it decides to deincapsulate error state.
In general I do not like cull: and I'm really suspicious about its use. It often reveals a lack of coherence and/or design. Why this is not simply BlockClosure>>ifError: errorHandlerBlock ^ self on: Error do: errorHandlerBlock ??
Hi
I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it.
BlockClosure>>ifError: errorHandlerBlock
^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver]
Why people doing that? Many users of it just pass given error like
[...] ifError: [:msg :rcv | ...
rcv error: msg].
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
2016-01-10 21:29 GMT+01:00 stepharo <stepharo@free.fr>:
Especially it is commonly used scenario by senders of #critical:ifError:.
But it is different question. I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
So did you fix it?
Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages
On 11 ene 2016, at 2:19 p.m., Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-01-10 21:29 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages So did you fix it?
Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages
+1111^1111111 We should make a list. Some that should be easy: - Delay should be splitted - Chronology should be splitted One more complicated: - InstructionClient and InstructionStream should be splitted And then, we should also review the API of basic objects Object methods size => 385 Integer methods size => 182 ...
On Mon, Jan 11, 2016 at 11:52 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
On 11 ene 2016, at 2:19 p.m., Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-01-10 21:29 GMT+01:00 stepharo <stepharo@free.fr>:
Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance.
What you think? Can be put it in Pharo 5? Such change can touch some packages
So did you fix it?
Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages
+1111^1111111
We should make a list. Some that should be easy:
- Delay should be splitted
I'll do Delay. I'm in the middle of cleaning it bit atm. https://pharo.fogbugz.com/default.asp?17375 cheers -ben
- Chronology should be splitted
One more complicated:
- InstructionClient and InstructionStream should be splitted
And then, we should also review the API of basic objects
Object methods size => 385 Integer methods size => 182 ...
+1111^1111111
We should make a list. Some that should be easy:
- Delay should be splitted
why?
- Chronology should be splitted
One more complicated:
- InstructionClient and InstructionStream should be splitted
And then, we should also review the API of basic objects
Object methods size => 385 Integer methods size => 182 ...
On 12 ene 2016, at 8:53 p.m., stepharo <stepharo@free.fr> wrote:
+1111^1111111
We should make a list. Some that should be easy:
- Delay should be splitted
why?
First, I mean Delay, not processes. Processes are required for executing code, delays are not. I believe that Delay is not a language kernel concern. It is an important concern but not a Kernel one. Also, - the biggest it is the Kernel package, the more difficult it is to analyze dependencies (because everything depends on kernel so who would care, no?) - I could imagine little images that do not contain delay, because they do not use it. Of course, it is not the typical Pharo distribution but it is a possible case. I only say that having it in a separate package is worth it. Check senders of wait, you will see that the usages inside the kernel are really few: mainly BlockClosures implementing things like #valueAndWait and Delay tests.
- Chronology should be splitted
One more complicated:
- InstructionClient and InstructionStream should be splitted
And then, we should also review the API of basic objects
Object methods size => 385 Integer methods size => 182 ...
participants (8)
-
Ben Coman -
Denis Kudriashov -
Guillermo Polito -
Juraj Kubelka -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Tudor Girba