On Sunday, 9 June 2013 at 06:03:14 UTC, Manu wrote:
> I'm here, and interested in D due mainly to it's immediate familiarity, as
> opposed to others like Rust for instance. I can actually envision a
> migration. It seems like it's possible... one step at a time.
> ...it's also compiled and binary compatible, which is obviously critical ;)
> .. (this is where C# fails, or everyone would already be on that wagon
> without question)

I see your point, but there's a contradiction since I think a lot of the reason to move away from C/C++ to D is because D is actually different and does things in a more sane way. If you want to retain familiarity and 100% compatibility with C/C++, then just stick with C/C++. Yes D has attempted to remain sort of compatible with C.C++, so as to allow for a migration and to leverage the momentum, but that means that D is not truly standing on its own, and because of this, it has limited itself and deeply integrated some of the same bad things about C/C++ into D.

Rather than pollute D for sake of compatibility with all of the bad mistakes of the past, we should find better interfacing strategies. For instance, maybe a smart linker can help.

--rt

On 6/9/13 10:19 AM, Andrei Alexandrescu wrote:
> On 6/9/13 6:58 AM, Timon Gehr wrote:
>> On 06/09/2013 04:57 AM, Walter Bright wrote:
>>> On 6/8/2013 4:35 PM, Timon Gehr wrote:
>>>> 2. My last pull request has rotten for 6 months now.
>>>
>>> Sorry about that.
>>
>> No problem. Thanks for merging!
>
> Speaking of imports and dependencies, there was a dependency graph for
> Phobos that was circulating at some point. It used a script in
> conjunction with a graph printing program (such as dot or viz). Where is
> it?
>
> Thanks,
>
> Andrei

Philippe sent this to me via email. Getting it to work again doesn't seem like a slam dunk, so I'm posting this in case someone has the time. I think it would be a nice tool to have.

> The relevant graph algorithms are there:
>
> https://github.com/PhilippeSigaud/dranges/blob/master/graphalgorithm.d
>
> Lines 767-873. I see they are commented out, it seems there was a problem in 2.050 version of std.algo.startswith.
> Seeing how today Phobos and DMD are quite better, there is probably a much more elegant way to do the extraction now.
>
> The module also needs:
>
> https://github.com/PhilippeSigaud/dranges/blob/master/graph.d
> and
> https://github.com/PhilippeSigaud/dranges/blob/master/graphrange.d


Andrei

On 6/10/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Philippe sent this to me via email
>> The relevant graph algorithms are there:
>>
>> https://github.com/PhilippeSigaud/dranges/blob/master/graphalgorithm.d

This is very, very hacky. It fails as soon as you have a comment line inbetween your imports.

Anyway it works if you're very careful where you put the running script. It took just a few small fixes, clone this repo:

https://github.com/AndrejMitrovic/dranges

The FixGraph branch should be checked out. Then copy the "test.d" file one directory UP, and run "rdmd test.d"

On Friday, 7 June 2013 at 15:23:49 UTC, deadalnix wrote:
> On Friday, 7 June 2013 at 07:31:52 UTC, Walter Bright wrote:
>> deadalnix mentioned enforcing 'export' on classes exposed to shared libraries, but then aren't we back to expecting user annotation rather than doing things automatically?
>
> Yes, let me explain more.
>
> The export problem isn't new, and you'll find 2 major approach : the UNIX approach of export everything, and the windows approach of requiring explicit export.

Beware of generalizations, last time I used Aix (2002), it used the
same model as Windows, including export files.

Not sure how it works nowadays.

--
Paulo

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.894.1370540538.13711.digitalmars-d@puremagic.com...
> On Wednesday, June 05, 2013 22:50:14 Michel Fortin wrote:
>> P.S.: while implementing this change, please make sure private and package functions can be virtual.
>
> I'd agree with package on that, but I don't think that private should be
> virtualizable, because that conflicts with actually hiding non-accessible
> functions, which is what a number of us are pushing for. Otherwise,
> private
> implementation details of classes and modules risk causing code breakage
> (e.g.
> the fact that overload resolution occurs before checking the access level
> is
> atrocious).
>
> - Jonathan M Davis

Private functions can be overridden only within the same module.  This does not conflict with hiding private members from _outside_ the module.  You will always be able to _see_ private members from inside the same module, virtual or not.

On Wednesday, June 12, 2013 13:26:44 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.894.1370540538.13711.digitalmars-d@puremagic.com...
> 
> > On Wednesday, June 05, 2013 22:50:14 Michel Fortin wrote:
> >> P.S.: while implementing this change, please make sure private and package functions can be virtual.
> > 
> > I'd agree with package on that, but I don't think that private should be
> > virtualizable, because that conflicts with actually hiding non-accessible
> > functions, which is what a number of us are pushing for. Otherwise,
> > private
> > implementation details of classes and modules risk causing code breakage
> > (e.g.
> > the fact that overload resolution occurs before checking the access level
> > is
> > atrocious).
> > 
> > - Jonathan M Davis
> 
> Private functions can be overridden only within the same module. This does not conflict with hiding private members from _outside_ the module. You will always be able to _see_ private members from inside the same module, virtual or not.

Good point, but I fully expect that many of the folks who want to do NVI will want to use private functions for that as they do in C++, and I think that that would be a mistake. private is accessible within a module, so it should be visible to everything in that module, but IMHO, it shouldn't be visible or overridable outside of the module, as nothing outside of the module would have access to it, and it would be too detrimental with regards to name clashes to permit it.

- Jonathan M Davis

On Wednesday, 12 June 2013 at 03:26:43 UTC, Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
> news:mailman.894.1370540538.13711.digitalmars-d@puremagic.com...
>> On Wednesday, June 05, 2013 22:50:14 Michel Fortin wrote:
>>> P.S.: while implementing this change, please make sure private and
>>> package functions can be virtual.
>>
>> I'd agree with package on that, but I don't think that private should be
>> virtualizable, because that conflicts with actually hiding non-accessible
>> functions, which is what a number of us are pushing for. Otherwise, private
>> implementation details of classes and modules risk causing code breakage (e.g.
>> the fact that overload resolution occurs before checking the access level is
>> atrocious).
>>
>> - Jonathan M Davis
>
> Private functions can be overridden only within the same module.  This does
> not conflict with hiding private members from _outside_ the module.  You
> will always be able to _see_ private members from inside the same module,
> virtual or not.

Which also make them finalizable automagically.