headers
Bertrand Meyer | 1 Jan 2009 07:55
Picon

RE: What good is a create expression as an assignment target?

Dear Greg:

The language definition also allows you to write the assignment

      x := x

and the routine declaration

      r do r end

neither of which seems to have exciting applications.

A language design should make the useful expressible. If you know one that
makes all expressible programs useful please tell us, you will get
considerable interest.

With best regards,

-- BM

From: eiffel_software@...
[mailto:eiffel_software@...] On Behalf Of Greg C
Sent: Wednesday, December 31, 2008 23:39
To: eiffel_software@...
Subject: [eiffel_software] What good is a create expression as an assignment
target?

Hello,

While browsing through the ECMA standard, I noticed that the following
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Beale | 1 Jan 2009 18:33

Re: Re: Hiding implementation from heirs

Geir Ove Skjaervik wrote:
 >
 > Hello,
 > 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
 > compiles).
 >
 > I do not want heirs to assign directly to it as long as there is a
 > set_item_name() for this purpose.
 >

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 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

--

-- 
    Thomas Beale
Chief Technology Officer, Ocean Informatics

Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London

------------------------------------
(Continue reading)

Permalink | Reply | 14 comments |
headers
Emmanuel Stapf [ES] | 1 Jan 2009 18:44
Favicon

RE: Re: Hiding implementation from heirs

> 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 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.

Even if you do not have this facility in the language, EiffelStudio can tell you
all the assigner of an attribute. So when you want this pattern, simply make sure
there is only one assigner.

Regards,
Manu

------------------------------------
Permalink | Reply | 1 comment |
headers
Thomas Beale | 1 Jan 2009 18:53

Re: Re: Hiding implementation from heirs

Emmanuel Stapf [ES] wrote:
 >
 > > 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 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.
 >
 > Even if you do not have this facility in the language, EiffelStudio 
can tell you
 > all the assigner of an attribute. So when you want this pattern, 
simply make sure
 > there is only one assigner.
 >

yes, that's true of course, I should have mentioned that - I often use 
that facility to check what the assigners are.

- thomas

--

-- 
    Thomas Beale
Chief Technology Officer, Ocean Informatics

Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London

------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geir Ove Skjaervik | 1 Jan 2009 20:50
Picon
Picon

Re: Hiding implementation from heirs

Hello,
On page 505 in OSSC 2.edition Meyer talks about "Progrmas with 
holes" and outlines how libraries with deferred classes / routines 
may be extended. As I said to "colinlema" in this thread:

"Briefly my concern is that reuse should not only be possible 
from "uses" clients, but also from "is" clients (ancestors). "

And this is in the spirit of what Meyer himself outlines as far as I 
can see.

Now: Why should we be able to hide implementation clutter 
from "uses" clients, but not from "is" clients (ancestors)?

The problem is the same: We do not want users to mess with features 
that should not be touched! 

Even when I write a complete Hierarchy of classes myself, I see the 
problem: Yes, I may of course even abuse set_features (by assigning 
directly to the attribute itself) in class A itself when I implement 
it, but the chances are much greater that I mess up by abusing 
exposed features in A when I much later implement class B that 
inherits from A. 

And what about reuse by "is" relations of classes hiearchys written 
long time ago?  Extending certain widgets in the Vison2 library can 
be really daunting: It exposes a myriad of features that I most 
probably should not touch! This is actually hampering "is" reuse, 
not empowering it in my opinion.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Paul Cohen | 1 Jan 2009 21:13
Picon

Re: Re: Hiding implementation from heirs

Hi

On Thu, Jan 1, 2009 at 8:50 PM, Geir Ove Skjaervik <geiroves@...> wrote:
> The problem is the same: We do not want users to mess with features
> that should not be touched!

I have not followed the entire discussion in detail, but features can
be declared as "frozen" to protect descendants from messing with them.
 But this language mechanism does not seem to be used that often as it
could be.

/Paul

--

-- 
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: paul.cohen@...

------------------------------------
Permalink | Reply | 9 comments |
headers
Geir Ove Skjaervik | 1 Jan 2009 22:15
Picon
Picon

Re: Hiding implementation from heirs

Hello,
Frozen will only stop one from changing a feature, not using a 
feature that should not be used (it should have been private) 
outside the class (by ancestors)

Geir Ove

--- In eiffel_software@..., "Paul Cohen" 
<pacoispaco <at> ...> wrote:
>
> Hi
> 
> On Thu, Jan 1, 2009 at 8:50 PM, Geir Ove Skjaervik <geiroves <at> ...> 
wrote:
> > The problem is the same: We do not want users to mess with 
features
> > that should not be touched!
> 
> I have not followed the entire discussion in detail, but features 
can
> be declared as "frozen" to protect descendants from messing with 
them.
>  But this language mechanism does not seem to be used that often 
as it
> could be.
> 
> /Paul
> 
> -- 
> Paul Cohen
(Continue reading)

Permalink | Reply | 8 comments |
headers
colinlema | 1 Jan 2009 22:27
Picon

Re: Hiding implementation from heirs

It should also be noted that export status doesn't disallow access to
a feature from clients.

class C
feature {ANY}
thing: INTEGER
end

class D
inherit C
export {NONE} thing end
end

If you have a D you can't access `thing', but if you assigned it to a
C you could then access `thing'.

The export mechanism is *purely* a convenience hiding mechanism not a
prevention mechanic. Contracts are used to ensure correct usage.

--- In eiffel_software@..., "Geir Ove Skjaervik"
<geiroves <at> ...> wrote:
>
> Hello,
> On page 505 in OSSC 2.edition Meyer talks about "Progrmas with 
> holes" and outlines how libraries with deferred classes / routines 
> may be extended. As I said to "colinlema" in this thread:
> 
> "Briefly my concern is that reuse should not only be possible 
> from "uses" clients, but also from "is" clients (ancestors). "
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Cohen | 1 Jan 2009 22:44
Picon

Re: Re: Hiding implementation from heirs

Hi

On Thu, Jan 1, 2009 at 10:15 PM, Geir Ove Skjaervik
<geiroves@...> wrote:
> Frozen will only stop one from changing a feature, not using a
> feature that should not be used (it should have been private)
> outside the class (by ancestors)

Ok. To me that does not make any sense when you are talking about
conventional inheritance (type conformance). However it could be
interesting in cases of implementation inheritance (non type
conformant inheritance).

In the case of conventional inheritance you are specializing a class
and extending the type hierarchy. The only restraining conditions for
this should be the inherited specification, ie. the contracts.

In the case of implementation inheritance, you are simply making a set
of features accessable in your new class without the need for a
particular object reference. In this case a point *could possibly* be
made for being able to restrict the use of certain features in
descendant classes.

However, I am personally wary of introducing more language mechanisms,
that don't have an extremely strong rationale. In the case of
conventional inheritance where you have lots of available features and
you're not sure of how to use them I would say; read the contracts,
read the code and read the documentation!

/Paul
(Continue reading)

Permalink | Reply | 7 comments |
headers
Geir Ove Skjaervik | 1 Jan 2009 23:01
Picon
Picon

Re: Hiding implementation from heirs

Hello,
Well, in the ideal case, we have both source code and documentation. 
In the real world? Where I come from that's not the case.

Anyway, I think I have found a pattern that I will personally use:
I hate it, but it will sort of "solve" the problem for code that ** 
I ** write: I will prefix features I consider "private" to a class 
with an underscore, signalling that "you may break contracts" if you 
use this feature!

While on the contract subject: I do not like accessing attributes 
directly at all: There is no way to "diretcly" assign any contracts 
(pre- or postconditions to them): Reading the contact, they will not 
state anything. Of course, the class Invariant may ensure their 
correct values and thus usage, but it is far more "indirect" way of 
stating how the atrributes should be used.

Geir Ove

--- In eiffel_software@..., "Paul Cohen" 
<pacoispaco <at> ...> wrote:
>
> Hi
> 
> On Thu, Jan 1, 2009 at 10:15 PM, Geir Ove Skjaervik <geiroves <at> ...> 
In the case of
> conventional inheritance where you have lots of available features 
and
> you're not sure of how to use them I would say; read the contracts,
> read the code and read the documentation!
(Continue reading)

Permalink | Reply | 6 comments |

Gmane