Private imports and Objects

[Jonathan M Davis]

On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote:
> 1. Why are imports visible from outside the package when you do
> selective imports?
>
> //mod.d
> module mod;
>
> import std.stdio : writeln;
>
> public void greet()
> {
>      writeln("Hello");
> }
>
>
> //app.d
> import mod;
>
> void main()
> {
>   mod.greet();
>   writeln("You should not be seeing this.");
>
> }
>
> Compiles just fine and prints "You should not be seeing this."
> just fine with `$dub build`. Even if I use package imports the
> result stays the same.

If you use a version of dmd that's at least semi-recent, you should see a
deprecation message. It works due to a long standing bug that has been
fixed, but when it was fixed, a number of aspects of imports were
overhauled, and it was decided to phase in the new behavior to minimize code
breakage, and as such, it should be printing a deprecation message at the
moment, whereas in the future, it will become an error like it should be.

> 2. Classes that do not inherit (base classes) actually inherit
> from 'Object`. For which, often times one converts the Object to
> its subclasses. What's the rationale behind this?
> Isn't this going to add overhead?

I don't understand the question. You're asking whether casting from a base
class to a derived class creates overhead? Or are you asking whether having
a base class for all classes creates overhead? Or something else?

Object exists primarily because D didn't originally have templates, and when
you don't have templates, having a single base class is the only way to have
a function accept any class, and for something like a container, you'd
pretty much be forced to use void* without Object if you don't have
templates. However, once templates were added to D, the benefits of Object
were significantly reduced, and it's arguably not a particularly good idea
to be writing code that operates on Object. However, it's far too late in
the game to get rid of Object.

At one point, it was decided to remove Object's member functions, because
having them on Object needlessly locks in a particular set of attributes for
those functions, and if we did that, then there really wouldn't be much
reason to use Object directly, but that change has never happened, and it's
not clear that it's going to happen, since there are a number of technical
issues that make it a bit of a pain to do (particularly if we don't want to
break a lot of code). One of the bigger issues is that the AA implementation
in druntime needs to be templated so that it doesn't need to operate on
Object, and that's proven to be a bit of a challenge.

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

- Jonathan M Davis