[DGD] Terms and sharing utility code between objects

Mikael Lind mikkelin at gmail.com
Thu Feb 8 01:16:42 CET 2007


Hello,

2007/2/7, Petter Nyström <jimorie at gmail.com>:
>  So first I should probably clarify what I mean by utility code.
> Shortly, I mean pure programs that have no global variables. (If you
> get what I mean, can you also tell me what is the proper term?)

 I do not know of a proper term, but I have also used the term
utility. This is also the term used in Java for classes with only
static functions.

>  The approaches I can come up with are:
>
>  - #include the program into the objects that need its functionality.

Prefer inheritance to reduce memory usage. This solution is only
recommended for the auto object, which cannot inherit. Inclusion does
not scale well when utility programs are implemented in terms of other
utility programs. Private inheritance does.

>  - Access the required functionality from the defining program with
> call_other().

I used to be against this because you lose the compile-time checks and
most likely pay some additional overhead compared to a local function
call. The Kernel Library uses it for things like normalize_path(), and
I have found myself using the pattern in my system code. I think it is
appropriate to use it in system code, less so in user code. Users need
all the help they can get. ;-)

>  - Inherit the program and access the functionality locally.

My favourite. Use private inheritance for is-implemented-in-terms-of
relationships, as would be the case for utility programs. (Use
non-private inheritance for is-a relationships.)

>  - As a special case of the above, bag all utility functions together
> and put them in the auto object.

Not a good idea. The auto object is privileged. You should keep the
amount of privileged code to a minimum to reduce the risk of security
problems. Only code that needs to be privileged should be. Also, you
are polluting the namespace of each program with a lot of functions
that may not be used in every program. It is a better idea to provide
reusable code in modules.

> What is your preferred method for getting utility functionality like
> this into your objects?

Private inheritance, at least for user-level code.

> I think I have used them all to some degree at different points.
> Lately I have been trying to inherit the functionality I need. And
> actually, something that I am even more interested in at the moment,
> is if there are some official terms for inheritables that hold data
> and those that do not? I have been struggling to find words to
> differentiate the programs I inherit to make up the object dataspace
> from the ones I just inherit to get access to some utility functions.
> Any suggestions?

Use the plain old /lib/ subdirectory for your stateful programs and
/lib/util/ for your stateless utility programs. If you use API
programs like the Kernel Library does, use a /lib/api/ subdirectory.
You can call them library, utility, and API programs, respectively.

Regards,
Mikael




More information about the DGD mailing list