View mode: basic / threaded / horizontal-split · Log in · Help
December 21, 2012
Re: About Go, D module naming
12/21/2012 12:44 PM, Timon Gehr пишет:
> On 12/21/2012 06:41 AM, Walter Bright wrote:
>> ....
>>
>> D has an excellent module system.
>
> ... modulo the private symbol clash issue. For all I know it is
> deliberate, which is embarrassing. Other than obviously breaking
> modularity, it severely restricts the usefulness of symbol
> disambiguation (which it makes necessary when it should not be), because
> the disambiguating alias may introduce more conflicts even if it is
> private, all over the code base.
>

+1. It never made any sense to me that private is visible but not 
accessible. A carryover from C++ I guess (but there we just hide stuff 
out of the header file, use awful internal namespaces etc.).

> Eg:
>
> https://github.com/D-Programming-Language/druntime/pull/298#discussion_r1691013
>
>
>> No, I don't think Go or anyone else has a better one.
>
> Other languages that support modules usually get hiding of private
> symbols (or equivalent) right.


-- 
Dmitry Olshansky
December 21, 2012
Re: About Go, D module naming
Walter Bright:

> another large source of irritation if unused imports are errors.

In Go even unused variables are *errors* :-)


> D has an excellent module system. No, I don't think Go or 
> anyone else has a better one.

I think D module system is a primitive tool compared to (S)ML 
module system.

http://en.wikipedia.org/wiki/Standard_ML#Module_system

More info on SML module system can be found with Google.

Bye,
bearophile
December 21, 2012
Re: About Go, D module naming
On Friday, December 21, 2012 12:57:10 Dmitry Olshansky wrote:
> +1. It never made any sense to me that private is visible but not
> accessible. A carryover from C++ I guess (but there we just hide stuff
> out of the header file, use awful internal namespaces etc.).

It also makes stuff like private aliases useless. I don't really know of any 
reason _not_ to fix it. At minimum, private symbols should be removed from 
overload sets outside of their module, though they may need to remain visible 
(but inaccessible) in dealing with stuff other than overload sets.

- Jonathan M Davis
December 21, 2012
Re: About Go, D module naming
On 12/21/2012 12:58 AM, bearophile wrote:
> Walter Bright:
>> D has an excellent module system. No, I don't think Go or anyone else has a
>> better one.
>
> I think D module system is a primitive tool compared to (S)ML module system.
>
> http://en.wikipedia.org/wiki/Standard_ML#Module_system

Then why did you bother with the Go module system?
December 21, 2012
Re: About Go, D module naming
Walter Bright:

> Then why did you bother with the Go module system?

The Go and D module systems are comparable, while the SML module 
system is something quite different and another (higher) level.

Bye,
bearophile
December 21, 2012
Re: About Go, D module naming
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are 
>> errors.
>
> In Go even unused variables are *errors* :-)
>
>
>> D has an excellent module system. No, I don't think Go or 
>> anyone else has a better one.
>
> I think D module system is a primitive tool compared to (S)ML 
> module system.
>
> http://en.wikipedia.org/wiki/Standard_ML#Module_system
>
> More info on SML module system can be found with Google.
>
> Bye,
> bearophile

SML modules are something entirely different from D modules. If 
you want SML module like functionality in D, the closest thing 
are actually structs with all members static (or just wrapping 
your functions in a template), not modules.
December 21, 2012
Re: About Go, D module naming
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are 
>> errors.
>
> In Go even unused variables are *errors* :-)

This is a tricky one. On one hand, it *is* a useful way to catch 
errors, but on the other it's a constant source of irritation 
when you are tinkering with code during development/debugging.
December 21, 2012
Re: About Go, D module naming
On Friday, 21 December 2012 at 13:19:32 UTC, Peter Alexander
wrote:
> On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
>> Walter Bright:
>>
>>> another large source of irritation if unused imports are 
>>> errors.
>>
>> In Go even unused variables are *errors* :-)
>
> This is a tricky one. On one hand, it *is* a useful way to 
> catch errors, but on the other it's a constant source of 
> irritation when you are tinkering with code during 
> development/debugging.

I would consider those not as (language, compile-time) errors but
(not-)compliance with strictness-levels.

However, it is reasonable to include something like strictness
levels as part of the compiler? (think gcc with MISRA-C
integrated).
December 21, 2012
Re: About Go, D module naming
jerro:

> SML modules are something entirely different from D modules.

Yep. (That's what I have said to Walter).


> If you want SML module like functionality in D,

I don't. I (did) want modules to have the same name as their 
files.

Bye,
bearophile
December 21, 2012
Re: About Go, D module naming
On 12/21/12, bearophile <bearophileHUGS@lycos.com> wrote:
> Walter Bright:
>
>> another large source of irritation if unused imports are errors.
>
> In Go even unused variables are *errors* :-)

There was a long blost post somewhat recently (well, it might be from
this year at least) where the author complained how the Go compiler
likes to error on the most trivial things, and how it interrupts the
workflow of the programmer. The link is somewhere on reddit.

If I really want to get all the warnings I would want to have a
special flag for these kinds of trivial things (which will probably
never happen), but then again I might as well use another tool for it.

Speaking of tools: you could fork DMD, add all the warnings you want
in the front-end and provide a script for users that automatically git
clones your repo and builds the custom DMD, which can then be used as
a lint tool. That way you avoid having to create something from
scratch, and avoid redistribution issues.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home