[Info-vax] Reinventing VMS logical names (Fuchsia & Win NT)

[Dan Cross]

In article <uj6dlv$2fvae$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 11/16/2023 6:35 PM, Dan Cross wrote:
>> In article <uj616t$2e6j7$1 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> [snip]
>>> The 1.2.2 version (latest version) on page labeled 8 (page 26
>>>from start) says:
>>>
>>> <quote>
>>> Objects are used to model the behavior of all sorts of application
>>> entities. In
>>> object-oriented terminology, an object is simply an instance of its
>>> class. Each object
>>> contains member functions (methods) that are only specified in the class as
>>> operations. In the distributed object model, a DCE interface is a public
>>> set of
>>> operations, but the methods of implementation are separate and application
>>> specific. (Data types are usually application specific but the interface
>>> can specify
>>> them as well.) A DCE interface specifies what is known as an abstract
>>> base class
>>> because the class has a public interface and a hidden implementation.
>>>
>>> Object-oriented applications make it easy to hide data and
>>> implementation details
>>> by using hierarchies of classes and other object-oriented features. Thus
>>> object-oriented applications can help minimize the exposure of network
>>> details and
>>> the special DCE mechanisms of distributed computing. In DCE, the IDL
>>> compiler
>>> generates a class hierarchy for applications. This hierarchy contains an
>>> interface
>>> class derived from a DCE RPC base class. The interface class becomes
>>> part of an
>>> application in such a way that the network details, mechanisms of data
>>> transfer, and
>>> object location are hidden (encapsulated) in the base class.
>>> </quote>
>> 
>> You elided all of the context of the rest of the book, instead
>> quoting one small part of one small section that would appear to
>> support your thesis, provided one hasn't actually read the book.
>> But here at least you should have quoted the first paragraph of
>> the section you copied:
>> 
>> |DCE allows for a distributed object model in conjunction with
>>                                             ^^^^^^^^^^^^^^^^^^^
>> |the other DCE models to give a flexible way to distribute
>>   ^^^^^^^^^^^^^^^^^^^^
>> |functionality and data for client/server applications. In
>> |addition, a distributed object model combines appropriate
>> |functionality with data, by way of distributed objects, in
>> |a way that also hides how parts of the distributed application
>> |communicates.
>> 
>> Note the emphasis I added.  Does DCE _allow_ you to write a
>> system based on distributed objects?  Sure.  So does HTTP.  OO
>> is one of many models one can map things to both HTTP and DCE
>> RPCs; does that mean that that DCE RPC is somehow
>> "Object-Oriented"?  Not really; neither is HTTP for that matter.
>> Do you really think the fact that the IDL compiler can generate
>> C++ changes that?  One can generate object-oriented bindings for
>> HTTP clients and servers as well; so is HTTP "object-oriented"?
>
>The comparison with HTTP is totally bogus.

Yes, I understand that it does not support your thesis about DCE
and OO.  But your thesis seems to be based on factual errors.  I
suggest you spend some time reading the DCE application
development documentation; it's decidedly not object-focused.

>HTTP interface is not defined using an object oriented definition
>like IDL

You keep saying that, but have you actually used it, or even
looked at it in any detail?

The DCE IDL isn't particularly object-oriented; it is explicitly
described as being close to C and is explained in terms of the
sorts of concepts one would expect to see in a fairly
traditional procedural language: compound data types a la
C-style "structs", constants, and procedures/functions.

>and the HTTP documentation does not talk about being
>object oriented like the DCE one does.

The DCE documentation does make reference to object-orientation
in the context of talking about a _model_ for structuring a
system, and for C++ code that can be generated by the IDL
compiler (added in DCE 1.2.1, incidentally; note that MSRPC is
based on 1.1).  That is, it can generate object-oriented
bindings for DCE RPC services.

But none of that is the same as DCE RPC being "object oriented",
and if you actually spend some time with the DCE documentation,
I think you'd be hard-pressed to explain how it is
"object-oriented" in the way you seem to be describing it.

>It is correct that DCE can be used non object-oriented, but that
>is not really relevant.

Again, it's not clear what you mean when you say that DCE RPC is
"object-oriented" beyond something so nebulously vague that a C
header file could be considered "object-oriented."

>The argument proposed was that DCE lost due to not being object
>oriented.
>
>It does not seem plausible that DCE was discarded for not being
>object oriented when it can be used object oriented just because
>it can also be used non-object oriented.

The entire system was oriented towards an era that was coming to
a close: centralized services tightly-coupled with OS-centric
notions of identity, authentication, data storage, etc.  The web
came along and largely obsoleted the things that DCE provided.

	- Dan C.