std.fileformats?
berni44
dlang at d-ecke.de
Tue Jan 7 12:44:40 UTC 2020
On Tuesday, 7 January 2020 at 01:10:08 UTC, Jonathan M Davis
wrote:
> Are you talking about putting them all in a single module or
> all in a single package?
Sorry, for being unclear here. I thought of a package.
> Now, personally, I don't think that anything regarding file
> formats should have been in the standard library in the first
> place.
Thinking about this whole stuff, I noticed, that there are two
different points of view, which should be separated: The idealist
view and the pragmatic view. IMHO both are important.
So when I got you right, from an idealists view, you'd say these
file formats should be removed from phobos, but from a
pragmatists view this looks much more difficult.
I think, I share this point of view. But I'd like to get rid of
them anyway.
> For the most part, I don't see any point in removing any of
> these modules, since that would break existing code,
Well, every module, that is kept inside Phobos produces (lots of)
maintainance work. From my perspective, we are missing resources
here. So I prefere a controlled breaking of code (with
deprecation and all) instead of having the code rosting and
breaking uncontrolled sooner or later.
I came up with this issue, when I looked at my own comment on
issue 17709 [1]: I found the reason for this issue and I think I
could fix that in a reasonable amout of time. But is it worth it
doing so if that module might be removed or replaced in the near
future? Wouldn't it be much better to use that time to fix a bug
at a more important place?
But on the other side: How does such a comment look like to
someone how is using std.xml and found that issue, cause he
stumbled over the same problem? Wouldn't it be better to remove
std.xml completely in the first place?
[1] https://issues.dlang.org/show_bug.cgi?id=17709
And than, there is something more to be thought of: The (public)
perception of Phobos. If it contains parts, that are more or less
broken, useless or outdated, this will be the parts where people
will look at, when they judge. It won't help much to have other
parts, that work well.
> BTW, base64 isn't really a file format. It's an encoding.
Really? So why isn't it in std.encoding? :-) I know, that base64
is somewhat different, maybe it's in the gray area... Or look at
it the other way round: Isn't zipping also just encoding and
unzipping decoding?
More information about the Digitalmars-d
mailing list