quick question on Oberon-2 
Author Message
 quick question on Oberon-2

A question on encapsulation in Oberon-2

In derived class (located in same module as the base class ), can
the type-bound procedures in derive class access and modify the

1. read-only data member ?
2. default members ? (not exported and not read-only)

Thanks.



Sun, 01 Jun 1997 00:21:15 GMT  
 quick question on Oberon-2

Quote:

>A question on encapsulation in Oberon-2

>In derived class (located in same module as the base class ), can
>the type-bound procedures in derive class access and modify the

>1. read-only data member ?
>2. default members ? (not exported and not read-only)

Wouldn't it have been easier to write a small little test module and
compile it?

But, the answer is: yes.

Taylor Hutt, World's Number 1 Winter Hater
Best Things about Winter: no pesky bugs and no birds pooping on your car.



Sun, 01 Jun 1997 20:24:09 GMT  
 quick question on Oberon-2

: >A question on encapsulation in Oberon-2
: >
: >In derived class (located in same module as the base class ), can
: >the type-bound procedures in derive class access and modify the
: >
: >1. read-only data member ?
: >2. default members ? (not exported and not read-only)

: But, the answer is: yes.

A rather more interesting question is, why the not exported members of
a data structure are not accesible in the derived class in an other module
i.e. all members of a data structure are either "public" or "private", but
there seems to be no way to declare them as "protected".

But why? To my mind all of the global inaccessible members should become
accessible when the base type is beeing extended.

Is Oberon too simple, or am i just wrong?

Jost



Wed, 04 Jun 1997 22:23:09 GMT  
 quick question on Oberon-2

 > A rather more interesting question is, why the not exported
 > members of a data structure are not accesible in the derived
 > class in an other module i.e. all members of a data structure
 > are either "public" or "private", but there seems to be no
 > way  to declare them as "protected".
 >
 > But why? To my mind all of the global inaccessible members
 > should become accessible when the base type is beeing
 > extended.

        Do you really want to force all of the inherited
fields in an extended type to be visible?  The programmer of
an extension could *very* easily corrupt the data by modifying
fields improperly -- that's why private fields are only
accessible to code in the same module (i.e., written by the
same person).  This is a little bit of "human engineering".
        As far as having the possibility of some "protected"
fields, it wouldn't have made sense in the original Oberon
language and probably didn't seem important to Moessenboeck
when he designed Oberon-2.  Can you show us examples where
this feature would be important?



Fri, 06 Jun 1997 06:47:44 GMT  
 quick question on Oberon-2


Quote:


>: >A question on encapsulation in Oberon-2
>: >
>: >In derived class (located in same module as the base class ), can
>: >the type-bound procedures in derive class access and modify the
>: >
>: >1. read-only data member ?
>: >2. default members ? (not exported and not read-only)

>: But, the answer is: yes.

>A rather more interesting question is, why the not exported members of
>a data structure are not accesible in the derived class in an other module
>i.e. all members of a data structure are either "public" or "private", but
>there seems to be no way to declare them as "protected".

>But why? To my mind all of the global inaccessible members should become
>accessible when the base type is beeing extended.

That's one way of thinking, but it's not the way Oberon does it.  If a
data member is exported as R/W, then it can be accessible otherwise it is
not.  The reasons are precisely what Mike described: the client could
corrupt an internal structure by invalidating an invariant.

The solution is to properly document the interface and the public items
of an exported type.

Would you please give an example where you would want to use a protected
mechanism in practice?

Taylor Hutt, protected by white {*filter*} cells
Carl Sagan's new book: _Pale Blue Dot_ has a really neat picture of Earth.



Fri, 06 Jun 1997 23:08:55 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Frage Oberon 3 / Question Oberon 3

2. Oberon-Growth-Limit was Re: Oberon: beginners questions

3. New Books on Oberon (Short summary: Three Questions on Oberon)

4. Quick, easy newbie question

5. Quick find replace question

6. Quick Question...

7. Quick listbox question

8. Quick Question

9. Mac Help quick question

10. two quick questions

11. Quick (I hope) question about max. window size

12. Quick question?

 

 
Powered by phpBB® Forum Software