[MUD-Dev] Spoofs

[John Buehler]

Daniel Harman writes:

> In many circumstances I agree, but it depends on the complexity of
> your class hierarchy and how the objects interelate. The problem
> with your approach is that if want to use functionality of the
> child component, but no interest in the functionality of the
> parent in this instance, then the parent still gets instantiated
> by the child. Or do you you have to add code to the child to
> dynamically instantiate a parent on an as needed basis?

> e.g.

>   You have this:

>
>                   IMessageMap
>                         |
>     CActiveX      CMessageMap
>         \___        ___/
>             \      /
>              \    /
>             CWindow

In a component system, this is an assembly.  It has a class
identifier of its own because collectively it has a specific
behavior that isn't covered by CWindow or CMessageMap or CActiveX
individually.  The mechanism of an assembly involves runtime
connections between the involved components.  CWindow acknowledges
that it operates in conjunction with an IMessageMap.  So we can give
it a CMessageMap's IMessageMap or, alternately, CFunkyMessageMap's
IMessageMap, per your contrasting example.

The template approach permits you to specify what classes should be
related to other classes, and that is what assemblies are about.  So
the exact functionality that you're after is possible by using that
technology.  It does it in a more rigorous fashion because nobody is
tempted to cheat and look inside an associated class.  With
components, it's all interfaces.  With C classes, you can clown
around with member data and other goodies.  There's a contract
there, but nobody is forced to think of it as such.  And where is
the technology that I speak of?  Deep in the bowels of Microsoft
Research.  The technique itself isn't remarkable, although few seem
to have grasped it to date.

> The bloat you mentioned isn't really a fair criticism, as the
> whole point is that you only bring in what you need. Its
> anti-bloat!

Each time a class is referenced in one of these constructs, it is
duplicated.  Thus the bloat concern.  In the assembly technique, the
only addition of information to the overall system is the actual
data that orchestrates the connection of the assembly, plus the code
that permits connections to be made in each component.  Because the
code that permits connections to be made is a component itself that
is aggregated by just about every other component, the actual cost
of that code is negligible.

>> It is my understanding that C# makes all this COM component stuff
>> much easier to deal with.  So I'm told by my old team at
>> Microsoft.  And that should make COM component development that
>> much more appealing.

> COM isn't actually that hard if you take the time to learn the
> rules. I've heard the C# team are in direct competetion with the
> COM team at MS and its a pitched battle by all accounts. Both
> teams thinking the opponents approach is flawed as there are some
> fundamental differences in methodology. COM wants everything to be
> a black box, .net is opposite in that it thinks full reflection is
> of key importance.

Just as a reminder, I came from the research team that Tony Williams
started in order to continue the work that he began years ago as
COM.  Yes, we were in direct opposition to the COM+ guys (although
they made some pretty impressive components).  Tony's team is now
using C# and are cranking out components by using its features.  I'm
told that it's vastly simpler than the C code that we were having to
write.  The devil was definitely in the details.

As for COM not being that hard, well, it's straightforward to create
components once you know the rules.  But doing an optimal design of
an all-component application is no mean task.  As a result,
component development itself has to be made trivial so that all the
needed brain cycles can be applied to the higher order design
problems that show up.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev