On 3 sept. 2014, at 17:26, Eliot Miranda <[email protected]> wrote:

> 
> 
> 
> On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier <[email protected]> 
> wrote:
> 
> 
> 
> 2014-09-03 14:40 GMT+02:00 Marcus Denker <[email protected]>:
> 
> with:do: on SequencableCollection checks that both collections have the same 
> size (it raises an Error if not).
> 
> with: otherCollection do: twoArgBlock
>     "Evaluate twoArgBlock with corresponding elements from this collection 
> and otherCollection."
>     otherCollection size = self size ifFalse: [self error: 'otherCollection 
> must be the same size'].
>     1 to: self size do:
>         [:index |
>         twoArgBlock value: (self at: index)
>                 value: (otherCollection at: index)]
> 
> I think we should not do that:
> 
> 1) it is slow
> 
> Are you sure about that one? The check is a constant cost disregarding the 
> collection length, and, anyway, self size is reused just after that.
>  
> 2) when the other is larger, is would work and just omit the rest 
> 3) if it is smaller, you will get an error anyway
> 
> I have a feeling I'm not in Pharo anymore, but in R instead ;)
> 
> +2.  There are clear safety advantages in the check.  If you want the 
> "faster" protocol why not define withSomeOf:do: or some such?

Like Thierry I'm not sure that omitting the check brings a significant speedup.
However, not doing this check follows the robustness principle: "Be 
conservative in what you do, be liberal in what you accept from others". 
I would even be more liberal with a: 
1 to: (self size min: otherCollection size) do: ....
:)

>  
> Thierry 
>  
> 
> There are just three methods doing such a size check:
> 
> with:do:
> with:collect:
> reverseWith:do:
> (the last one actually raises a         SizeMismatch exception, it is the 
> sole user of that exception)
> 
> Is there a reason why this makes sense?
> 
> I added an issue with a slice to clean it up:
> 
> https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size
> 
>         Marcus
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> best,
> Eliot

Reply via email to