On Monday, 17 March 2014 at 10:25:26 UTC, Walter Bright wrote:
> On 3/17/2014 12:53 AM, Iain Buclaw wrote:
>> If it's in any relation to your comments in the PR, my opinion is that they are
>> irrelevant to to PR in question, but they *are* relevant in their own right and
>> warrant a new bug/PR to be raised.
>
>
> Here it is:
>
> https://github.com/D-Programming-Language/druntime/pull/741
>
> I think it shows it is very relevant to your PR, as in fact I included your files essentially verbatim, I just changed the package layout.

So I'd import "core.sys.ucontext.package" if I didn't want a
system-specific module (which should be always)?  Why this
approach and not publishing modules from somewhere into core.sys
on install?

On 3/17/2014 12:18 PM, Sean Kelly wrote:
> So I'd import "core.sys.ucontext.package" if I didn't want a
> system-specific module (which should be always)?

No,

    import core.sys.ucontext;

Yes, ucontext is a directory. The package.d is a magic file name. This is the new package design that was incorporated last year, designed specifically to allow single imports to replaced by packages without affecting user code.


> Why this approach and not publishing modules from somewhere into core.sys
> on install?

The short answer is I happen to have a fondness for installs that are simple directory copies that do not modify/add/remove files. I think we are safely beyond the days that even a few hundred extra files installed on the disk are a negative.

Even if the non-used platform packages are simply deleted on install, this will not affect compilation. I think that's still better than modifying files. I've never trusted installers that edited files.

Besides that, there are other strong reasons for this approach:

1. New platforms can be added without affecting user code.

2. New platforms can be added without touching files for other platforms.

3. User follows simple no-brainer rule when looking at OS documentation:

    #include <ucontext.h>

  rewrites to:

    import core.sys.ucontext;

4. Bugs in particular platform support files can be fixed without concern with breaking other platforms.

5. Changes in platform support will not touch files for other platforms, greatly simplifying the QA review process.

6. D installed on Platform X can be mounted as a remote drive and used to compile for Platform Y.

On 3/17/2014 11:31 AM, Johannes Pfau wrote:
> Clever, but potentially dangerous once cross-module inlining starts
> working (The inlined code could be different from the code in the
> library).

True, but you can use .di files to prevent that.

On 3/17/2014 11:46 AM, Johannes Pfau wrote:
> With versions the user has no way to know if the library actually
> supports PNG or not. He can only guess and the optional case can't be
> implemented at all.

I don't know cairoD's design requirements or tradeoffs so I will speak generally.

I suggest solving this by raising the level of abstraction. At some point, in user code, there's got to be:

    if (CAIRO_HAS_PNG_SUPPORT)
        doThis();
    else
        doThat();


I suggest adding the following to the Cairo module:

    void doSomething()
    {
      if (CAIRO_HAS_PNG_SUPPORT)
        doThis();
      else
        doThat();

    }

and the user code becomes:

    doSomething();

On Monday, 17 March 2014 at 19:42:47 UTC, Walter Bright wrote:
> On 3/17/2014 12:18 PM, Sean Kelly wrote:
>> So I'd import "core.sys.ucontext.package" if I didn't want a
>> system-specific module (which should be always)?
>
> No,
>
>     import core.sys.ucontext;
>
> Yes, ucontext is a directory. The package.d is a magic file name. This is the new package design that was incorporated last year, designed specifically to allow single imports to replaced by packages without affecting user code.

Ah.  I suspected this might be the case and searched the language
docs before posting, but couldn't find any mention of this so I
thought I'd ask.

I like the idea of a file per platform, and am undecided whether
I prefer this or the publishing solution.  This one sounds more
flexible, but it may be more difficult to produce installs that
contain only the files relevant to some particular platform.

On 3/17/2014 1:23 PM, Sean Kelly wrote:
> I like the idea of a file per platform, and am undecided whether
> I prefer this or the publishing solution.  This one sounds more
> flexible, but it may be more difficult to produce installs that
> contain only the files relevant to some particular platform.

At the worst, you could do a recursive delete on freebsd.d, etc. :-)

Note that even with all these platform files, it only adds one extra file to the compilation process: package.d and the platform specific file.

Am Mon, 17 Mar 2014 20:10:31 +0100
schrieb Rainer Schuetze <r.sagitario@gmx.de>:

> > In that specific case, why does this not work for you?:
> >
> > nothrow extern(Windows) {
> >    HANDLE GetCurrentProcess();
> > }
> >
> 
> The attributes sometimes need to be selected conditionally, e.g. when building a library for static or dynamic linkage (at least on windows where not everything is exported by default). Right now, you don't have an alternative to code duplication or heavy use of string mixins.

Can we write this? It just came to my mind:

enum attribs = "nothrow extern(C):";

{
    mixin(attribs);
        HANDLE GetCurrentProcess();
}

-- 
Marco

On 3/14/2014 6:20 AM, Regan Heath wrote:
>
> Yes.. but doesn't help Manu or any other consumer concerned with speed
> if the library producer neglected to do this.  This is the real issue,
> right?  Not whether class *can* be made final (trivial), but whether
> they *actually will* *correctly* be marked final/virtual where they
> ought to be.
>
> Library producers range in experience and expertise and are "only human"
> so we want the option which makes it more likely they will produce good
> code.  In addition we want the option which means that if they get it
> wrong, less will break if/when they want to correct it.
>

While I personally would have been perfectly ok with changing to final-by-default (I'm fine either way), I can't help wondering: Is it really that big of a deal to sprinkle some "final"s into the occasional third party library if you really need to?

On Tuesday, 18 March 2014 at 01:25:34 UTC, Nick Sabalausky wrote:
> While I personally would have been perfectly ok with changing to final-by-default (I'm fine either way), I can't help wondering: Is it really that big of a deal to sprinkle some "final"s into the occasional third party library if you really need to?

It makes that much noise because this is a problem that everybody understand. Much bigger problem do not receive any attention.

On Tue, Mar 18, 2014 at 02:31:02AM +0000, deadalnix wrote:
> On Tuesday, 18 March 2014 at 01:25:34 UTC, Nick Sabalausky wrote:
> >While I personally would have been perfectly ok with changing to final-by-default (I'm fine either way), I can't help wondering: Is it really that big of a deal to sprinkle some "final"s into the occasional third party library if you really need to?
> 
> It makes that much noise because this is a problem that everybody understand. Much bigger problem do not receive any attention.

http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

:-)


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill