Constant objects (Was: Proposal: cleanup manifest strings!)
Author |
Message |
Alexei V. Kanato #1 / 11
|
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 |
|
|
Alexei V. Kanato #2 / 11
|
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 |
|
|
Nick Leato #3 / 11
|
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 |
|
|
Alexei V. Kanato #4 / 11
|
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 |
|
|
Alexei V. Kanato #5 / 11
|
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 |
|
|
Nick Leato #6 / 11
|
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 |
|
|
Alexei V. Kanato #7 / 11
|
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 |
|
|
Nick Leato #8 / 11
|
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 |
|
|
Alexei V. Kanato #9 / 11
|
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 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 |
|
|
Nick Leato #10 / 11
|
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 |
|
|
Joachim Durchhol #11 / 11
|
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 |
|
|
|