Method : what to ensure after creation ? 
Author Message
 Method : what to ensure after creation ?

Quote:
> 1) Nothing, rely on class invariants
>    My thought : moves the problem to the class invariants, doesn't
>    show the fact of only partly initialization.

Class invariants are normally describing change-invariantproperies of
instances. So if your ensure condition describes
a general quality of the instances it is maybe better described
by the invariant.

Quote:
> 2) The value of the non-void features
>    My thought : pretty good , not too much typing (GRIN)
> 3) The value of every attribute be it void or non-void
>    My thougt : Hard to maintain, when attributes change to routines

There is one strategy in science which is quite interesting: to tellthe truth
but not more than the truth. Or in other words: dealing only
with positiv points in the sense of what is relevant concerning a
question. So I would focus only on the qualities of objects which are
used: to restrict what exists.

Maybe there was something which helped. Otherwise I would be
very glad to be corrected.

Many greetings,
Christoph



Sun, 03 Dec 2000 03:00:00 GMT  
 Method : what to ensure after creation ?


Quote:
>Hello everybody, I have a methodical question regarding the best style of
>'ensure' clauses to be placed in a creation routine of a class . I plan to
>use a make_with_default(x:y;...) creation feature, which initializes only
>some of several attributes.

    At first I'd like to say that creation procedure is an ordinary
procedure and its postcondition clause has the same semantics as ensure
clause of any other rouitine. In general when we have !!x.creation_procedure
we can split it (logically) into 3 steps create object and attach it to x,
switch off class invariant checks, call creation_procedure  with invariant
check after. So, ensure in general should state that the contract is
fullfilled. Creation procedure has it own contract and ensure has to
garantee that the proper actions were performed in the body of the
procedure. If 'contract validity expression' is covered by invariant you can
miss ensure, but it is better to duplicate assertions. In practice we can
perform (and do perform) a flexible control over assertions enabled and
disabled and that it is why it is better to think about each element of the
class separately. Assume that we have only one feature and express it
assertions, then take a class and express its invariant. Such approach will
allow to be more safe, esspecially for large systems when selective
assertions control is often used.

Alexei Kanatov
--

Object Tools                http://www.object-tools.com

  Alexei V. Kanatov.vcf
< 1K Download


Mon, 04 Dec 2000 03:00:00 GMT  
 Method : what to ensure after creation ?

Quote:
>I plan to use a make_with_default(x:y;...) creation feature, which
>initializes only some of several attributes.

>What shall I ensure ? I see the following options
>1) Nothing, rely on class invariants
>   My thought : moves the problem to the class invariants, doesn't
>   show the fact of only partly initialization.
>2) The value of the non-void features
>   My thought : pretty good , not too much typing (GRIN)
>3) The value of every attribute be it void or non-void

Creation routines are closely tied to class invariants --
they are the only features which are not required to
test the invariant at entry, only at exit. This implies that
their only *required* functionality is to establish the
invariant. So, any conditions which this code is
intended to establish should be part of the invariant,
not of an 'ensure' clause.

It's often both possible and convenient to do additional
initialization work in a creation feature, beyond what
is necessary to establish the invariant. This work *could*
be factored out in a completely separate non-creation
feature instead, but it might be convenient just to do
everything at once. Conditions which don't make the
object 'invalid' but do specialize it for some purpose
should be asserted in an 'ensure' clause, then.

Note that, if you have several different creation
routines which establish *very* different initial
ensure conditions  while sharing a common
invariant, you might be better off making the
invariant stuff a base class and inheriting it
into several different class types instead.

Hope this helps.



Thu, 07 Dec 2000 03:00:00 GMT  
 Method : what to ensure after creation ?

Quote:

> Hello everybody, I have a methodical question regarding the best style of
> 'ensure' clauses to be placed in a creation routine of a class . I plan to
> use a make_with_default(x:y;...) creation feature, which initializes only
> some of several attributes.

You should design the class with invariants in mind before the creation
routine. Then design one or more creation routines. They all have to
satisfy the invariant.

If you want a make_default creation routine, and it only takes a couple
of parameters, you have to be sure that it can still initialise the
object to a state which you regard as valid in the wider system.

On the question of what to ensure:
a) ensure those things not covered by the invariant
b) consider ensuring some things that are covered by the invariant,
since the invariant doesn't say everything. Example:

feature -- Initialisation
        make(a_name:STRING) is
                do
                        name := a_name
                ensure
                        name = a_name
                end

feature -- Access
        name:STRING

invariant
        name /= Void                    

The trivial "name = a_name" post-condition ensures that name refers to
the same object as a_name; it could have been "name.is_equal(a_name)".
The invariant can't make this distinction, since it has no reference to
a_name. Now, this is a trivial example with strings; it will be more
interesting with "real" objects.

- thomas beale



Fri, 08 Dec 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. using rescue/ensure in methods

2. Another take on ensuring right args to methods

3. Q: Ensuring Presence of Method Implementation? (Newbie)

4. ENSURE-GENERIC-FUNCTION and method combinations?

5. How to ensure that a method is compiled?

6. Method creation

7. Creation methods and VAPE

8. Cyclic Marshals :: again the need for a built in creation parent method

9. Dynamic creation of classes and methods

10. dynamic method creation

11. Method creation question

12. automatic method creation

 

 
Powered by phpBB® Forum Software