Eiffel's attributes (was: Kent Beck's List) 
Author Message
 Eiffel's attributes (was: Kent Beck's List)

(Note: I'm cross-posting this from comp.object to comp.lang.eiffel)



Quote:

> >But I thought Eiffel didn't allow a client to an object to modify
data
> >members directly; ie

> >   class A feature
> >       in_a: INTEGER
> >   end

> >   class B feature
> >     do_b is
> >       local an_a: A
> >       do
> >          an_a.in_a := 1 -- Is a syntax error
> >       end
> >   end

> >Is this what you're talking about, or am I misinterpreting?

> INTEGER is an expanded type. Try this instead:

> class POINT
>    feature
>       x: INTEGER
>       y: INTEGER
>       set_x( new_x: INTEGER ) is
>          do
>             x = new_x
>          end
>       set_y( new_y: INTEGER ) is
>          do
>             y = new_y
>          end
> end

> class RECTANGLE
>    feature
>       top_left: POINT
>       bot_right: POINT
>    invariant
>       top_left.x <= bot_right.x
>       top_left.y <= bot_right.y
> end

> Now you can

> class A
>    feature
>       func is
>          local
>             rect: RECTANGLE
>          do
>             rect.top_left.set_x( 5 )
>             -- rect.top_left.x now equals 5
>             -- and we have broken RECTANGLE's invariant
>             -- without it knowing. *runtime error*
>          end
> end

> Note: you could not do the above if top_left was a calulation instead
of
> a reference to an object, or if top_left and bot_right were expanded.

> I'm not saying the C++ is universally better by a long shot! I just
> think that Eiffel would benifit greatly if it allowed const in some
> meaningful way.

Interesting. I had to play around with your example some, but you're
right, if I top_left is a function of RECTANGLE, then calling set_x
does trigger the invariant, whereas before it did not.

So do you think the enforcement should be done by the compiler, or
handled explicitly by the programmer with some new syntax? For this
particular case, it seems to me that the compiler could add the
invariant check after each access of a feature, regardless of whether
or not it's a data attribute or a function. That would argue for the
problem really being an implementation issue, not of the language
itself. But is that sufficient for the general case?

Greg

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

Sent via Deja.com
http://www.*-*-*.com/



Tue, 29 Jul 2003 05:32:18 GMT  
 Eiffel's attributes (was: Kent Beck's List)
(The post that I'm responding to is a response to something that I
posted in comp.object. I would like to reiterate it here.)

OOSC2 talks about the Uniform Access principle. Its main aim is that a
uniform notation be used "which does not betray whether they are
implemented through storage or through computation."

However, the part in quotes requires more than just a uniform notation.

class A
feature
   x: INTEGER
   change_x( new_x: INTEGER ) is do
      x := new_x
   end
end

class B
feature
   value: A
end

Now supposedly, the client cannot tell if 'value' returns a reference to
a stored value in B or if it computes the value on demand. That way one
can change back and forth. However, with the above a client can do this:

procedure( obj: B ) is
local
   sub_obj: A
do
   sub_obj := obj.value
   sub_obj.change_x( 12 )
end

and thereby change the state of 'obj'. If the programmer of 'B' then
changes 'value' to a computation, 'procedure' breaks. This forces the
client to know if value is implemented through storage or through
computation, which destroys the whole reason for the Uniform Access
principle!

One can fix this by only returning expanded types (emulate C++'s return
by value) but then we are forcing the system to create a new 'A' object
every time someone calls 'value' on 'B'. This may be very expensive.

C++ gets around this by allowing 'B's programmer to return a "const
reference". This way, the client of 'B' cannot call 'change_x' on
'value' and therefore cannot know if 'value' is computed or stored.



Tue, 29 Jul 2003 11:22:44 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. freeware: GemStone/S port of Kent Beck's Testing Framework

2. Kent Beck's remarks

3. Kent Beck's testing framework

4. need Kent Beck's drawing editor

5. [VW] Any one have Kent Beck's Object Explorer on 5i

6. Looking for contact information for Kent Beck

7. XP Immersion Training with Kent Beck

8. INFO: KENT BECK ...help

9. Kent Beck speaks in Chicago 4-17-95

10. Kent Beck testing framework

11. Kent Beck Patterns Book

12. Test-Driven Dev. (Kent Beck) Python Chapter Question

 

 
Powered by phpBB® Forum Software