www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - move std.{ascii, base64, utf} to a new encoding package

reply Seb <seb wilzba.ch> writes:
Hi all,

today Johannes and I had a short discussion on Github about 
std.base64. I think his post is a good summary of the status quo:


 base64 shouldn't be a top level module though, moving it to a 
 new package std.encoding may be a good idea. std.base64 is just 
 quite old and when it was written we didn't use subpackages in 
 phobos yet. std.utf and std.ascii are also encodings and could 
 be moved to std.encoding as well, AFAICS. And we also have a 
 std.encoding module which should be part of the same package.


That being said I know that such housekeeping isn't liked a lot, 
but with `public import` we can very easily mitigate breakage and 
allow a long deprecation period.
What's your opinion on this? Any major objections?

Cheers,

Seb

[1] 
https://github.com/dlang/phobos/pull/4720#issuecomment-238348553
Aug 08 2016
next sibling parent LaTeigne <LaTeigne blabla.fr> writes:
On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote:

 Hi all,

 today Johannes and I had a short discussion on Github about 
 std.base64. I think his post is a good summary of the status 
 quo:


 base64 shouldn't be a top level module though, moving it to a 
 new package std.encoding may be a good idea. std.base64 is 
 just quite old and when it was written we didn't use 
 subpackages in phobos yet. std.utf and std.ascii are also 
 encodings and could be moved to std.encoding as well, AFAICS. 
 And we also have a std.encoding module which should be part of 
 the same package.


 That being said I know that such housekeeping isn't liked a 
 lot, but with `public import` we can very easily mitigate 
 breakage and allow a long deprecation period.
 What's your opinion on this? Any major objections?

 Cheers,

 Seb

 [1] 
 https://github.com/dlang/phobos/pull/4720#issuecomment-238348553


They're all related to encoding but they don't have a proper 
common interface like std.digest or std.experimental.allocators

I think it would be justified for something like

std.encoding.variable_length_quantity
std.encoding.z85
std.encoding.base64
std.encoding.base32
std.encoding.base16
etc...

with an uniform API (decode, encode, + specialized helpers)

I you do it as the modules are now it's gonna look like the 
content of a girl bag because of no uniform API.

In short I'm against unless a serious work is done on the API, 
otherwise it's just a crappy useless refactoring.
Aug 08 2016
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote:

 ...


Also see https://github.com/dlang/phobos/pull/4599 for more 
discussion on why std.encoding's current design is problematic, 
and why it should probably be redesigned.
Aug 08 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote:

 Hi all,

 today Johannes and I had a short discussion on Github about

 std.base64. I think his post is a good summary of the status quo:

 base64 shouldn't be a top level module though, moving it to a
 new package std.encoding may be a good idea. std.base64 is just
 quite old and when it was written we didn't use subpackages in
 phobos yet. std.utf and std.ascii are also encodings and could
 be moved to std.encoding as well, AFAICS. And we also have a
 std.encoding module which should be part of the same package.


 That being said I know that such housekeeping isn't liked a lot,
 but with `public import` we can very easily mitigate breakage and
 allow a long deprecation period.
 What's your opinion on this? Any major objections?

 Cheers,

 Seb

 [1]
 https://github.com/dlang/phobos/pull/4720#issuecomment-238348553


std.encoding needs a complete overhaul. Unfortunately, while I think that
that's generally agreed upon, no one has stepped up to do it. So, who knows
when it'll be fixed. However, given that std.encoding needs an overhaul, I
don't seem much point in moving stuff into it. While it may not be ideal,
base64 works where it is, and we can worry about moving it when std.encoding
is revamped. If we changed it now and then changed it again when
std.encoding got overhauled, then we'd end up breaking code twice just to
move a function around.

- Jonathan M Davis
Aug 08 2016
parent Seb <seb wilzba.ch> writes:
On Tuesday, 9 August 2016 at 00:24:40 UTC, Jonathan M Davis wrote:

 On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote:

 [...]


 std.encoding needs a complete overhaul. Unfortunately, while I 
 think that that's generally agreed upon, no one has stepped up 
 to do it. So, who knows when it'll be fixed. However, given 
 that std.encoding needs an overhaul, I don't seem much point in 
 moving stuff into it. While it may not be ideal, base64 works 
 where it is, and we can worry about moving it when std.encoding 
 is revamped. If we changed it now and then changed it again 
 when std.encoding got overhauled, then we'd end up breaking 
 code twice just to move a function around.

 - Jonathan M Davis


Thanks   all for your explanations!
FWIW I have added std.encoding to the wiki's wishlist ;-)

https://wiki.dlang.org/Wish_list#std.encoding
Aug 10 2016