... if that is true, then you don t even want the current class to be able to do it, so it is not a question of inheritance semantics, but simply some kind ofMessage 1 of 48 , Jan 1, 2009View SourceGeir Ove Skjaervik wrote:
>if that is true, then you don't even want the current class to be able
> Thanks, but I am afraid I do not understand what you mean. Attribute
> item_name_ is indeed accessible in all heirs (I tried it, and it
> I do not want heirs to assign directly to it as long as there is a
> set_item_name() for this purpose.
to do it, so it is not a question of inheritance semantics, but simply
some kind of protected status of a private attribute to be only settable
by a single 'set' routine (which probably ensures some other work is
done properly, not just the assignment). This capability doesn't exist
in Eiffel, but I have often thought it would be useful.
- thomas beale
Chief Technology Officer, Ocean Informatics
Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London
Hello, Thanks a lot for the helpful pointers! I will take a look at this as soon as I get the time! Geir Ove ... presentations ... slide= ) ... with ... slide=Message 48 of 48 , Jan 4, 2009View SourceHello,
Thanks a lot for the helpful pointers! I will take a look at this as
soon as I get the time!
--- In firstname.lastname@example.org, "halwebre" <halwebre@...>
> Hello Geir Ove,
> You may also be interested in two sections of the online
> on the eiffel.com website.slide= )
> First, slides 16 and 17 of "C# and Eiffel the Language" (at:
> attempt to contrast the C#/Java style of access to instance datawith
> Eiffel's style.slide=
> Second, slides 13 - 17 of "Design by Contract -- Part 2" (at:
> ) address reuse through the two relationships (client/supplier and
> inheritance) and try to explain the justification for allowing
> descendants to access inherited features and the use of design by
> contract to keep this safe.
> I hope these will be helpful.
> Best regards,