"Walter Bright" <newshound@digitalmars.com> wrote
> COM/interface/factory methodology in C++ does enable full hiding, however, and if you do that in D, you get full hiding as well.


With respect to indirection: let's go back to the Factory example I posted earlier, which the compiler failed on:

~~~~~~~~~~~~~~~~~~~
SearchInterfaces.d
~~~~~~~~~~~~~~~~~~~

module SearchInterfaces;

interface ISearchEngine
{
        ISearchItem[] lookup (char[] terms);
}

interface ISearchItem
{
        int relevancy();
        char[] retrievalUrl();
        char[] displaySnippet();
}



~~~~~~~~~~~~~~~~~~~
SearchFactory.d
~~~~~~~~~~~~~~~~~~~

module SearchFactory;


public import SearchInterfaces;

// private import a.bunch.of.proprietary.stuff;


// a factory for hooking up a client to the hidden implementation
ISearchEngine createSearchEngine (char[] someAttributes)
{
        // potentially reference a.bunch.of.proprietary.stuff;
        return new XYX(someAttributes).
}


// do some proprietary setup
private static this()
{
        // potentially do a.bunch.of.proprietary.stuff;
}

~~~~~~~~~~~~~~~~~~~~~


That's the Factory implementation, which has a bunch of proprietary stuff in it along with references to proprietary imports. To correctly decouple a client from this implementation, one should provide another file (I'm covering Walter's statements here, from a long time ago) along the following lines:

~~~~~~~~~~~~~~~~~~~
SearchFactory.di
~~~~~~~~~~~~~~~~~~~

module SearchFactory;   // I believe this has to be the same name?

public import SearchInterfaces;

ISearchEngine createSearchEngine (char[] someAttributes);

~~~~~~~~~~~~~~~~~~~


This setup does the right thing from an implementation-hiding aspect. It's what's been asked for many times in the past. Note that only public decalarations have been exposed. There's no class in there at all, just to make it as simple as possible. Unfortunately, I can't show the -H version. However, it's not much of a stretch to map the above onto Derek's original example, and assert that (for example) the implementation for both the factory method, and the static ctor() would be exposed (along with any other method considered to be inline-able) That would be no good, Walter. If it were the case, we'd have to ship all those proprietary imports too, along with everything they referenced ~ ad infinitum.

I do wish I had a working compiler so this could be more concrete.

"Sean Kelly" <sean@f4.ca> wrote...
> But don't you have to supply a -H command-line parameter to indicate that the header should be generated?  I'm not sure it's fair to criticize DMD for what seems like user error.

It's a precarious approach, which I noted in the OP. You've used Build before ... it's very easy to take a mis-step here, in all manner of ways.

"JT" <JT_member@pathlink.com> wrote
>  I still cant understand why people are upset because a feature
> exists they dont need. Its downright comedy.

It would be, if it had no ramifications. It's clear that you're thinking about the claimed "performance enhancing" aspects alone, and not the real topic at all. If you really think that I personally fit into your little frame above, then you're sorely mistaken. Sure is nice that you're being entertained, though :)

Kris wrote:
> 
> This setup does the right thing from an implementation-hiding aspect. It's what's been asked for many times in the past. Note that only public decalarations have been exposed. There's no class in there at all, just to make it as simple as possible. Unfortunately, I can't show the -H version. However, it's not much of a stretch to map the above onto Derek's original example, and assert that (for example) the implementation for both the factory method, and the static ctor() would be exposed (along with any other method considered to be inline-able) That would be no good, Walter. If it were the case, we'd have to ship all those proprietary imports too, along with everything they referenced ~ ad infinitum.

So why not provide a method to turn off inlined function generation? Since inlining isn't always desired, this seems a reasonable request.


Sean

In article <dp574e$gie$1@digitaldaemon.com>, Kris says...
>
>"JT" <JT_member@pathlink.com> wrote
>>  I still cant understand why people are upset because a feature
>> exists they dont need. Its downright comedy.
>
>It would be, if it had no ramifications. It's clear that you're thinking about the claimed "performance enhancing" aspects alone, and not the real topic at all. If you really think that I personally fit into your little frame above, then you're sorely mistaken. Sure is nice that you're being entertained, though :)
>
>

Well I agree with a lot of what you are saying but I think you clearly want a *DIFFERENT* solution for implementation hiding than -H. Its like people are saying "Walter, this apple tastes like an orange!". maybe thats because it is an orange. :D  Maybe you need to use the front end and come up with your own solution? just a suggestion....

Indeed. We should try to be clear that -H performs some kind of source-code munging for purposes other than this topic. Several folk (including myself) have tried to say, in a variety of different ways, "we should desist from associating it with implementation-hiding, since it is not currently targeted for that task".

As you say, it is currently "an orange" :)




"JT" <JT_member@pathlink.com> wrote in message news:dp57m1$gs6$1@digitaldaemon.com...
> In article <dp574e$gie$1@digitaldaemon.com>, Kris says...
>>
>>"JT" <JT_member@pathlink.com> wrote
>>>  I still cant understand why people are upset because a feature
>>> exists they dont need. Its downright comedy.
>>
>>It would be, if it had no ramifications. It's clear that you're thinking about the claimed "performance enhancing" aspects alone, and not the real topic at all. If you really think that I personally fit into your little frame above, then you're sorely mistaken. Sure is nice that you're being entertained, though :)
>>
>>
>
> Well I agree with a lot of what you are saying but I think you clearly
> want a
> *DIFFERENT* solution for implementation hiding than -H. Its like people
> are
> saying "Walter, this apple tastes like an orange!". maybe thats because it
> is an
> orange. :D  Maybe you need to use the front end and come up with your own
> solution? just a suggestion....
>
>
>
>
> 

For implementation hiding, just move the private members in classes to the end of the vtable, after all public and protected members (define this in the ABI and modify the reference compiler to guarantee this). Problem solved.

No more private members need to be included in the generated header files because their vtable offsets are always greater than vtable offsets of public/protected members and will have no push/pull affect on them if left out.  Simply ignoring them in the _header_ class creates no binary compatibility issues.

Const initializers; simply include them as well in the generated header classes for public/protected members to preserve correct offsets.

Templates... well that's another story.

James Dunne wrote:
> For implementation hiding, just move the private members in classes to the end of the vtable, after all public and protected members (define this in the ABI and modify the reference compiler to guarantee this). Problem solved.
> 
> No more private members need to be included in the generated header files because their vtable offsets are always greater than vtable offsets of public/protected members and will have no push/pull affect on them if left out.  Simply ignoring them in the _header_ class creates no binary compatibility issues.
> 
> Const initializers; simply include them as well in the generated header classes for public/protected members to preserve correct offsets.
> 

I was wondering about this!

> Templates... well that's another story.

I guess it is another story.  Maybe templates should just stay in there own D file and be processed the old fashioned way.

Oh boy, look at us.  We're all still trying to solve the implementation-hiding issue, insatiable creatures we are. :)

-JJR

On Sat, 31 Dec 2005 10:28:10 +1100, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Derek Parnell" <derek@psych.ward> wrote in message
> news:op.s2le7jga6b8z09@ginger.vic.bigpond.net.au...
>> On Fri, 30 Dec 2005 21:10:52 +1100, bobef <bobef@lessequal.com> wrote:
>>> P.S. I didn't undestand how you control if the compiler is importing .d
>>> or .di . I looked in the docs but I didn't find any info on that. I mean
>>> if they have the same name?
>>
>> If you code "import xyz" the compiler looks first for xyz.d, and if it
>> can't find that it tries to find xyz.di and if that's not found it errors.
>
> No, first it looks for .di, then .d.

Brillilant! I think I can use that behaviour in the macro preprocessor coming soon to Build.



-- 
Derek Parnell
Melbourne, Australia

On Sat, 31 Dec 2005 16:44:18 +1100, JT <JT_member@pathlink.com> wrote:

> I still cant understand why people are upset because a feature
> exists they dont need. Its downright comedy.

It's because of a misunderstanding. Myself and some others assumed its purpose was to support closed-source development, especially by the way it was presented by Walter, but it turns out that it's purpose is to speed up compilation when libraries are being used. I'm afraid its really just because we misunderstood Walter's (and Dave's) intent for the feature. Personally, I have no need for it as compilations speeds are so fast that even a 50% reduction would have zero effect on productivity.

-- 
Derek Parnell
Melbourne, Australia