std.data.json formal review

[Jacob Carlborg via Digitalmars-d]

On 2015-07-30 06:41, Walter Bright wrote:

> I agree with your goal of readability. And if someone wants to write
> code that emphasizes it's JSON, they can write it as
> std.data.json.parseStream. (It's not about saving typing, it's about
> avoiding extra redundant redundancy, I'm a big fan of Strunk & White :-)
> ) This is not a huge deal for me, but I'm not in favor of establishing a
> new convention that repeats the module name. It eschews one of the
> advantages of having module name spaces in the first place, and evokes
> the old C style naming conventions.

I kind of agree with that, but at the same time, if one always need to 
use the fully qualified name (or an alias) because there's a conflict 
then that's quite annoying.

A prefect example of that is the Path module in Tango. It has functions 
as "split" and "join". Every time I use it I alias the import:

import Path = tango.io.Path;

Because otherwise it will conflict with the string manipulating 
functions with the same names. In Phobos the names in the path module 
are different compared to the string functions.

For example, I think "Value" and "parse" are too generic to not include 
"JSON" in their name.

-- 
/Jacob Carlborg