Throught delegates? The only lines that have extern (D) are:
aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
gc\gc.d(91): extern (D) alias void (*fp_t)(Object);
What I want to be able is to define a class in one file and implement some
of it's methods in another. Can we do this?
Thanks

Throught delegates? The only lines that have extern (D) are:
aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
gc\gc.d(91): extern (D) alias void (*fp_t)(Object);
What I want to be able is to define a class in one file and implement some
of it's methods in another. Can we do this?

Yes. In phobos\std\gc.d, we have the functions declared but not defined:
void fullCollect();
whereas in phobos\internal\gc\gc.d, it is implemented:
void fullCollect() { ... implementation ... }
The way phobos is built, it is not linked with phobos\std\gc.d, but with
internal\gc\gc.d, though the user of gc never sees the implementation and
doesn't care.

Julio did you get this working ? If so could you post it so we could put it
on the wiki ? ( I am still not sure how you would implement this for
classes )
C
"Walter" <walter digitalmars.com> wrote in message
news:bp28fs$uof$3 digitaldaemon.com...

Throught delegates? The only lines that have extern (D) are:
aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
gc\gc.d(91): extern (D) alias void (*fp_t)(Object);
What I want to be able is to define a class in one file and implement

some

of it's methods in another. Can we do this?

Yes. In phobos\std\gc.d, we have the functions declared but not defined:
void fullCollect();
whereas in phobos\internal\gc\gc.d, it is implemented:
void fullCollect() { ... implementation ... }
The way phobos is built, it is not linked with phobos\std\gc.d, but with
internal\gc\gc.d, though the user of gc never sees the implementation and
doesn't care.

Throught delegates? The only lines that have extern (D) are:
aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
gc\gc.d(91): extern (D) alias void (*fp_t)(Object);
What I want to be able is to define a class in one file and implement

some

of it's methods in another. Can we do this?

Yes. In phobos\std\gc.d, we have the functions declared but not defined:
void fullCollect();
whereas in phobos\internal\gc\gc.d, it is implemented:
void fullCollect() { ... implementation ... }
The way phobos is built, it is not linked with phobos\std\gc.d, but with
internal\gc\gc.d, though the user of gc never sees the implementation and
doesn't care.

But they're free functions. The OP (and me!) wants to know how to do this
for classes. In other words, get back to the C++ way of separation of
interface from implementation.

Yes. In phobos\std\gc.d, we have the functions declared but not defined:
void fullCollect();
whereas in phobos\internal\gc\gc.d, it is implemented:
void fullCollect() { ... implementation ... }
The way phobos is built, it is not linked with phobos\std\gc.d, but with
internal\gc\gc.d, though the user of gc never sees the implementation

and

doesn't care.

But they're free functions. The OP (and me!) wants to know how to do this
for classes. In other words, get back to the C++ way of separation of
interface from implementation.

But the two files are unrelated, are they not? It's not possible to
"include" the public into the private, one just has to generate a stripped
public one, no? Hence, an opportunity for errors. Or am I missing something?

But the two files are unrelated, are they not? It's not possible to
"include" the public into the private, one just has to generate a
stripped public one, no? Hence, an opportunity for errors. Or am I
missing something?

Well, there are two aspects to this.
1. IP protection. This may be rare. Most shared software will be
open-source, or at least source-supplied. Most application software will be
binary only. However, once established, there will be
2. The separate writing of interface and implementation as a development
convenience. I know the "wider development community" has an issue with C &
C++'s separation of interface and implementation, but I've always thought
this a strength, and I consider Java, C# and D weak, since they force
sometimes enormous amounts of implementation into the class interface. If D
was to support both, as C++ does, I think that would be an advantage.
However, I suspect this will never happen, so I'm not going to argue
forcefully for it.
So, we really just want a stripper. How will this be implemented?
I think dmd.exe should support, as standard, the option -strip=<file>. When
it receives this option, it should defer to a strip module (module in the
binary sense, not in the D sense), i.e. a DLL or .SO, called DMDStrip.dll or
libDMDStrip.so, and loaded according to the host operating system's loading
rules. The module should have the following entry points (which should be
C-compatible, so we can use this in other tools):
int DStrip_Initialise()
void DStrip_Uninitialise()
int DStrip_String(char (const) *srcName, char (const) *dest, uint flags);
The inclusion/separation has the following advantages:
1. By being a standard part of the compiler, we can have a standard approach
to the development of scripts (make) and tools leds/DIDE/etc.
2. It does not have to be implemented by Walter. All he has to do is add the
small amount of code into the compiler that parses -strip=<file>, loads the
DLL and calls the entry points. (I expect he'll put some SEH around the
calls, in case the strip author is a gibbering fool. ;)
3. We can each install and write our own strip components, _if we want_
(Most will not, of course)
4. There can be a shared strip project. Hopefully we can start with Burton's
dstrip code, if we're allowed. Naturally, the expectation is that a shared
project would reach very high quality quite quickly.
"Walter" <walter digitalmars.com> wrote in message
news:bpb42k$2a08$1 digitaldaemon.com...

I agree with you - a stripper is the way to go. It should also be
implemented using the compiler source. But all it needs is the lexer and the
parser, and I think it should just be a separate tool (just built out of the
compiler sources). Unlike C++, you don't need much code to implement
something like this. (In fact, you could not implement this for C++ 100%.)

Um, I'm trying really hard not to comment here. In fact, I was hoping somebody
else would post already, just so I could behave myself. Hopefully there's a
sense of humor in this group and Jan won't pull this, but what a great quote
from our fearless leader. Just trying to keep it light.

else would post already, just so I could behave myself. Hopefully there's

a

sense of humor in this group and Jan won't pull this, but what a great

quote

from our fearless leader. Just trying to keep it light.

LOL! When I was in college, one of the sports was to post on the frat house
wall out-of-context quotes from the members. The rules were that it had to
be an actual quote, and the out-of-context meaning had to be unintended.