Constant objects (Was: Proposal: cleanup manifest strings!) 
Author Message
 Constant objects (Was: Proposal: cleanup manifest strings!)

Looking at discussion about manifest strings I always feel that we need a
general mechanism not only for STRING but for any Eiffel object to be
constant by value not by reference. Now we have only 5 Eiffel classes for
which we can specify constants by value (INETGER, REAL, DOUBLE, CHARACTER
and BIT), all these classes are expanded and part of the Kernel library and
moreover wellknown by compilers internally. (remember great example like
(5).copy (6)  or x: INETEGER is 5 and then x.copy (6); print (x) ). Let's
make one small step forward and introduce constant objects in a way similar
to once functions

    constant_object: ITS_TYPE is
        frozen -- we do not need to introduce a new keyword - frozen shows
semantics rather well - does not it ?
            -- initialization
        end

    In general
        <feature_names> [<arguments>] : <type> is
            frozen
                <instructions>
            end

    frozen can be defined semantically in a way similar to the following
postondition clause
        frozen ~ ensure Result.is_deep_equal (old Result) !!! It is not a
real Eiffel it is just a short way to express semantics

    So, we can rely on the idea that frozen is checked by run-time when
posconditions are on (or we can have a separate control for contants checks)
and when we access constant object run-time has to compare inital values and
values after the end of the call based on constant object. This will cause
some performance penalties but this will be at debugging time and there is
no difference between assertions and constants objects support.

For example:
        constant_string: STRING is
            frozen
                Result := "bla-bla-bla"
            end
        ...
            constant_string.copy ("new string") -- will cause exception -
could be postcondition violation or better constant object violation
            constant_string.put ('!', 1) -- exception again

    Any comments ?

Regards,
Alexei

--
--

Object Tools                 http://www.*-*-*.com/



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Important addition.

Quote:
>    frozen can be defined semantically in a way similar to the following
>postondition clause
>        frozen ~ ensure Result.is_deep_equal (old Result) !!! It is not a
>real Eiffel it is just a short way to express semantics

    If we have a feature call based on constant object run-time has to make
a deep-copy of the constant object before performing the call and call
is_deep_equal after success of the call.

    constant_object.some_feature (some_arguments)

    Run-time behaviour

        if check_assertions_level (?) then
            buffer := deep_clone (constant_object)
        end
        do_call some_feature
        if check_assertions_level (?) and then not buffer.is_deep_equal
(constant_object) then
            raise ("Constant object violation")
        end
    -- This is not real Eiffel ...

Alexei



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:

> Important addition.

> >    frozen can be defined semantically in a way similar to the following
> >postondition clause
> >        frozen ~ ensure Result.is_deep_equal (old Result) !!! It is not a
> >real Eiffel it is just a short way to express semantics
>     If we have a feature call based on constant object run-time has to make
> a deep-copy of the constant object before performing the call and call
> is_deep_equal after success of the call.

>     constant_object.some_feature (some_arguments)

>     Run-time behaviour

>         if check_assertions_level (?) then
>             buffer := deep_clone (constant_object)
>         end
>         do_call some_feature
>         if check_assertions_level (?) and then not buffer.is_deep_equal
> (constant_object) then
>             raise ("Constant object violation")
>         end
>     -- This is not real Eiffel ...

But it is not a good definition of constness. I think you really want to
know
that all the queries on the object are the same before and after.

This enables you to implement logical constness, for example a complex
number whose
internal representation changes, but externally does not.

Then comes the question, can you implement it efficiently?

--

Nick



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:

>But it is not a good definition of constness. I think you really want to
>know
>that all the queries on the object are the same before and after.

    Let's find a good one ;-) If to define constant object as an object
which has all data attributes recursively contain the same values during all
life-time of this object.
    I think that it is not necessary to look at queries as smth different -
we have a feature call notion, and then constant object preserves its values
recursively after each successfull feature call.

Quote:
>Then comes the question, can you implement it efficiently?

    My answer - we do not need to implement it efficiently :-) We can ask
for assertions to be implemented efficiently but it is not the main target
of assertions. Constant object is a kind of assertions and all implication
related with assertions are applicable to constant objects. Definitely we
will get performance degrade, but we need this to protect ourself, nobody
will say that assertions are bad due to negative performance change. The
main idea to be safe and then the second one how to implement it with less
losses of performance.

Alexei



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)
One more addition :-)
1. All sub-objects of the constant object are also constant objects. It
means if a sub-object was selected from the constant object and passed into
other place it will keep its constness status. This will allow to preserve
constness of the father object. If object is cloned then ... ??? I think
that we can clear the constness status in this situation.

2. To some extend constness status of the object can be treated as an
invariant extension of the class like
        Current.is_deep_equal (old Current) !!! It is not Eiffel again ...

Alexei



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:


> >But it is not a good definition of constness. I think you really want to
> >know
> >that all the queries on the object are the same before and after.

>     Let's find a good one ;-) If to define constant object as an object
> which has all data attributes recursively contain the same values during all
> life-time of this object.
>     I think that it is not necessary to look at queries as smth different -
> we have a feature call notion, and then constant object preserves its values
> recursively after each successfull feature call.

What about the complex number example? A complex number could be
represented
as a + b i or as r e ^ i theta, and depending on what you want to do,
you have
a preference for one of the forms. Addition wants a cartesian
representation,
multiplication a polar representation. So you have queries that return
a, b, r,
and theta, and two representation variables and a flag saying which is
in use,
private. If I multiply a number with a cartesian representation, it
converts,
without me knowing to a polar representation. However, as far as I am
concerned
the operation is const, it doesn't change the object as I see it. a, b,
r and theta
stay the same, but the private data doesn't change.

--

Nick



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:

>What about the complex number example? A complex number could be
>represented
>as a + b i or as r e ^ i theta, and depending on what you want to do,
>you have
>a preference for one of the forms. Addition wants a cartesian
>representation,
>multiplication a polar representation. So you have queries that return
>a, b, r,
>and theta, and two representation variables and a flag saying which is
>in use,
>private. If I multiply a number with a cartesian representation, it
>converts,
>without me knowing to a polar representation. However, as far as I am
>concerned
>the operation is const, it doesn't change the object as I see it. a, b,
>r and theta
>stay the same, but the private data doesn't change.

    If the function changes the object itself it means that this object
could not be a constant one. If you need to have a constant object you have
to apply non-side-effect scheme where each query will not change the object
itself, just perform all necessary actions to evaluate a result.

    c1: COMPLEX is
        frozen
            !! Result.make (1,1)
        end
    c2: COMPLEX is
        frozen
            !! Result.make (2,3)
        end
    c3: COMPLEX

    c3 := c2 * c1 -- that is all. Addition or multiplication are infix
oparators - they should not change Current either argument.

If some desing schemes do not accept usage of constant objects it is not a
problem - just do not use constants objects due to side-effects introduced
in desing scheme. The main idea of constant object is to garantee the
constness of object data during execution time.

Regards,
Alexei



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:


> >What about the complex number example? A complex number could be
> >represented
> >as a + b i or as r e ^ i theta, and depending on what you want to do,
> >you have
> >a preference for one of the forms. Addition wants a cartesian
> >representation,
> >multiplication a polar representation. So you have queries that return
> >a, b, r,
> >and theta, and two representation variables and a flag saying which is
> >in use,
> >private. If I multiply a number with a cartesian representation, it
> >converts,
> >without me knowing to a polar representation. However, as far as I am
> >concerned
> >the operation is const, it doesn't change the object as I see it. a, b,
> >r and theta
> >stay the same, but the private data doesn't change.
>     If the function changes the object itself it means that this object
> could not be a constant one. If you need to have a constant object you have
> to apply non-side-effect scheme where each query will not change the object
> itself, just perform all necessary actions to evaluate a result.

But its appearance as far as I am concerned is unchanged. If a multiply
a and b
giving c  (shades of cobol!) I would expect that a is constant. In the
reasonable
example I have given, it isn't under your scheme.

Quote:
>     c1: COMPLEX is
>         frozen
>             !! Result.make (1,1)
>         end
>     c2: COMPLEX is
>         frozen
>             !! Result.make (2,3)
>         end
>     c3: COMPLEX

>     c3 := c2 * c1 -- that is all. Addition or multiplication are infix
> oparators - they should not change Current either argument.

Why not? If it is more efficient to change the representation so long as
I don't
change the external appearance? It is how I might want to implement the
solution. The
interface doesn't change.

Quote:
> If some desing schemes do not accept usage of constant objects it is not a
> problem - just do not use constants objects due to side-effects introduced
> in desing scheme. The main idea of constant object is to garantee the
> constness of object data during execution time.

But it can give the wrong impression. See above.

What about inheritance?

--

Nick



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:

>But its appearance as far as I am concerned is unchanged. If a multiply
>a and b
>giving c  (shades of cobol!) I would expect that a is constant. In the
>reasonable
>example I have given, it isn't under your scheme.

    I have nothing against different implementations of class COMPLEX, it
could be 2 INTEGERS, 4 INTEGERS, 4 INTEGERS with BOOLEAN flag, may be some
others. I'd rather prefer not to go into deep discussion of how to implement
class COMPLEX, my initial intention was to step forward with a proposal of
constant object (instead of MUTABLE, RESIZABLE or any kind of STRING :-).
Constant object is constant by itslef - there is not realtion with internal
or external representation of an object.

Quote:
>> If some desing schemes do not accept usage of constant objects it is not
a
>> problem - just do not use constants objects due to side-effects
introduced
>> in desing scheme. The main idea of constant object is to garantee the
>> constness of object data during execution time.

>But it can give the wrong impression. See above.

    I am very sorry that my proposal can give a wrong impression. But it was
not a formalized proposal with all validity rules, syntax and exact
semantics ...

Quote:

>What about inheritance?

    What do you mean ?
    Constant objects are very close to once functions and I think that they
should not be 'redefinable' - they are constants.

Alexei



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:


> >But its appearance as far as I am concerned is unchanged. If a multiply
> >a and b
> >giving c  (shades of cobol!) I would expect that a is constant. In the
> >reasonable
> >example I have given, it isn't under your scheme.

>     I have nothing against different implementations of class COMPLEX, it
> could be 2 INTEGERS, 4 INTEGERS, 4 INTEGERS with BOOLEAN flag, may be some
> others. I'd rather prefer not to go into deep discussion of how to implement
> class COMPLEX, my initial intention was to step forward with a proposal of
> constant object (instead of MUTABLE, RESIZABLE or any kind of STRING :-).
> Constant object is constant by itslef - there is not realtion with internal
> or external representation of an object.

> >> If some desing schemes do not accept usage of constant objects it is not
> a
> >> problem - just do not use constants objects due to side-effects
> introduced
> >> in desing scheme. The main idea of constant object is to garantee the
> >> constness of object data during execution time.

> >But it can give the wrong impression. See above.
>     I am very sorry that my proposal can give a wrong impression. But it was
> not a formalized proposal with all validity rules, syntax and exact
> semantics ...

> >What about inheritance?
>     What do you mean ?
>     Constant objects are very close to once functions and I think that they
> should not be 'redefinable' - they are constants.

Maybe I got the wrong end of the stick. ;-)

Did you mean const in the C++ sense, as not modified by me when passing
a parameter?
That is, const type means 'type' without any procedures (recursively)?

Have a look through deja news. The topic has come up before, not
surprisingly as it
seems so obvious. However, no one came up with a good definition, appart
from a function
having a postcondition that the results of all queries in the object are
preserved.

--

Nick



Sun, 01 Apr 2001 03:00:00 GMT  
 Constant objects (Was: Proposal: cleanup manifest strings!)

Quote:

> One more addition :-)
> 1. All sub-objects of the constant object are also constant objects.

OK, now what is a subobject? How's the status of referenced objects?

I don't think 'const' alone is what we need. I think we need a way to
specify constant aspects - that's much more useful.

Another thought: constness is intimately related to equality. I haven't
seen a good definition of equality yet - we usually aren't interested in
equality but in equivalence (and different clients are often enough
interested in different forms of equivalence).

Solve equality, and you'll get a good idea of constness as well.

Regards,
Joachim
--
Please don't send unsolicited ads.



Sun, 01 Apr 2001 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Proposal: cleanup manifest strings!

2. manifest constants

3. Wanted: Manifest String extension

4. Manifest STRINGs

5. Proposal v2 /was: Standardising string primitives (was: Re: String)

6. Proposal: S>UPPER etc /was: Standardising string primitives (was: Re: String)

7. Proposal: Add constants to Math

8. Order of object cleanup at interpreter exit?

9. Tcl-DP object cleanup problem

10. Assigning to string object in Object Rexx

11. string object methods vs string module functions

12. Defining string constant with ASCII Code Under 32

 

 
Powered by phpBB® Forum Software