<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-11-10 10:53 GMT+01:00 Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 10.11.2017, at 08:00, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@<wbr>gmail.com</a>> wrote:<br>
><br>
> But old implementation was a to:do: loop on indices with (self tempAt: i)<br>
> So we already pay the price of low level procedural style,<br>
> why having to pay the stream overhead?<br>
> It makes code more convoluted than necessary (a higher level dsiguise)<br>
><br>
> Or should we rewrite most of SequenceableCollection protocol?<br>
><br>
<br>
</span>I don't get it.<br>
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888">        -Tobias<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Hi Tobias,<br></div><div>I say that the main interest of stream is to release you from direct index manipulation</div><div>which are considered as lower level implementation details</div><div><br></div><div>The code below is just doing a copy.</div><div>It was done with low level index iteration on one side for reading,</div><div>and invoking higher level stream on the other side for writing,</div><div>despite the fact that the low level indices would perfectly match...</div><div><br></div><div>We are thus complexifying the code un-necessarily by using two concepts where a single one would have been enough.</div><div>Incidentally, code was less efficient, but I don't know if we ever have to care (maybe Eliot cares for VM simulation).</div><div><br></div><div>So that's why I call this a higher level disguise: it's fake since we continue manipulating low level indices.<br></div><div><br></div><div>SequenceableCollection if full of those low level iterations on indices, but there it's mainly for the sake of speed/efficiency.</div><div><br></div><div> If we have to conceptualize every 4 liners like that, Squeak is really going to be conservative ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> 2017-11-10 2:55 GMT+01:00 Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>>:<br>
> +1.  #streamContents: is a high-level message.<br>
><br>
> Eliot is a master of C programming, I guess we all see our own style<br>
> as less baroque.  I generally try to retain original authors' style<br>
> and formatting  as much as possible unless I'm making significant<br>
> changes to the method.  I would never only replace someone's<br>
> formatting or style with my own.<br>
><br>
><br>
> On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
> ><br>
> >> On 08.11.2017, at 02:11, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
> >><br>
> >> Eliot Miranda uploaded a new version of Kernel to project The Trunk:<br>
> >> <a href="http://source.squeak.org/trunk/Kernel-eem.1117.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/<wbr>trunk/Kernel-eem.1117.mcz</a><br>
> >><br>
> >> ==================== Summary ====================<br>
> >><br>
> >> Name: Kernel-eem.1117<br>
> >> Author: eem<br>
> >> Time: 7 November 2017, 5:11:32.043344 pm<br>
> >> UUID: 110255e1-5b72-4d99-96bb-<wbr>e5068c2f5b5b<br>
> >> Ancestors: Kernel-tpr.1116<br>
> >><br>
> >> Use a slightly less baroque implemetation for Context>>arguments, equivalent to Pharo's.<br>
> >><br>
> ><br>
> > What is baroque about that?<br>
> > I'd prefer the other stile any time.<br>
> > I especially find the assignment in the "computation" of the argument ugly (the n assignment) and potentially confusing.<br>
> ><br>
> > I'm a bit puzzled you prefer the style you just put there to the streaming constructor…<br>
> ><br>
> > Best regards<br>
> >         -Tobias<br>
> ><br>
> >> =============== Diff against Kernel-tpr.1116 ===============<br>
> >><br>
> >> Item was changed:<br>
> >>  ----- Method: Context>>arguments (in category 'accessing') -----<br>
> >>  arguments<br>
> >> +     "Answer the receiver's arguments as an Array.<br>
> >> +      We could use simply ^(1 to: self numArgs) collect: [:i| self tempAt: i]<br>
> >> +      but for performance and minimality we use the implementation below."<br>
> >> +     | n args |<br>
> >> +     args := Array new: (n := self numArgs).<br>
> >> +     1 to: n do: [:i| args at: i put: (self tempAt: i)].<br>
> >> +     ^args!<br>
> >> -<br>
> >> -     ^ Array new: self numArgs streamContents: [:args |<br>
> >> -             1 to: self numArgs do: [: i |<br>
> >> -                     args nextPut: (self tempAt: i)]]!<br>
> >><br>
> >><br>
> ><br>
> ><br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>