Re: [Pharo-dev] ifError: implementation is bad

> On 12 ene 2016, at 8:53 p.m., stepharo wrote: > > > +^111 >> >> 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 lan

Re: [Pharo-dev] ifError: implementation is bad

+^111 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

Re: [Pharo-dev] ifError: implementation is bad

On Mon, Jan 11, 2016 at 11:52 PM, Guillermo Polito wrote: > > On 11 ene 2016, at 2:19 p.m., Denis Kudriashov wrote: > > > 2016-01-10 21:29 GMT+01:00 stepharo : >>> >>> Especially it is commonly used scenario by senders of >>> #critical:ifError:. But it is different question. >>> I propose change

Re: [Pharo-dev] ifError: implementation is bad

> On 11 ene 2016, at 2:19 p.m., Denis Kudriashov wrote: > > > 2016-01-10 21:29 GMT+01:00 stepharo >: > Especially it is commonly used scenario by senders of #critical:ifError:. > But it is different question. > I propose change ifError: to cull error instance. > > W

Re: [Pharo-dev] ifError: implementation is bad

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 totally agreed :)

Re: [Pharo-dev] ifError: implementation is bad

2016-01-10 21:29 GMT+01:00 stepharo : > 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 di

Re: [Pharo-dev] ifError: implementation is bad

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? Stef

Re: [Pharo-dev] ifError: implementation is bad

But it is too long. ifError: is very intuitive name. Not to me. Stef

Re: [Pharo-dev] ifError: implementation is bad

2016-01-08 21:30 GMT+01:00 stepharo : > 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. > But it is too long. ifError: is very intuitive name.

Re: [Pharo-dev] ifError: implementation is bad

2016-01-08 21:17 GMT+01:00 Juraj Kubelka : > Hi, > > 8. 1. 2016 v 17:11, Tudor Girba : > > > 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

Re: [Pharo-dev] ifError: implementation is bad

2016-01-08 21:11 GMT+01:00 Tudor Girba : > 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

Re: [Pharo-dev] ifError: implementation is bad

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 : Hi, Denis says that right now, to use ifError: you do: [...] ifError: [:msg :rcv | … ] a

Re: [Pharo-dev] ifError: implementation is bad

Hi, 8. 1. 2016 v 17:11, Tudor Girba : > 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

Re: [Pharo-dev] ifError: implementation is bad

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 i

Re: [Pharo-dev] ifError: implementation is bad

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

Re: [Pharo-dev] ifError: implementation is bad

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

Re: [Pharo-dev] ifError: implementation is bad

2016-01-07 13:35 GMT+01:00 Sven Van Caekenberghe : > If think it makes more sense to #cull: the exception instance, it is more > object oriented We all know it. But then we found such methods in the system and cry :). who can wrote it

Re: [Pharo-dev] ifError: implementation is bad

> On 07 Jan 2016, at 13:11, Denis Kudriashov 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: erro

[Pharo-dev] ifError: implementation is bad

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 descri