[squeak-dev] The Trunk: Kernel-eem.1117.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Nov 11 09:23:49 UTC 2017


2017-11-11 9:24 GMT+01:00 Tobias Pape <Das.Linux at gmx.de>:

>
> > On 11.11.2017, at 08:59, Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> > Interestingly, the streaming thing is more natural to me here than the
> make-array-and-put.
> > Some people I asked agree, some don't. Seemed to correlate with age,
> tho… ;P
>
> Should have said "correlate with what people where exposed first to", sorry
>
>
:)
Logically, punching cards should help developping a taste for an economy.
Unfortunately, it was just an economy of punch...
Maybe that's why we like those short words, to:, do:, at:


> Best regards
> >       -Tobias
> >
> >> On 11.11.2017, at 02:31, Chris Muller <asqueaker at gmail.com> wrote:
> >>
> >> I get what you're saying.  It's not _necessary_ to introduce any
> >> streaming concepts into this.  Very good point.
> >>
> >> On Fri, Nov 10, 2017 at 1:00 AM, Nicolas Cellier
> >> <nicolas.cellier.aka.nice at gmail.com> wrote:
> >>> But old implementation was a to:do: loop on indices with (self tempAt:
> i)
> >>> So we already pay the price of low level procedural style,
> >>> why having to pay the stream overhead?
> >>> It makes code more convoluted than necessary (a higher level dsiguise)
> >>>
> >>> Or should we rewrite most of SequenceableCollection protocol?
> >>>
> >>> 2017-11-10 2:55 GMT+01:00 Chris Muller <asqueaker at gmail.com>:
> >>>>
> >>>> +1.  #streamContents: is a high-level message.
> >>>>
> >>>> Eliot is a master of C programming, I guess we all see our own style
> >>>> as less baroque.  I generally try to retain original authors' style
> >>>> and formatting  as much as possible unless I'm making significant
> >>>> changes to the method.  I would never only replace someone's
> >>>> formatting or style with my own.
> >>>>
> >>>>
> >>>> On Tue, Nov 7, 2017 at 11:58 PM, Tobias Pape <Das.Linux at gmx.de>
> wrote:
> >>>>>
> >>>>>> On 08.11.2017, at 02:11, commits at source.squeak.org wrote:
> >>>>>>
> >>>>>> Eliot Miranda uploaded a new version of Kernel to project The Trunk:
> >>>>>> http://source.squeak.org/trunk/Kernel-eem.1117.mcz
> >>>>>>
> >>>>>> ==================== Summary ====================
> >>>>>>
> >>>>>> Name: Kernel-eem.1117
> >>>>>> Author: eem
> >>>>>> Time: 7 November 2017, 5:11:32.043344 pm
> >>>>>> UUID: 110255e1-5b72-4d99-96bb-e5068c2f5b5b
> >>>>>> Ancestors: Kernel-tpr.1116
> >>>>>>
> >>>>>> Use a slightly less baroque implemetation for Context>>arguments,
> >>>>>> equivalent to Pharo's.
> >>>>>>
> >>>>>
> >>>>> What is baroque about that?
> >>>>> I'd prefer the other stile any time.
> >>>>> I especially find the assignment in the "computation" of the argument
> >>>>> ugly (the n assignment) and potentially confusing.
> >>>>>
> >>>>> I'm a bit puzzled you prefer the style you just put there to the
> >>>>> streaming constructor…
> >>>>>
> >>>>> Best regards
> >>>>>       -Tobias
> >>>>>
> >>>>>> =============== Diff against Kernel-tpr.1116 ===============
> >>>>>>
> >>>>>> Item was changed:
> >>>>>> ----- Method: Context>>arguments (in category 'accessing') -----
> >>>>>> arguments
> >>>>>> +     "Answer the receiver's arguments as an Array.
> >>>>>> +      We could use simply ^(1 to: self numArgs) collect: [:i| self
> >>>>>> tempAt: i]
> >>>>>> +      but for performance and minimality we use the implementation
> >>>>>> below."
> >>>>>> +     | n args |
> >>>>>> +     args := Array new: (n := self numArgs).
> >>>>>> +     1 to: n do: [:i| args at: i put: (self tempAt: i)].
> >>>>>> +     ^args!
> >>>>>> -
> >>>>>> -     ^ Array new: self numArgs streamContents: [:args |
> >>>>>> -             1 to: self numArgs do: [: i |
> >>>>>> -                     args nextPut: (self tempAt: i)]]!
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171111/ed5e1e84/attachment.html>


More information about the Squeak-dev mailing list