BinaryWriter/Reader question

[Guest]

Re: BinaryWriter/Reader question


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1b2321 83e159a7c998aa7 6@msnews.micros oft.com...[color=blue]
> <pdavis68@hotma il.com> wrote:[/color]
[snip (trying to keep these messages manageable)][color=blue][color=green]
> > I guess in this case, it helps to know what's going on underneath, but I
> > would infer that the fact that Dispose() is implemented this way and
> > furthermore, that Dispose() isn't even documented for the BinaryWriter
> > that calling Dispose() on the BinaryWriter is probably not always a good[/color][/color]
idea.[color=blue]
>
> It's not *always* a good idea (as in this case) but I believe that when
> you know the lifetime of the stream as well, it's a good idea, just
> going along with the idea that it implements IDisposable for a reason.
>
> BinaryWriter.ID isposable.Dispo se actually *is* documented, but as "This
> member supports the .NET Framework infrastructure and is not intended
> to be used directly from your code." I think this is a *big* mistake,
> and breaks the whole idea of interfaces.
>[/color]

Yes, but wouldn't the idea that they've chosen to implement it as an
explicit interface hint that it shouldn't be used by user's code? So isn't
the documentation simply confirming that?

BTW, you must be using different documentation. My MSDN (Jan 2004) only
shows the protected Dispose(bool).
[color=blue][color=green]
> > Besides, all it does is close the Stream which is going to happen[/color][/color]
anyway.[color=blue]
>
> It's going to happen at *some* stage, sure. I just think that getting
> into the habit of disposing of objects which implement IDisposable and
> thinking about the consequences of doing so is a good habit to get
> into.
>[/color]

Well, I think all this explicit implementation stuff simply adds a layer of
complexity that is more annoying than helpful. I'm all for simplifying as
much as possible. I figure if you don't want people to call a method, then
you shouldn't implement it in a callable fashion (i.e. make it private and
don't do it as part of the IDisposable interface to begin with).

I mean, you're right, if they implement IDisposable, then I should be
expected to call Dispose(), but they're kind of saying not to do it. I mean,
that's kind of stupid, in my mind. And in this case, it could have
unintended consequences for the user. It screams out bad design somewhere.
[color=blue][color=green]
> > But again, without knowing the underlying implementation and without it
> > being documented, this wouldn't be known (except for the fact that
> > unobfuscated code is so easy to reverse engineer in .NET).
> >
> > Actually, I have never used "using" except for accessing namespaces
> > myself. I don't doubt its usefulness nor its readability. Simply
> > haven't adopted it as part of my programming style.... yet....[/color]
>
> I would seriously consider doing so in the *very* near future. Are you
> currently closing streams etc in finally blocks? If not, you're risking
> problems if an exception is thrown. If you are, then your code would
> become more readable immediately by using the using statement.
>[/color]

I'm big on try/finally I don't know why. It adds an extra layer of
indentation and yeah, it's kind of ugly. I just kind of got started that
way (probably some book I read early on in my C# programming) and have been
doing it ever since. What can I say? Habits are hard to break.

Pete

[Justin Rogers]

Re: BinaryWriter/Reader question

> Well, I think all this explicit implementation stuff simply adds a layer of[color=blue]
> complexity that is more annoying than helpful. I'm all for simplifying as
> much as possible. I figure if you don't want people to call a method, then
> you shouldn't implement it in a callable fashion (i.e. make it private and
> don't do it as part of the IDisposable interface to begin with).
>
> I mean, you're right, if they implement IDisposable, then I should be
> expected to call Dispose(), but they're kind of saying not to do it. I mean,
> that's kind of stupid, in my mind. And in this case, it could have
> unintended consequences for the user. It screams out bad design somewhere.[/color]

They are using explicit binding so they can maintain functionality with C# to
avoid a common programming mistake of not closing an underlying object.
Explicit binding is chosen in this case so that they can rename the API that
you actually should be calling to shut-down a BinaryWriter and that is the
Close method.

You'll notice that both the public virtual Close and protected virtual
Dispose(bool)
share something in common. They are both virtual, and you could easily
write your own wrappers that disabled the shut-down of the underlying
stream. If this is the case, why implement IDisposable in the first case, well
we
are right back to C# and avoiding common programming mistakes. The Mort
user needs stuff cleaned up because they do things like lose the original stream
in calls such as:

new BinaryWriter(Fi le.OpenText(... ));

Simple as that. Confuses seasoned programmers, might not be the best way to
go, but there are more Mort's out there than the 2 E's.
[color=blue]
> I'm big on try/finally I don't know why. It adds an extra layer of
> indentation and yeah, it's kind of ugly. I just kind of got started that
> way (probably some book I read early on in my C# programming) and have been
> doing it ever since. What can I say? Habits are hard to break.[/color]

The reason for the using statement is to gain the extra changes that the keyword
may or may not allow in the future. If you read the C# Team/FAQ blog then
you'll
realize there are some performance changes for the using statement that you
might
want to take advantage of, and some logic that they automatically build in based
on
compile time checks. I'll add that you can easily do this yourself in your own
optimized try/finally, but it actually saves you a bunch of work in the long run
and
makes your code more compatible with types that you don't own and ensures that
your code will easily compile on future versions of .NET.


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

[Jon Skeet [C# MVP]]

Re: BinaryWriter/Reader question

<pdavis68@hotma il.com> wrote:[color=blue][color=green]
> > BinaryWriter.ID isposable.Dispo se actually *is* documented, but as "This
> > member supports the .NET Framework infrastructure and is not intended
> > to be used directly from your code." I think this is a *big* mistake,
> > and breaks the whole idea of interfaces.[/color]
>
> Yes, but wouldn't the idea that they've chosen to implement it as an
> explicit interface hint that it shouldn't be used by user's code? So isn't
> the documentation simply confirming that?
>
> BTW, you must be using different documentation. My MSDN (Jan 2004) only
> shows the protected Dispose(bool).[/color]

Where are you looking? If you look down the index, typing BinaryWriter,
it shows BinaryWriter.ID isposable.Dispo se on my box between Flush and
Null. I'm using Jan 2004 too.
[color=blue][color=green][color=darkred]
> > > Besides, all it does is close the Stream which is going to happen
> > > anyway.[/color]
> >
> > It's going to happen at *some* stage, sure. I just think that getting
> > into the habit of disposing of objects which implement IDisposable and
> > thinking about the consequences of doing so is a good habit to get
> > into.[/color]
>
> Well, I think all this explicit implementation stuff simply adds a layer of
> complexity that is more annoying than helpful.[/color]

Agreed.
[color=blue]
> I'm all for simplifying as
> much as possible. I figure if you don't want people to call a method, then
> you shouldn't implement it in a callable fashion (i.e. make it private and
> don't do it as part of the IDisposable interface to begin with).[/color]

Yup.
[color=blue]
> I mean, you're right, if they implement IDisposable, then I should be
> expected to call Dispose(), but they're kind of saying not to do it. I mean,
> that's kind of stupid, in my mind. And in this case, it could have
> unintended consequences for the user. It screams out bad design somewhere.[/color]

Yup.
[color=blue][color=green]
> > I would seriously consider doing so in the *very* near future. Are you
> > currently closing streams etc in finally blocks? If not, you're risking
> > problems if an exception is thrown. If you are, then your code would
> > become more readable immediately by using the using statement.[/color]
>
> I'm big on try/finally I don't know why. It adds an extra layer of
> indentation and yeah, it's kind of ugly. I just kind of got started that
> way (probably some book I read early on in my C# programming) and have been
> doing it ever since. What can I say? Habits are hard to break.[/color]

It'll come in handy if you ever do Java, where there's no using
statement (unfortunately) . Still, that's definitely better than not
doing anything at all, which is what far too many people do.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too