headers
Wyden Silvan | 1 Mar 2009 07:15
Picon
Favicon

Re: Server/Client problems

Hello Roger

Thanks for your answer. I know that the example was not very good. But my aime was to understand the
mechanisme of the eiffel fault managment with rescue and retry. Is there any good documentation about that?

We are getting away from the main subject. My problem is that there always apears an error when I tried to
connect via TCP/IP to a server that isn't up. I make the connection via the NETWORK_STRAM_SOCKET and with
the feature connect. And there is a rescue and retry mechanisme but why doens't it work?

Hope that somebody can help me.

Regards Wyden S.

________________________________
From: "rfo@..." <rfo@...>
To: eiffel_software@...
Sent: Saturday, February 28, 2009 3:15:16 PM
Subject: RE: [eiffel_software] Server/Client problems

Hello Wyden!

If you know the file does not exist at that point (you don't really, but
that's a separate issue), why are you trying again?
I think you must be taking the example too literally.
If what you want is to fail gracefully when an expected file does not
exists, then simply report that and fall through to exit.
If what you want is to check for the existence of a file for some normal
logic path, then use your logic, not the exception mechanism.
It is not uncommon for some programmers to blur the distinction between
exceptions and normal logic. Please don't do that. If you think of an
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfo | 1 Mar 2009 14:08

RE: [eiffel_software] Server/Client problems

Hello Wyden!

I guess I have to answer your question with another question.
How do you know it doesn't work?
Typically, one would check the nature of the exception in this case. 
There might be a different reason for the exception than the one you
expect.  You can, for example, check to see if it's a signal exception
and do one thing, but if it's an IO exception, do another, etc.  Have a
look at the EXCEPTIONS class.

The retries are excecuted immediately, so there is little chance of
things changing in between attempts.
To introduce delays, you would use a layer above the open/read routine
that waits between attempts and checks the result of each, putting in a
sleep or equivalent.

f1
  local
    tries: INTEGER
  do
    from f2
    until done or gave_up
    loop
      if not done then
        tries := tries + 1
        if tries > max_tries then
          -- give up
        else
          -- delay
          f2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rosivaldo Fernandes Alves | 1 Mar 2009 20:24
Picon
Favicon

How to prevent contract breaking due to aliasing

Although OO allows to encapsulate things inside a class and Eiffel contracts 
help to ensure class correction, I'd like to know a general strategy for 
preventing contract breaking due to aliasing. Ok, a client can't directly 
assign a value to an attribute, but if it can get a reference to the 
attribute, as is usually possible, the state of that attribute may be 
changed in a way to break the supplier class contract. Ok again, perhaps the 
supplier class should not give access to an attribute whose state shouldn't 
be tweaked by clients, but when it is necessary, what should be done? Give 
to clients an attribute's twin? worst: a deep_twin? What about space/time 
efficiency? Even worse for container classes that may need to rely on their 
contents, not only on their internal structure, to keep correctness, as the 
example below illustrates.

Functional languages, like Haskell, use to prevent all of this by forbidding 
any aliasing at all. How an OO language like Eiffel treats this matter?

Thanks for any help,

Rosivaldo.

P.S.: Below are two classes to illustrate my point.

class
 APPLICATION

inherit
 ARGUMENTS

create
 make
(Continue reading)

Permalink | Reply | 7 comments |
headers
rfo | 1 Mar 2009 22:30

RE: [eiffel_software] How to prevent contract breaking due to aliasing

Hello Rosivaldo!

The problem you are trying to solve is not aliasing exactly, but it is a
problem.

Whenever a query of a class yields a reference type, the features of
that reference type are available to the receiver.  This is the law of
the universe, the jungle, and just about everything else.

The example you cite is a string.  What you want is to treat these
objects as _values_, and not as _references_.  That is not what they
are, but I sympathize.

While this is not FORTRAN, you still can do something like that by using
an IMMUTABLE_STRING, as discussed at great length in an earlier thread.

For non-STRINGs, there is no 'constancy' characteristic orthogonal to
type.  I have urged members of this forum to consider this, but never
heard a peep from anyone.  Why, I don't know.  Maybe I'm off my nut on
this one, but to me, such a characteristic would be quite helpful in
cases like this.

There is another rather easy way to accomplish what you want (sort of),
using classes and assertions.  You can create a kind of 'handle' class
that holds the original reference but has a class invariant that asserts
the value of that reference never changes.  What bothers me most (there
are plenty of candidates) about this is that we are creating a do-er
class.  I have seen some serous abuses coming from this approach.  I
have coined this kind of thinking as 'POOP' - Procedure-oriented object
programming :)  Still,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Helmut Brandl | 1 Mar 2009 22:39
Picon

Re: How to prevent contract breaking due to aliasing

Hello Rosivaldo,

you raised a good point that puzzles me a lot as well.

Usually it should not be possible for a client to break the invariant of
a supplier, but if the supplier is not very carefully designed with
respect to aliasing a client can break the invariant of a supplier.

The simplest example I could come up to demonstrate the problem is a
class SORTED_SEQUENCE[G->COMPARABLE]. As its name says the obvious
invariant is that all the elements are sorted according to its
comparison criterion.

Then you can have:

  s: SORTED_SEQUENCE[STRING]
  ...
  s.extend("a")
  s.extend("b")
  ...
  s[1][1] := "c"   -- breaks invariant of s, because
   -- s[1] returns a reference to the first string
   -- s[1][1] := "c" is equivalent to s[1].put("c",1)
   -- i.e. s[1][1]:="c" replaces the first string "a"
   -- with the string "c"

There is a method to avoid the problem. You have already mentioned that.
If you want to be sure the the above problem does not happen, you have
to deep_twin the strings on "s.extend("....") and you have to deep_twin
the strings on the query "item alias "[]" (i:INTEGER): G".
(Continue reading)

Permalink | Reply | 6 comments |
headers
Helmut Brandl | 1 Mar 2009 23:06
Picon

Re: How to prevent contract breaking due to aliasing

rfo@... wrote:
> 
> For non-STRINGs, there is no 'constancy' characteristic orthogonal to
> type.  I have urged members of this forum to consider this, but never
> heard a peep from anyone.  Why, I don't know.  Maybe I'm off my nut on
> this one, but to me, such a characteristic would be quite helpful in
> cases like this.
> 

Hello Roger,

here is the first peep.

Your point concerns me as well. In my previous response to Rosivaldo I
have mentioned a class SORTED_SEQUENCE[G->COMPARABLE] which wants to
protect itself against a violation of its invariant from the outside
world but where the protection is quite costly.

Having something like

  item alias "[]" (i:INTEGER): constant G

would help. Having that SORTED_SEQUENCE could be sure that no one could
modify the returned object any more. So the only necessary protection
would be on the incoming side.

But figuring out all the necessary conforming rules is not quite
trivial. Furthermore: What should be the semantics of "const G"?

The most apparent semantics would be that on any entity of type "const
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfo | 1 Mar 2009 23:23

RE: [eiffel_software] How to prevent contract breaking due to aliasing

Hi Helmut!

Thanks for the peep :)

Bertrand has spoken of 'unchanged'-style postconditions from time to
time (and the difficulties associated with them).  I forget what wording
he used.
Do you think such a thing would help enough?  Perhaps a class could
conform to 'constant' (i.e. can accept a constant qualifier) only if its
functions had 'unchanged' postconditions.  Perhaps rather than overwhelm
'ensure' with tons of negativity, a new postcondition subclause might
help to identify 'unchanged'-style assertions.  Something like:
  ...
  ensure [[then] <boolean expression>]
  [unchanged [then] <value expression>]
  end

I see this as much like a loop variant in spirit, but inside out and
backwards :)
The unchanged subclause would trigger 'old' for each value expression
(itself a query).
We still have the issue of C-isms in our queries when called from the
assertion, but we would know at compile time that we are indeed calling
from an 'unchanged' clause so perhaps something could be done, if only
for self defense.

Thanks,
     R

==================================================
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rosivaldo Fernandes Alves | 1 Mar 2009 23:37
Picon
Favicon

Re: How to prevent contract breaking due to aliasing

Hello Roger!

Thanks for the reply.

String is only a convenient example of a set element type. Even if strings 
were immutable, other kind of mutable elements could lead to the same 
problem. As designed, my set would be safe only if it accepted only 
immutable types. The only way I can devise to prevent this problem is 
exactly what you propose: treat elements as values. But then I should yield 
deep twins of them every time they need to be given to clients. The 
performance penalty is huge.

So, reasking my original question: since Eiffel is more than 20 years old, 
isn't there so far a common, proven, trustful and efficient 
design/contract/coding pattern to deal with this issue?

Any additional comments would be highly appeciated.

Best regards,

Rosivaldo.

-----Mensagem Original----- 
De: rfo@...
Para: eiffel_software@...
Enviada em: domingo, 1 de março de 2009 18:30
Assunto: RE: [eiffel_software] How to prevent contract breaking due to 
aliasing

Hello Rosivaldo!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helmut Brandl | 1 Mar 2009 23:44
Picon

Re: How to prevent contract breaking due to aliasing

Hello Roger,

I think you are talking about enforcing command query separation.

ECMA Eiffel once considered a "pure" characteristic for queries. But it
has not implemented that. Instead of this ECMA provides us with an
"only" clause in postconditions.

In an "only" clause in a postcondition you can assert that the routine
only modifies this and that. An empty only clause asserts that the
routine does not modify anything. I.e. in ECMA you can assert the
"pureness" of queries by giving them an empty only clause.

I don't know to what extend EiffelStudio is going to implement it.

But the only clauses cannot resolve the violation of class invariants in
classes like SORTED_SEQUENCE[G->COMPARABLE] and the problem in
Rosivaldo's example.

But the send me a reference to Bertrand's posts. I will read them carefully.

Helmut

rfo@... wrote:
> Hi Helmut!
> 
> Thanks for the peep :)
> 
> Bertrand has spoken of 'unchanged'-style postconditions from time to
> time (and the difficulties associated with them).  I forget what wording
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rosivaldo Fernandes Alves | 1 Mar 2009 23:47
Picon
Favicon

Re: How to prevent contract breaking due to aliasing

Hello Helmut,

Yes, you got my point well. And pointed to what I forgot to mention to 
Roger: I need a deep twin of the objects when they enter my set, not only 
when they are read by a client. Indeed my code breaks exactly because 
{MY_SET}.put doesn't do that.

Anyway, your reply is desolating: it confirms my worst fears, and gives no 
hope. :-)

Could anyone come to rescue?...

Regards,

Rosivaldo.

-----Mensagem Original----- 
De: Helmut Brandl
Para: eiffel_software@...
Enviada em: domingo, 1 de março de 2009 18:39
Assunto: Re: [eiffel_software] How to prevent contract breaking due to 
aliasing

Hello Rosivaldo,

you raised a good point that puzzles me a lot as well.

Usually it should not be possible for a client to break the invariant of
a supplier, but if the supplier is not very carefully designed with
respect to aliasing a client can break the invariant of a supplier.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane