[MUD-Dev] (no subject)

[Bruce]

Joe Andrieu wrote:
> In comparing inheritance to components, what are the differences, if any,
> in memory usage and/or processing demands when your number of objects
> scales dramatically?
> 
> I can see how components could be a good alternative to inheritance in some
> cases, but if I have tens or hundreds of thousands of objects (or more),
> each with potentially a dozen or so components, is that any worse or better
> than the same number of objects with an inheritance scheme?  Or am I
> misunderstanding the situation?

<snip original paragraph that I wrote because I'm tired and it
was confusing>

What I meant was:

Object A inherits B.

B defines per-instance state variables (x, y, z).

Each instance of A will have to have storage for (x, y, z).

--or--

Object A accesses B as a service.

B needs per-client state, so it allocates a context object, or an
instance for A to use.  That context object or instance contains
storage for (x, y, z).

--or--

Object A accesses B as a service.

B needs no per-client state.  It allocates a single instance of
(x, y, z).  If this is the case, then the above don't really
matter as you surely wouldn't have implemented it that way. :)

--end--

(per-client is referring to A as a client of B.)

There may be implementation specific advantages to either model
due to your language, language runtime, or environment.

I have some of the same concerns as you, regarding thousands and
millions of objects.  But we're worrying about them at an
entirely different level. (We're trying to manage the overhead of
many objects by way a persistent object system integrated with
garbage collection routines, to allow us to automatically be able
to load and unload data from various sources (disk, algorithmic,
databases) transparently.)

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