Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Implementing an observer

Reply
Thread Tools

Implementing an observer

 
 
Tim Rentsch
Guest
Posts: n/a
 
      11-24-2010
jacob navia <(E-Mail Removed)> writes:

> Le 23/11/10 00:39, Tim Rentsch a @C3{A9}crit :
>
>> Are you going to offer any kind of statement of requirements?
>> If not, I suggest the first order of business is to formulate
>> one.

>
> 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).
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      11-24-2010
Le 24/11/10 07:33, Tim Rentsch a écrit :
> jacob navia<(E-Mail Removed)> writes:
>
>> Le 23/11/10 00:39, Tim Rentsch a @C3{A9}crit :
>>
>>> Are you going to offer any kind of statement of requirements?
>>> If not, I suggest the first order of business is to formulate
>>> one.

>>
>> 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).


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.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      11-24-2010
jacob navia <(E-Mail Removed)> writes:

> Le 24/11/10 07:33, Tim Rentsch a @C3{A9}crit :
>> jacob navia<(E-Mail Removed)> writes:
>>
>>> Le 23/11/10 00:39, Tim Rentsch a @C3{A9}crit :
>>>
>>>> Are you going to offer any kind of statement of requirements?
>>>> If not, I suggest the first order of business is to formulate
>>>> one.
>>>
>>> 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).

>
> 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?
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-24-2010
Le 24/11/10 10:29, Tim Rentsch a écrit :
> jacob navia<(E-Mail Removed)> writes:
>
>> Le 24/11/10 07:33, Tim Rentsch a @C3{A9}crit :
>>> jacob navia<(E-Mail Removed)> writes:
>>>
>>>> Le 23/11/10 00:39, Tim Rentsch a @C3{A9}crit :
>>>>
>>>>> Are you going to offer any kind of statement of requirements?
>>>>> If not, I suggest the first order of business is to formulate
>>>>> one.
>>>>
>>>> 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).

>>
>> 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?


(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


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      11-25-2010
On Nov 19, 1:00*am, jacob navia <(E-Mail Removed)> wrote:
>
> (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.




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Implementing the observer pattern in C jacob navia C Programming 3 03-29-2011 06:48 AM
implementing mvc - using observer pattern - beginner to OOP Adam Akhtar Ruby 8 11-11-2008 01:31 PM
Observable, Observer and recursive update() problem Rogan Dawes Java 4 06-11-2004 02:34 PM
Observer/Observable: update not called Timo Nentwig Java 1 04-16-2004 04:21 PM
Why don't Listeners use Observer/Observable Timo Nentwig Java 1 10-27-2003 04:13 PM



Advertisments