[haiku-development] Re: RFC: BDataIO::Print(), PrintToStream(BDataIO&)

-------- Original-Nachricht --------
> Datum: Tue, 30 Jun 2009 13:04:15 +0200 CEST
> Von: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>

> "Ingo Weinhold" <ingo_weinhold@xxxxxx> wrote:
> > > That could also be solved by a BFormattedIO class that you can wrap 
> > > around any other class.
> > > If one would also add parsing functionality, I think this would be 
> > > the 
> > > preferred way to go.
> > I thought about that too and, since Java uses a somewhat similar 
> > design
> > (PrintWriter/PrintStream), I thought about it some more. I just can't 
> > see any
> > advantage to this approach, while it has the obvious disadvantage 
> > that useful
> > facilities from the derived classes cannot be used. E.g. BFileIO 
> > overrides
> > VPrint() to make use of vfprintf(). The base class implementation 
> > (respectively
> > a BFormattedIO class) has to resort to vsnprintf() and a limited 
> > static buffer.
> 
> While that is true, it's also a rare case; ie. only BFileIO would have 
> that ability.

Which in turn would be well-used though (e.g. in PrintToStream()).

> But if you prefer that solution, I'm not really against it either.

My most-favored option would be introducing a BPrintOutput. That would also 
allow debug_printf() and ktrace_printf() as backends. In fact using 
debug_printf() for PrintToStream() was what I originally needed, though BFile 
and "/dev/dprintf" have the same effect.

Come to think of it, having a BFilePrintOutput with FILE* and vfprintf() as 
backend would also make introducing the [V]Print() in BDataIO unnecessary, 
since then a BFormattedIO would only need to be used for the cases where an 
optimization isn't possible anyway.

> Where would you put functions like (endian-safe) {Read|Write}Int32() 
> in? Also in BDataIO?

That depends on where this interface is going. If we also intend to write more 
complex objects, a BObjectIO wrapper that provides the functionality would be 
the way to go, IMO.

> > What would make sense IMHO is to pull Print() and VPrint() into an 
> > abstract
> > base class -- let's call it BPrintOutput -- to allow for greater 
> > flexibility (the
> > PrintToStream() methods would get such an object instead of a 
> > BDataIO).
> > For above reasons I would still derive BDataIO directly from it, 
> > though.
> 
> Not sure what binary compatibility would say about that :-)

Something like "Argh! Oh no!" I suppose. :-)

> > > > * Added experimental BFdIO and BFileIO, which are BPositionIO 
> > > > implementations wrapping a given file descriptor respectively 
> > > > FILE*.
> > > I don't like the BFdIO name, but I don't have a good idea for a 
> > > replacement either -
> > If it's just the name, Stippi's proposed BDescriptorIO sounds good to 
> > me.
> 
> Rene's suggestion, but yes, I like that, too.

Oh, sorry Rene! I blame it on the somewhat uncomfortable web mail I use under 
Haiku. :-)

[...]
> > > I think we could also add the Meta{Read|Write|...}() functions to 
> > > BDataIO, they should be useful, too.
> > Deja vu... ;-)
> 
> We still haven't added them yet, haven't we? ;-)

Yeah, someone keeps mentioning it every few years, though. :-)

CU, Ingo

Other related posts: