[ruby-talk:8466] Re: string like istringstream (was: A bug inruby)

Hello --

On Tue, 2 Jan 2001, Jean Michel wrote:

> In article <[e-mail]>,
> David Alan Black  <[e-mail]> wrote:
> >
> >Wouldn't it be better, if the pointer is < length, to return what's
> >left of the string, even if pointer + n >= length?  Something like:
> >
> >     def read(n)
> >       @pos += n
> >       res = self[@pos - n .. @pos - 1]
> >       @pos = length if @pos > length
> >       res
> >     end
> >
> >In your version, if you start reading inside the string but go past
> >the end, you get nil (instead of the end of the string).  
> >
> >(I like @pos better than @current_pointer, because it's shorter, still
> >readable, and similar to IO#pos.)
> 
> It is not  a matter of 'better'  but to follow exactly  the semantics of
> IO::read . It was my understanting that if the required amount could not
> be read,  the result  is nil.  If I am  wrong my  code should  change of
> course. Similarly,  since as you  pointed IO uses  @pos I should  do the
> same and change my variable name as you recommend.

"Better" specifically in the sense of "more similar to IO::read" :-)
I'd actually included this and then taken it out for brevity:

   irb 1> fh = File.open("/tmp/4list")  # 50K chars
      ==>#<File:0x401abee8>
   irb 2> fh.pos = 49999
      ==>0
   irb 3> fh.read 100
      ==>"\n"
   irb 4> fh.pos = 49999
      ==>0
   irb 5> fh.read 1
      ==>"\n"


> >My main suggestion would be to think about some refactoring, such that
> >the following code (or something like it) would work:
> >
> >   Dir["*.mp3"].each{ |f|
> >     print "\n{#{f}}\n"
> >     tag = ID3V2Tag.new
> >     tag.get_from_stream(open(f, "rb"))
> 
> You might get unpleasantness elsewhere. For instance, my routine
> .read_ID3V2tag signals by returning nil that no tag was found. How do you
> propose to handle that in your version? 

I wouldn't credit myself with a real version... but anyway, presumably
whatever method was looking for a tag could return nil if one isn't
found.  (The above dummy snippet does not test for this.)

> >As per my previous post, I find it sort of lop-sided to put the
> >knowledge of these tags in the String and IO classes.
> 
> I  think it  wonderful  that ruby  allows to  re-open  and extend  basic
> classes. I  do not  find it  lop-sided. Maybe you  feel this  because it
> would be impossible in other languages.

No, it's not a general concern with extending basic classes.  (We all
love *that*! :-)  It comes down to this: if you encapsulate Tag
knowledge in the Tag code, then your Tag code can, without
modification, handle any object which seeks and reads.  But if you
have to tell your Tag code exactly which types of objects seek and
read, then if that ever changes, you have to manually update the list.

(I'm not sure, in this case, what those new object types would be, so
perhaps I'm applying a general principle too rigidly....  But I still
would prefer not having to manually keep track of all the seekable
objects.)

Also, if in a larger program you were dealing with a number of
different types (not just tags), and if you took the general approach
of extending basic classes, one by one, to include knowledge of those
types, I think it could become very hard to maintain, and to manage
namespaces.  Class String, for example, might end up with methods
called read_ID3V2_tag, read_XYZ_entry, read_ABC_header, etc.  That's
the lop-sided part (to me).  One could end up using method names to
re-encapsulate functionality.


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav