On 10/13/06, Wilson Bilkovich <wilsonb / gmail.com> wrote:
> On 10/13/06, Brian Mitchell <binary42 / gmail.com> wrote:
> > On 10/13/06, Brian Mitchell <binary42 / gmail.com> wrote:
> > > On 10/13/06, Tim Bray <tbray / textuality.com> wrote:
> > > > unpack doesn't seem to take a block.  This seems like an obvious
> > > > thing to want if I'm going to work with a big input string and not
> > > > burn memory.  Am I missing something? -Tim
> > >
> > > Possibly a good idea. Lets go ahead and try it out.
> > >
> > > class String
> > >   def unpack_each(format)
> >
> >  On second thought... each_unapck is a much better name.
>
> Shouldn't it just be 'unpack', and have some 'if block_given?' juice
> squeezed on it?

Not when I am monkey patching [1] like this. If I felt like writing a
worthwhile implementation... then that might happen. I am an advocate
of intelligent interfaces but I am also an advocate of avoiding too
many invasive changes when they really aren't needed. It is perfectly
sensible to play around with this using a name each_unpack.

And it is a sort of iteration... like each_line and each_byte, we get
repeated results from a sort of scan like transformation process. Each
series of unpacked array.. I think it fits.

Anyway.. I sound like a broken record. Just woke up from the aftermath
of an 8 hour long party at my apartment here in NYC. ;-)

Brian.

[1] I have no problem reopening classes but when I override something
I always take great care to minimize change. If this is so great, we
could merge the idea into ruby's code base and call it standard.