Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Eiffel and COM

0 views
Skip to first unread message

Thomas Goering

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
It's hardly to ignore: The recent activities of two major Eiffel compiler
vendors will hopefully lead us to a wider acceptance of Eiffel. After ISE
released its EiffelCOM library, Object Tools has released a first version of
their COM to Eiffel bridge last month. I think that COM is the ideal base
for the purpose of introducing Eiffel to projects that now use C++ or Java
and for building reliable components. COM provides a language-independent
way for a component-based development that is accepted in the public and
seems to have its future. Am I right? What do you think?

But as I don't know much about COM yet, could anyone recommend proved
introductory books about COM. At the moment I have two books (borrowed from
a colleague):

1. 'Essential COM' by Don Box (Addison Wesley): This one goes extremely into
depth and uses only C++ for implementation.
2. 'Inside COM' by Dale Rogerson (Microsoft Press): I prefer this one at the
moment, although it uses C++ for implementation, too.

Any comments on these book? Are there any books that use a more
language-independent way for the introduction to COM. Does this make sense
at all?

Regards,
Thomas


Raphael Simon

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to

Thomas Goering wrote:[new COM support by Object-Tools and ISE.]

The COM and Eiffel relationship has indeed a great potentiality. COM is a
powerful, empiric technology. Some specific parts of its design have however
some flaws (The best example I can think of now is the terrible "void **" in the
QueryInterface method). Eiffel can help to produce better components ("void **"
becomes ECOM_UNKNOWN).

> But as I don't know much about COM yet, could anyone recommend proved
> introductory books about COM. At the moment I have two books (borrowed from
> a colleague):
>
> 1. 'Essential COM' by Don Box (Addison Wesley): This one goes extremely into
> depth and uses only C++ for implementation.
> 2. 'Inside COM' by Dale Rogerson (Microsoft Press): I prefer this one at the
> moment, although it uses C++ for implementation, too.
>
> Any comments on these book? Are there any books that use a more
> language-independent way for the introduction to COM. Does this make sense
> at all?

Actually, I personally prefer Don Box book. It has a very clear explanation on
the motivations that lead to the creation of COM. 'Inside DCOM' by Guy Eddon and
Henry Eddon (Microsoft Press) is a good up-to-date version of 'Inside COM'. I
would also look forward for the incoming book of Don Box (I am not sure of the
title, something like "optimized DCOM").

Regards,

Raphael Simon.


Kaelin Colclasure

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
Thomas Goering wrote:
It's hardly to ignore: The recent activities of two major Eiffel compiler
vendors will hopefully lead us to a wider acceptance of Eiffel. After ISE
released its EiffelCOM library, Object Tools has released a first version of
their COM to Eiffel bridge last month. I think that COM is the ideal base
for the purpose of introducing Eiffel to projects that now use C++ or Java
and for building reliable components. COM provides a language-independent
way for a component-based development that is accepted in the public and
seems to have its future. Am I right? What do you think?
This post caught my interest, and so I took a quick look at the EiffelCOM library information available on ISE's Web site. My impression from what was available there is that this library allows you to a) use an Eiffel application as an automation controller, and b) use in-process automation servers (ActiveX controls, mostly) in an Eiffel application.

What is not supported is the far more useful (IMO) capability of developing in-process automation servers in Eiffel, and then deploying them for use from any of the host of RAD languages that have been ActiveX enabled. If I am mistaken in this impression, please set me straight.

Bertrand Meyer

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
Kaelin Colclasure wrote:


! This post caught my interest, and so I took a quick look at the EiffelCOM
! library information available on ISE's Web site. My impression from what was
! available there is that this library allows you to a) use an Eiffel
! application as an automation controller, and b) use in-process automation
! servers (ActiveX controls, mostly) in an Eiffel application.

! What is not supported is the far more useful (IMO) capability of developing
! in-process automation servers in Eiffel, and then deploying them for use from
! any of the host of RAD languages that have been ActiveX enabled. If I am
! mistaken in this impression, please set me straight.

This is in the works and will be available soon. We agree that it's
quite important. More details will be posted at http://eiffel.com.

--
Bertrand Meyer, Interactive Software Engineering
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
http://eiffel.com

Alexander Kogtenkov

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
Kaelin Colclasure wrote:
...

> What is not supported is the far more useful (IMO) capability of
developing
> in-process automation servers in Eiffel, and then deploying them for use
from
> any of the host of RAD languages that have been ActiveX enabled. If I am
> mistaken in this impression, please set me straight.

Recently released VE 2.5 allows to create in-process COM servers,
including automation ones (examples are included).

Though this is the first version of VE that provides this facility, it
reflects "bridge" technology which will be supported in this and next
releases of VE. It allows to write all code in Eiffel without any need
for user to manually represent details of COM implementation.

However, some specific constructs like "IUnknown **" are not
mapped into Eiffel in a natural way. These and some other
deficiencies are subject for improvements in the next version.

--
Alexander Kogtenkov
Object Tools, Moscow

d...@control.com

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
In article <35B64A71...@talarian.com>,

Kaelin Colclasure <kae...@talarian.com> wrote:
>
> This post caught my interest, and so I took a quick look at the EiffelCOM
> library information available on ISE's Web site. My impression from what was
> available there is that this library allows you to a) use an Eiffel
application
> as an automation controller, and b) use in-process automation servers (ActiveX

> controls, mostly) in an Eiffel application.
>
> What is not supported is the far more useful (IMO) capability of developing
> in-process automation servers in Eiffel, and then deploying them for use from
> any of the host of RAD languages that have been ActiveX enabled. If I am
> mistaken in this impression, please set me straight.

Last I looked at EiffelCOM it was also unclear whether it was pure IDispatch
or whether it supported direct (i.e. efficient) call to the COM interfaces.
A restriction to automation compatible data types is OK, though far from
desireable. A restriction to late binding and IDispatch is too little
support, too late. Sourcing events with and without IDispatch is also vital
to my work.

Whenever I post a message raising this issue, the silence is deafening.

Dan Pierson
Control Technology Corporation

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Raphael Simon

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to

Kaelin Colclasure wrote:

> This post caught my interest, and so I took a quick look at the
> EiffelCOM library information available on ISE's Web site. My
> impression from what was available there is that this library allows
> you to a) use an Eiffel application as an automation controller, and
> b) use in-process automation servers (ActiveX controls, mostly) in an
> Eiffel application.

Indeed, the current version of EiffelCOM allows the creation of both
local or remote Automation servers and clients. However, direct vtable
access is not possible yet. It is under development and should be
available in incoming releases. Also, the ability to produce DLLs (and
in-process components) will be added in the same time.

There will be a tool that will parse an IDL file to produce code dealing
with the EiffelCOM run-time. This code will be the link between COM and
Eiffel. It will also generates template Eiffel classes. It will be then
possible to define the behavior of the component by completing these
template classes.

Hope this is useful,
regards,

Raphael Simon.


Raphael Simon

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to

d...@control.com wrote:

> Last I looked at EiffelCOM it was also unclear whether it was pure IDispatch
> or whether it supported direct (i.e. efficient) call to the COM interfaces.
> A restriction to automation compatible data types is OK, though far from
> desireable. A restriction to late binding and IDispatch is too little
> support, too late. Sourcing events with and without IDispatch is also vital
> to my work.

As explained in my other post, the current release of EiffelCOM only supports
IDispatch (late binding). ISE is aware that it is too limitative and next version
will support direct vtable access. There will also be a support for all types which
can be defined in IDL: IDL types will be mapped into Eiffel classes.

> Whenever I post a message raising this issue, the silence is deafening.

I might have missed your other posts but it has always been clearly stated (as
proven by my last post) that the current release of EiffelCOM only supports late
binding.

regards,

Raphael Simon.


0 new messages