www.digitalmars.com         C & C++   DMDScript  

D - Interface Policy

reply larry cowan <larry_member pathlink.com> writes:
1. Private email is private discussion and should stay that way.

2. Public forum messages (and especially here) may be copied, reused, etc.

3. The interfaces topic is of interest to many in this forum.  Whether or not
there is private email negotiating the needs and ways to solve them, I think
there does need to be a policy level announcement by Walter on this topic here.
Too many questions have been opened, opinions stated, problems described, to
just leave things the way they have been.

4. It has been a hot day in spite of the chill and rain here in PA.

5. Limbo from AT&T sounds even more like D than Java or C++ does, but it's
interpreted...
Apr 08 2004
parent reply "Walter" <walter digitalmars.com> writes:
"larry cowan" <larry_member pathlink.com> wrote in message
news:c55fbd$107b$1 digitaldaemon.com...
 3. The interfaces topic is of interest to many in this forum.  Whether or

 there is private email negotiating the needs and ways to solve them, I

 there does need to be a policy level announcement by Walter on this topic

 Too many questions have been opened, opinions stated, problems described,

 just leave things the way they have been.

Actually, I've been working on a solution, but I want to make sure it works correctly first.
Apr 09 2004
next sibling parent reply larry cowan <larry_member pathlink.com> writes:
Thanks.  I didn't mean instantly, but we need some future plans with more than a
few words.  It is a a large concern to many of us, and to you, I'm sure.  The
commercial useability of D is very important to us also.

In article <c55klr$19bd$1 digitaldaemon.com>, Walter says...
"larry cowan" <larry_member pathlink.com> wrote in message
news:c55fbd$107b$1 digitaldaemon.com...
 3. The interfaces topic is of interest to many in this forum.  Whether or

 there is private email negotiating the needs and ways to solve them, I

 there does need to be a policy level announcement by Walter on this topic

 Too many questions have been opened, opinions stated, problems described,

 just leave things the way they have been.

Actually, I've been working on a solution, but I want to make sure it works correctly first.

Apr 09 2004
parent reply School <tec_mailhk yahoo.com.hk> writes:
larry cowan said:
 Thanks.  I didn't mean instantly, but we need some future plans with more than
a
 few words.  It is a a large concern to many of us, and to you, I'm sure.  The
 commercial useability of D is very important to us also.
 
 In article <c55klr$19bd$1 digitaldaemon.com>, Walter says...
 
"larry cowan" <larry_member pathlink.com> wrote in message
news:c55fbd$107b$1 digitaldaemon.com...

3. The interfaces topic is of interest to many in this forum.  Whether or

not
there is private email negotiating the needs and ways to solve them, I

think
there does need to be a policy level announcement by Walter on this topic

here.
Too many questions have been opened, opinions stated, problems described,

to
just leave things the way they have been.

Actually, I've been working on a solution, but I want to make sure it works correctly first.


starting looking at D and see that just a Interface could case so many problems, I am more worrying using D or not. Just take a look at something like java. We all know that java people use interface very much, and we know that they also really "implements" the interface. I couldn't find that happening, even in future, in D. Just only the syntax is confusing, a ":" stands for "implements", but it also stand for "inherits", so which is the real thing? Without a rough look of the original code of the interface implemented, we could not see if it is a interface or not. Also as others here said, is D interface really a interface? I would not say it is. From other examples, I can only state a use of interface in D -- mapping a COM object. I use "map" because it is really a mapping, and we know that interface originally is designed for the "maker", not the user. What I want to point out is that "interface" is not a wrapper for user of the class/object, but for class maker to give a better organized front-end to users. I would suggest, renaming the keyword interface to wrapper, which is a reflection of current use. In the other hand, the real interface usage stated above could be incorporated as "properties". It is actually from C#. From other forums and mailing-list or etc., I get the idea that properties is actually a improved version of interfaces. In my point of view properties are readable and/or writable, so does interfaces. Of course they are not totally the same, but if it is possible properties would give better results than interfaces. After all, D *is* D. It is not C, VC, Java, C# etc. There is no need for D to copy others, but there is a need to make things as clear as possible. I hope somebody here would give brighter ideas than annoying noises.
Apr 09 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"School" <tec_mailhk yahoo.com.hk> wrote in message
news:c56p63$2un$1 digitaldaemon.com...
 I totally feel your worrying of the future of D interface. I am now
 starting looking at D and see that just a Interface could case so many
 problems, I am more worrying using D or not.

- Kris
Apr 09 2004
parent School <tec_mailhk yahoo.com.hk> writes:
Kris ??:
 "School" <tec_mailhk yahoo.com.hk> wrote in message
 news:c56p63$2un$1 digitaldaemon.com...
 
I totally feel your worrying of the future of D interface. I am now
starting looking at D and see that just a Interface could case so many
problems, I am more worrying using D or not.

And the good news is ... Walter has resolved all those issues! - Kris

Apr 09 2004
prev sibling next sibling parent "Pablo Aguilar" <paguilarg hotmail.com> writes:
Just a comment... you're thinking exclusively about dispinterfaces (or
properties/methods called through an IDispatch interface)... full COM
Interfaces are used by clientes (i.e. IDispatch which is used to set/get
properties and call methods of dispinterfaces)

 larry cowan said:
 Thanks.  I didn't mean instantly, but we need some future plans with


 few words.  It is a a large concern to many of us, and to you, I'm sure.


 commercial useability of D is very important to us also.

 In article <c55klr$19bd$1 digitaldaemon.com>, Walter says...

"larry cowan" <larry_member pathlink.com> wrote in message
news:c55fbd$107b$1 digitaldaemon.com...

3. The interfaces topic is of interest to many in this forum.  Whether




not

there is private email negotiating the needs and ways to solve them, I

think
there does need to be a policy level announcement by Walter on this




here.

Too many questions have been opened, opinions stated, problems




to

just leave things the way they have been.

Actually, I've been working on a solution, but I want to make sure it



correctly first.


starting looking at D and see that just a Interface could case so many problems, I am more worrying using D or not. Just take a look at something like java. We all know that java people use interface very much, and we know that they also really "implements" the interface. I couldn't find that happening, even in future, in D. Just only the syntax is confusing, a ":" stands for "implements", but it also stand for "inherits", so which is the real thing? Without a rough look of the original code of the interface implemented, we could not see if it is a interface or not. Also as others here said, is D interface really a interface? I would not say it is. From other examples, I can only state a use of interface in D -- mapping a COM object. I use "map" because it is really a mapping, and we know that interface originally is designed for the "maker", not the user. What I want to point out is that "interface" is not a wrapper for user of the class/object, but for class maker to give a better organized front-end to users. I would suggest, renaming the keyword interface to wrapper, which is a reflection of current use. In the other hand, the real interface usage stated above could be incorporated as "properties". It is actually from C#. From other forums and mailing-list or etc., I get the idea that properties is actually a improved version of interfaces. In my point of view properties are readable and/or writable, so does interfaces. Of course they are not totally the same, but if it is possible properties would give better results than interfaces. After all, D *is* D. It is not C, VC, Java, C# etc. There is no need for D to copy others, but there is a need to make things as clear as possible. I hope somebody here would give brighter ideas than annoying noises.

Apr 12 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
Actually, a com interface is a MS C++ compatible virtual pointer table. It
is defilned that way to be completely simple to implement in MS C++ (et al).
It is a binary standard for defining functions (methods) and not properties.
COM requires that all interfaces derive from IUnknown; however, this is just
a way of providing object life time control by reference counting.

The IDispatch inteface is another layer on top of this, implementing a bunch
of functions that allow 'late bound' applications to pass all functions
calls (and property set/reads) through a single function as varaints - very
ugly.

The ultimate is to build on top of an IDispatch interface and get both the
'late bound' capability as well as the direct call capability via the vtbl's
pointers to functions. The standard is to then define properties as both get
and set/put methods on the interface - so each property requires two
functions one to read and one to write.

The meta data about the inteface (type library) is used by the standard COM
IDispatch implementation to pass the variant based calls to the actual vtbl
ones. An interface defiend this way is called 'dual'.

Does this make sence to anyone - does anyone care?



"School" <tec_mailhk yahoo.com.hk> wrote in message
news:c56p63$2un$1 digitaldaemon.com...
 larry cowan said:
 Thanks.  I didn't mean instantly, but we need some future plans with


 few words.  It is a a large concern to many of us, and to you, I'm sure.


 commercial useability of D is very important to us also.

 In article <c55klr$19bd$1 digitaldaemon.com>, Walter says...

"larry cowan" <larry_member pathlink.com> wrote in message
news:c55fbd$107b$1 digitaldaemon.com...

3. The interfaces topic is of interest to many in this forum.  Whether




not

there is private email negotiating the needs and ways to solve them, I

think
there does need to be a policy level announcement by Walter on this




here.

Too many questions have been opened, opinions stated, problems




to

just leave things the way they have been.

Actually, I've been working on a solution, but I want to make sure it



correctly first.


starting looking at D and see that just a Interface could case so many problems, I am more worrying using D or not. Just take a look at something like java. We all know that java people use interface very much, and we know that they also really "implements" the interface. I couldn't find that happening, even in future, in D. Just only the syntax is confusing, a ":" stands for "implements", but it also stand for "inherits", so which is the real thing? Without a rough look of the original code of the interface implemented, we could not see if it is a interface or not. Also as others here said, is D interface really a interface? I would not say it is. From other examples, I can only state a use of interface in D -- mapping a COM object. I use "map" because it is really a mapping, and we know that interface originally is designed for the "maker", not the user. What I want to point out is that "interface" is not a wrapper for user of the class/object, but for class maker to give a better organized front-end to users. I would suggest, renaming the keyword interface to wrapper, which is a reflection of current use. In the other hand, the real interface usage stated above could be incorporated as "properties". It is actually from C#. From other forums and mailing-list or etc., I get the idea that properties is actually a improved version of interfaces. In my point of view properties are readable and/or writable, so does interfaces. Of course they are not totally the same, but if it is possible properties would give better results than interfaces. After all, D *is* D. It is not C, VC, Java, C# etc. There is no need for D to copy others, but there is a need to make things as clear as possible. I hope somebody here would give brighter ideas than annoying noises.

Apr 14 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Scott Egan" <scotte tpg.com.aux> wrote:

 Actually, a com interface is a MS C++ compatible virtual pointer
 table. It is defilned that way to be completely simple to implement in
 MS C++ (et al). It is a binary standard for defining functions
 (methods) and not properties. COM requires that all interfaces derive
 from IUnknown; however, this is just a way of providing object life
 time control by reference counting. 

Don't forget IUnknown::QueryInterface(), which is where most of the weirdness enters in :-)
 The IDispatch inteface is another layer on top of this, implementing a
 bunch of functions that allow 'late bound' applications to pass all
 functions calls (and property set/reads) through a single function as
 varaints - very ugly.

And slow. But it's how you get languages such as VB and JavaScript to talk to COM objects, and in many of those cases speed isn't the main issue.
 Does this make sence to anyone - does anyone care?

Yes, it was a good explanation. I think our interest here is whether supporting COM in D will inhibit functionality for non-COM applications. The line of thought that COM is a special case, but necessary for acceptance in the real world, makes the most sense to me. I like the idea of having a special way to indicate a COM interface, with special behavior limited to those kinds of declarations, and with Java-like behavior for standard D interfaces. In fact, if a D-style COM interface declaration had smart pointer functionality like _comptr_t<> or CComPtr<>, with reference counting management built in, and QueryInterface() calls via D's standard cast() keyword, that would be slick. Of course, there's probably issues with that which I haven't thought through (I'm certainly not a COM expert). -- dave
Apr 14 2004
parent reply "Scott Egan" <scotte tpg.com.aux> writes:
Do you know that VB only uses IDispatch when its using the generic object
type.

Its smart enough to use the actual vtbl for dual interfaces and can even use
pure COM (ie no IDispatch) if the types are legal automation ones.

If you try hard you can get VB to directly call things like the DirectX COM
APIs without a wrapper.

Scott

"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94CB41CBD5908dsiebersbc 63.105.9.61...
 "Scott Egan" <scotte tpg.com.aux> wrote:

 Actually, a com interface is a MS C++ compatible virtual pointer
 table. It is defilned that way to be completely simple to implement in
 MS C++ (et al). It is a binary standard for defining functions
 (methods) and not properties. COM requires that all interfaces derive
 from IUnknown; however, this is just a way of providing object life
 time control by reference counting.

Don't forget IUnknown::QueryInterface(), which is where most of the weirdness enters in :-)
 The IDispatch inteface is another layer on top of this, implementing a
 bunch of functions that allow 'late bound' applications to pass all
 functions calls (and property set/reads) through a single function as
 varaints - very ugly.

And slow. But it's how you get languages such as VB and JavaScript to talk to COM objects, and in many of those cases speed isn't the main issue.
 Does this make sence to anyone - does anyone care?

Yes, it was a good explanation. I think our interest here is whether supporting COM in D will inhibit functionality for non-COM applications. The line of thought that COM is a special case, but necessary for acceptance in the real world, makes the most sense to me. I like the idea of having a special way to indicate a COM interface, with special behavior limited to those kinds of declarations, and with Java-like behavior for standard D interfaces. In fact, if a D-style COM interface declaration had smart pointer functionality like _comptr_t<> or CComPtr<>, with reference counting management built in, and QueryInterface() calls via D's standard cast() keyword, that would be slick. Of course, there's probably issues with that which I haven't thought through (I'm certainly not a COM

 -- 
 dave

Apr 14 2004
parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Scott Egan" <scotte tpg.com.aux> wrote:

 Do you know that VB only uses IDispatch when its using the generic
 object type.
 
 Its smart enough to use the actual vtbl for dual interfaces and can
 even use pure COM (ie no IDispatch) if the types are legal automation
 ones. 
 
 If you try hard you can get VB to directly call things like the
 DirectX COM APIs without a wrapper.

No, I didn't know that! But I've done only very little VB. I guess this would be possible when you declare the object type up-front (when you import the type library via References)? I once tried to get VB6 to use the DirectShow API for video capture, but gave up on it quickly -- probably didn't understand VB well enough at the time. This makes me wonder, though: would it make any sense for D's "import" keyword to work like MS's "import" in C++, where it can import a COM type library? Or maybe a different keyword, like "com_import". And then D could generate D-style smart pointer interfaces for the library? (just thinking out loud, maybe it makes no sense...). If it worked, though, it would make COM (client) programming in D very clean. -- dave
Apr 14 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I hate to say I told you so, but:
	I told you so.

Go get 'em, Walter.  Looking for an employee, by any chance? :)

Walter wrote:
 Actually, I've been working on a solution, but I want to make sure it works
 correctly first.

Apr 09 2004
parent "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c56fc5$2j72$2 digitaldaemon.com...
 Go get 'em, Walter.  Looking for an employee, by any chance? :)

Yes, one who will work for free <g>.
Apr 09 2004