Implementing an observer

[Tim Rentsch]

Le 23/11/10 00:39, Tim Rentsch a @C3{A9}crit :


What do you mean by that?

Can you explain?

Quoting from Wikipedia, a requirement is "a statement that
identifies a necessary attribute, capability, characteristic, or
quality of a system in order for it to have value and utility".

A "statement of requirements" is a listing of all such attributes,
etc, considered to be important, along with some sort of indication
of how conflicts are to be resolved when several attributes cannot
all be mutually satisified (for example, by stating that some
requirements have "higher priority" than other requirements).

 

[jacob navia]

Le 24/11/10 07:33, Tim Rentsch a écrit :

Quoting from Wikipedia, a requirement is "a statement that
identifies a necessary attribute, capability, characteristic, or
quality of a system in order for it to have value and utility".

A "statement of requirements" is a listing of all such attributes,
etc, considered to be important, along with some sort of indication
of how conflicts are to be resolved when several attributes cannot
all be mutually satisified (for example, by stating that some
requirements have "higher priority" than other requirements).

I have written the specifications, available at
http://www.cs.virginia.edu/~lcc-win32/container.html
I am writing the sample implementation.

Now, this is not finished, and I am adding some features
that I deem important.

Is that a "statement of requirements"?

Maybe.

 

[Tim Rentsch]

Le 24/11/10 07:33, Tim Rentsch a @C3{A9}crit :

I have written the specifications, available at
http://www.cs.virginia.edu/~lcc-win32/container.html

An impressively large document (meaning the included
documentation ccl.pdf). I didn't have time to read it
thoroughly, but I did skim about 10 or 20 pages, and
looked through the table of contents.

I am writing the sample implementation.

Now, this is not finished, and I am adding some features
that I deem important.

Is that a "statement of requirements"?

My answer is in two parts.

A. Not as I meant the term, no. This document describes
externally visible behavior, but what I was asking about is
a statement of requirements from the point of view of an
implementor, that is, a more complete statement about what
attributes and properties, etc, must be observed in the
implementation. Externally visible behavior is one part of
that, but only part.

B. My original question is just about requirements for the
"observer" behavior that you had asked about. Maybe I missed
it, but I didn't see anything in this document about observer
functionality. Before trying to complete an implementation,
it would be good to write down at least some of what you
think the requirements should be - again, from the point of
view of an implementor - to help judge various design
choices. This can be an iterative process if you like,
alternating back and forth between writing requirements and
implementing, but still it's good to try to get the
requirements down first rather than afterwards.

Does that make more sense now?

 

[jacob navia]

Le 24/11/10 10:29, Tim Rentsch a écrit :

An impressively large document (meaning the included
documentation ccl.pdf). I didn't have time to read it
thoroughly, but I did skim about 10 or 20 pages, and
looked through the table of contents.


My answer is in two parts.

A. Not as I meant the term, no. This document describes
externally visible behavior, but what I was asking about is
a statement of requirements from the point of view of an
implementor, that is, a more complete statement about what
attributes and properties, etc, must be observed in the
implementation. Externally visible behavior is one part of
that, but only part.

B. My original question is just about requirements for the
"observer" behavior that you had asked about. Maybe I missed
it, but I didn't see anything in this document about observer
functionality. Before trying to complete an implementation,
it would be good to write down at least some of what you
think the requirements should be - again, from the point of
view of an implementor - to help judge various design
choices. This can be an iterative process if you like,
alternating back and forth between writing requirements and
implementing, but still it's good to try to get the
requirements down first rather than afterwards.

Does that make more sense now?

(1) The motivation for the specifications should be part of the
document. What happened is that I had a long explanation about why it
is necessary to write and develop a container library in C, but then I
dropped it, leaving a few sentences in the "Introduction", in the
documentation.

I dropped it because I did not like a plaintive tone it had. There is
nothing to complain about, I should be positive and try to propose
solutions rather than complaining about stuff.

(2) A requirements document about the design principles that should
guide implementors is missing, and in that you are right.

For instance the sample implementation is EXTENSIBLE. If you respect
the abstract container interface you can write your OWN containers that
can be handled in the same manner as the described ones, adding some
functionality but basically allowing old code to call new code without
having to recompile or rewrite the old code. I have nowhere specified
this.

What the observers are concerned, you are again right. I have to develop
a short document that would specify what they should do, then code.

The problem is that I am used to iterate through code. I write a program
that solves something, then, thinking about it, I see some part missing,
write abstract specifications (sometimes) and then I arrive
at other, enhanced programs.

The advantage of this approach is that you see the problems that are
associated with the specifications you have in mind. The disadvantage
is that you can start into a wrong path quite easily, noticing it when
it is too late... Any modifications would make a lot of code obsolete.

For instance I started coding the containers without thinking about a
generic container class, that could be done simply by following a
specified order in the method pointers. I arrived at that conclusion
much later, and I had to rewrite ALL interfaces in the same manner, a
lot of work that could have been avoided if I had thought about making
an abstract container class before.

Thanks for your suggestion. I will try to follow it.

jacob

 

[Malcolm McLean]

(1) Add a slot to the header object. This is simple, but it would mean
     that this already heavy objects are bigger by sizeof(void *), not
     very exciting considering that in 99.99% of the case you are not
     going to use it.

If you have an object-oriented system, 'observable container' can be a
rare type of container. The central problem is that you don't want
"observable array", "observable hash" and so on. You want to be able
to specify that any container has the "observable" interface. Which
means that most Object-orientated systems won't work.

You need to chain observers in a linked list so that any number of
observers can be added or removed. Performance might be pathological
for very large lists of observers. You also need to decide whether
observers are allowed to modify the container. If you decide not, this
is maybe a whole new can of worms.

The interface is pretty simple. You add an observer function of the
form

int observerfunction(void *container, int action, void *actiondata,
void *ptr)

container is the container being observed, action is an enum (ADDED,
DELETED, SORTED), action data is a sturct giving details (index of the
item added, etc). The return type you can use to make the action fail
- if you return failure modes from your containers, as you presumably
do for add at least.
You need to decide whether the observer should be called before the
action, after it, or both.

ptr is essential. The observer must be able to pass an arbitrary
pointer to be called back with. Otherwise he has to resort to global
data and can't instantiate multiple observers with the same function.