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


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.
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


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.
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.


 
 
 


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.

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 

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.


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.


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

- 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
 
 


What a good news!
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




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.




 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.

 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

 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.


 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




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.




 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.

 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

 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.


 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


expert).

 -- 
 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