Very good points, but fails to address how to handle COM capability, whi=
ch =
I think is important to Walter, and many others. I think commercial =
vendors will be as quick to dismiss D without COM ability as without =
adequate 'interface' support. I like lary's idea of having the interfac=
es =
as they are now re-named for COM interfaces, and then implementing the =
interfaces as you envision them.
I don't see how we could unify them without losing something on either =
side .
Ideas ?
C
On Tue, 6 Apr 2004 12:14:40 -0800, Kris =
<someidiot earthlink.dot.dot.dot.net> wrote:

I believe it's time to do something positive about the state of =

Interfaces
as implemented in D. To this end, I've written a small document detail=

ing

what I feel are the issues at hand. It's attached as an MS Word docume=

nt,

and I apologize to those who can't access it because of that.
As noted in the document, it is absolutely not my intent to give Walte=

r a

hard time, or to discredit D as a viable and useful language. My goal =

"C" <dont respond.com> wrote in message news:opr5148ozvehmtou localhost...
Very good points, but fails to address how to handle COM capability, which
I think is important to Walter, and many others. I think commercial
vendors will be as quick to dismiss D without COM ability as without
adequate 'interface' support. I like lary's idea of having the interfaces
as they are now re-named for COM interfaces, and then implementing the
interfaces as you envision them.
I don't see how we could unify them without losing something on either
side .
Ideas ?

Even though I haven't really understood yet what is actually meant by the
technical term 'interface', I can see that there is at least two flavours
being discussed here. If both are important and useful, then a simple
qualifying keyword should be all that's needed to let the D compiler know
what the code author is referring to. Something like ...
ms_com interface ABC{ . . . }
and
native interface DEF{ . . . }
Slightly off-topic, how does Microsoft's .NET vision change the future usage
of COM/ActiveX components and D? Does this also imply that D needs to
support a .NET type of interface?
--
Derek

Even though I haven't really understood yet what is actually meant by the
technical term 'interface', I can see that there is at least two flavours
being discussed here. If both are important and useful, then a simple
qualifying keyword should be all that's needed to let the D compiler know
what the code author is referring to. Something like ...
ms_com interface ABC{ . . . }
and
native interface DEF{ . . . }

I would suggest the existing pragma attribute would be good considering
that COM interfaces are a OS dependant feature.
pragma(com_interface) interface ABC { }
http://www.digitalmars.com/d/pragma.html

I would suggest the existing pragma attribute would be good considering
that COM interfaces are a OS dependant feature.
pragma(com_interface) interface ABC { }
http://www.digitalmars.com/d/pragma.html

Another idea which does not requiere to change syntax: COM interface is
built upon a "pure interface" by library means, just as XPCOM interface,
and other interfaces which conflict with "D object interface". "D object
interface", ie an interface supporting backcasting to D object, can be
built from a pure interface by compiler means. I propose that whenever
an interface ihnerits from "ObjectInterface", which may be a half-bogus
interface reserving VTable space for requiered methods, these methods
would be implemented for each class descendant of it automatically.
A syntax may always be bound for all interfaces to ObjectInterface
method calls (ie assume they are there), which would allow to implement
similar behaviours in library, and would correctly give errors when you
try such a syntax (ie backcasting) on an interface which does not
support it.
-eye

Hmm, I think COM is ( supposedly ) OS independent though right ? Thats =
the claim, though I rarely see it in practice on non MS-OS's. I still =
think the pragma is smooth looking , and since we maybe shouldn't but =
technology specific items in the language itself it probably still fits =
under pragma.
It would also be cool if we could get pragma(link,mylib.lib) , I always =
liked that C++ feature :).
C
On Tue, 6 Apr 2004 22:17:31 +0000 (UTC), Patrick Down =
<Patrick_member pathlink.com> wrote:

In article <c4v7k8$8p0$1 digitaldaemon.com>, Derek Parnell says...

Even though I haven't really understood yet what is actually meant by=

=

the
technical term 'interface', I can see that there is at least two =

flavours
being discussed here. If both are important and useful, then a simple=

qualifying keyword should be all that's needed to let the D compiler =

Yeah, I'm hoping the fellow didn't get a second bout of a nasty flu. I
got 3 consecutive bugs in a row this last month. I guess my immune
system was so knocked down that I wasn't able to fend off the next ones.

Yeah, I'm hoping the fellow didn't get a second bout of a nasty flu. I
got 3 consecutive bugs in a row this last month. I guess my immune
system was so knocked down that I wasn't able to fend off the next ones.

Hey, that's not so bad -- I usually get 3 or 4 bugs every DAY :-)
--
dave

Yeah, I'm hoping the fellow didn't get a second bout of a nasty flu. I
got 3 consecutive bugs in a row this last month. I guess my immune
system was so knocked down that I wasn't able to fend off the next ones.

Hmm, I think COM is ( supposedly ) OS independent though right ? Thats =
the claim, though I rarely see it in practice on non MS-OS's. I still =
think the pragma is smooth looking , and since we maybe shouldn't but =
technology specific items in the language itself it probably still fits =
under pragma.
It would also be cool if we could get pragma(link,mylib.lib) , I always =
liked that C++ feature :).
C
On Tue, 6 Apr 2004 22:17:31 +0000 (UTC), Patrick Down =
<Patrick_member pathlink.com> wrote:

In article <c4v7k8$8p0$1 digitaldaemon.com>, Derek Parnell says...

Even though I haven't really understood yet what is actually meant by=

=

the
technical term 'interface', I can see that there is at least two =

flavours
being discussed here. If both are important and useful, then a simple=

qualifying keyword should be all that's needed to let the D compiler =

I believe it's time to do something positive about the state of Interfaces
as implemented in D. To this end, I've written a small document detailing
what I feel are the issues at hand. It's attached as an MS Word document,
and I apologize to those who can't access it because of that.
As noted in the document, it is absolutely not my intent to give Walter a
hard time, or to discredit D as a viable and useful language. My goal is
simple: resolve some of the real issues surrounding D Interfaces before it
goes mainstream with v1.0, such that it will be seen as a serious contender
by the commercial-development-sector and avoid being categorized as some
pet-project.
Some will say that I'm being unfair to Walter; that he's just one guy
working on this thing. While that may be a reasonable argument, the solution
would be to delay the v1.0 release.
Take a read, and reach your own conclusions.

I don't even understand the point of interfaces: it seems to me that all they do
is require a class implement something, which seems pointless.

I believe it's time to do something positive about the state of Interfaces
as implemented in D. To this end, I've written a small document detailing
what I feel are the issues at hand. It's attached as an MS Word document,
and I apologize to those who can't access it because of that.
As noted in the document, it is absolutely not my intent to give Walter a
hard time, or to discredit D as a viable and useful language. My goal is
simple: resolve some of the real issues surrounding D Interfaces before it
goes mainstream with v1.0, such that it will be seen as a serious contender
by the commercial-development-sector and avoid being categorized as some
pet-project.
Some will say that I'm being unfair to Walter; that he's just one guy
working on this thing. While that may be a reasonable argument, the solution
would be to delay the v1.0 release.
Take a read, and reach your own conclusions.

I don't even understand the point of interfaces: it seems to me that all they
do
is require a class implement something, which seems pointless.

I don't really understand the concept of interfaces either. I think
right now interfaces are intended to carry two different roles (maybe
that's why this controversy has erupted).
1) Capability to features built-in to Windows
Example: IShellLink (creating Windows shortcuts)
http://www.dsource.org/tutorials/index.php?show_example=31
2) Facilitates advanced object-oriented techniques
Exampe: Multiple Inheritance with template 'bolt-ins'
http://www.dsource.org/tutorials/index.php?show_example=55
Perhaps these two goals are incompatible. We could split these roles
into separate abstractions: interface and cominterface. Or maybe all we
need is a extern(cominterface) for COM interfaces (or an extern(D) for
these fancy new D-style interfaces that Kris has in mind).
Perhaps D only needs to hide a pointer to InterfaceInfo after the
"visible" vtbl entries. (It seems to me that it'd be possible for the
compiler to secretly tack another pointer after the end of the
structure. But I might be delusional.)
--
Justin
http://jcc_7.tripod.com/d/

I believe it's time to do something positive about the state of Interfaces
as implemented in D. To this end, I've written a small document detailing
what I feel are the issues at hand. It's attached as an MS Word document,
and I apologize to those who can't access it because of that.

(just download open office if you can't - it's big though)

As noted in the document, it is absolutely not my intent to give Walter a
hard time, or to discredit D as a viable and useful language.

I can't see how anybody would think that.
I thought interfaces on D were just broken or incomplete,
never occured to me that the limitations were by design.
I hope we all (I mean you) can move Walter on this issue.
(the one contributor that Walter listens to is a C++ man
I don't believe he can help us here.)
Ant

I believe it's time to do something positive about the state of Interfaces
as implemented in D. To this end, I've written a small document detailing
what I feel are the issues at hand. It's attached as an MS Word document,
and I apologize to those who can't access it because of that.

I believe it's time to do something positive about the state of Interfaces
as implemented in D. To this end, I've written a small document detailing
what I feel are the issues at hand. It's attached as an MS Word document,
and I apologize to those who can't access it because of that.

"In short, D interfaces are nothing but a shill for Microsoft’s COM, and
a thinly veiled marketing tool for those who actually use Interfaces in
real-world scenarios."
(Did anyone else perceive irony that this statement was in a Microsoft
Word document? ;) )
I've posted a PDF version of this in the files/documentation section at
http://groups.yahoo.com/group/d_lab/. OpenOffice (www.openoffice.org)
can easily make PDF files - even from Word documents.
I haven't studied the document yet, but it looks like a very thorough
statement of your perspective. I'm unclear whether you see any need to
use existing Microsoft-style interfaces, but that ability is a MUST in
my opinion. I'm much more interested in using IShellLink, IPicture, DAO,
and ADO than in creating my interfaces.

As noted in the document, it is absolutely not my intent to give Walter a
hard time, or to discredit D as a viable and useful language. My goal is
simple: resolve some of the real issues surrounding D Interfaces before it
goes mainstream with v1.0, such that it will be seen as a serious contender
by the commercial-development-sector and avoid being categorized as some
pet-project.
Some will say that I'm being unfair to Walter; that he's just one guy
working on this thing. While that may be a reasonable argument, the solution
would be to delay the v1.0 release.
Take a read, and reach your own conclusions.
With respect,
- Kris

(Did anyone else perceive irony that this statement was in a Microsoft
Word document? ;) )

I do! :-)
I realize in hindsight that I failed miserably to differentiate between COM
interface and OO Interface. For the record, I have no issue with the former
whatsover; it's the "claims" regarding the latter that my document was
explicitly oriented toward. That isolated sentence should have said "OO
Interfaces", as should many others, so as to be clear. It was certainly not
my intention to suggest COM programmers are somehow not involved with "real
world" scenarios. I do apologize over the confusion, and hope my obviously
unfettered frustration within the last few paragraphs does not distract too
much from the real meat.
I'm also of the opinion that Walter is more than capable of bringing forth
an elegant solution that is compatible with DOM, whilst fully supporting the
OO Interface paradigm. It's perhaps a question of motivation more than
anything else.
- Kris
(Personally, I like the pragma() approach suggested by Patrick Down: he
makes a really good point about COM support being OS dependent, and hence a
pragma candidate.)

Justin; I've updated that document to (a) be explicit about which Interface
mechanism is under scrutiny and (b) to tone down my frustration level
somewhat. I'd very much appreciate it if you'd replace the version you
posted to the yahoo group -- frankly, It didn't cross my mind that this
would go beyond the NG. How naive of me.
- Kris