On Mon, 14 May 2012 09:20:57 -0400, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
On 14.05.2012 16:37, Steven Schveighoffer wrote:
The one last puzzle to solve is sharing. File is this half-breed of
sharing, because it contains a FILE *, which is a shared type, but File
is not. Then it does some casting to get around the problems.
And it all went nice and well till I spotted FILE*. Boom.
I mean I half assumed we are going to drop this crutch. Yep, too harsh.
So probably leave it as *one* of file backends that features
compatibility with C. Because IMHO using C-runtime this way is not
buying us anything else other then C compatibility and "welcome to the
world of unportable hacks where performance matters".
I think the compromise agreed upon will be reasonable. A constructed File
will start out as a FILE * entity until you want to do anything more
complex than writeln or readf. At that point, it switches over to D-based
backend automatically. I don't want to be trying to implement advanced
buffer-based techniques using FILE *, and I also don't want to restrict
phobos' types to only doing things that FILE * can do well. At the same
time, we have this legacy with std.stdio.File that we have to maintain
(the comments on my preliminary library were near-unanimous -- it cannot
break existing code).
Walter has a very very hard requirement that D's equivalent stdout stdin,
and stderr all interoperate with the C calls that use the equivalent C
structures. In other words, it is a hard requirement that writeln and
printf interoperate.
Really, printf is the *only* reason to have this backwards compatibility
"feature", and I strongly wish we could get rid of it.
That being said, if you *want* to avoid FILE *, it will definitely be
possible.
We need a
better solution than this, but shared is so difficult to use, I think
I'm going to have to implement something similar. It has been stipulated
by Walter and Andrei that fixing this shared situation is a requirement
for any new replacement. I have some ideas, but I have to play around to
see if they actually work and make sense.
Probably it worths checking how std.stdio does it.
I have. I don't know how well it applies to my library. One thing about
using FILE * is that you have full knowledge of the known universe of FILE
*. This means you can control internally the interactions between
threads, making sure that you don't have an unshared pointer unless the
thing is locked (and this is what std.stdio does).
The problem is when you create an *extendable* system like the one I'm
doing. At that point, you can lock when you cast away shared, but you
have no idea whether a method call is going to squirrel away an unshared
reference to itself somewhere, so that when you go back to shared (and
unlock), there's a leaked thread-local reference somewhere.
It may have to require documentation-based restrictions (i.e.
not-compiler-enforced). I haven't put enough thought into the possible
means to do this. Ideas are welcome!
-Steve
