Eiffel "Gotcha" #8 - order of local attributes 
Author Message
 Eiffel "Gotcha" #8 - order of local attributes

Roger Browne:

Quote:
> [local variable order]

Is it when both A and B are expanded with creation procedures that change
something global in which the order matters?


Sat, 06 Nov 1999 03:00:00 GMT  
 Eiffel "Gotcha" #8 - order of local attributes

I usually declare my local attributes in alphabetical order. Local attributes
can be declared in any convenient order, can't they?

Or can they? In what context will a routine containing this
declaration

  local
    a: A
    b: B

behave differently at runtime from the same routine with the
order of declaration reversed:

  local
    b: B
    a: A

Answer tomorrow. (Thanks to Alexei Kanatov for suggesting this one).

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Sat, 06 Nov 1999 03:00:00 GMT  
 Eiffel "Gotcha" #8 - order of local attributes

Quote:
> Local entities can be declared in any convenient order, can't they?

> Or can they? In what context will a routine containing this
> declaration

>   local
>     a: A
>     b: B

> behave differently at runtime from the same routine with the
> order of declaration reversed:

>   local
>     b: B
>     a: A

The "gotcha" comes from the fact that a local entity may be expanded,
in which case the creation routine (if any) will be automatically executed
upon routine entry.

If we assume that local entities are initialized in order of declaration
(an assumption that may be compiler-dependent), we can construct this
system which executes to completion as shown, but fails ("feature call on
void reference") if the order of declaration of 'a' and 'b' is reversed.

This is because when 'a' is declared first, the once-function is primed to
always return the string "gotcha", so the call to 'to_upper' succeeds in
both A and B. When 'b' is declared first, the once-function is primed to
always return a void reference, so the call to 'to_upper' will fail in B (and
would also fail in A if execution got that far).

  class MAIN
  creation make
  feature
    make is
      local
        a: A
        b: B
      do
      end
  end

  expanded class A
  inherit SHARED_ONCE_FUNCTION
  creation make
  feature
    make is
      do
        once_function("gotcha").to_upper
      end
  end

  expanded class B
  inherit SHARED_ONCE_FUNCTION
  creation make
  feature
    make is
      do
        once_function(void).to_upper  -- fails if 'b' decleared before 'a'
      end
  end

  class SHARED_ONCE_FUNCTION
  feature
    once_function(argument: STRING): STRING is
      once
        result := argument
      end
  end

[Aside: Why are once-functions permitted to take arguments? I cannot think
of a useful application for this, and I find the analogy in OOSC 1st edition
("Only the first person into the office each morning can set the thermostat")
unconvincing - I certainly wouldn't want to work in such an office.]

Regards,
Roger
--
--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525
-- Everything Eiffel: http://www.eiffel.demon.co.uk/ | +44-1772-687525



Sun, 07 Nov 1999 03:00:00 GMT  
 Eiffel "Gotcha" #8 - order of local attributes

Quote:

> [Aside: Why are once-functions permitted to take arguments? I cannot think
> of a useful application for this, and I find the analogy in OOSC 1st edition
> ("Only the first person into the office each morning can set the thermostat")
> unconvincing - I certainly wouldn't want to work in such an office.]

I support your opinion. In fact once functions with different
arguments would return inconsistent results (what if the postcondition
refers to the arguments? Should a postcondition for a once function be
evaluated evry time? It can't I fear...)

Ulrich Windl



Mon, 08 Nov 1999 03:00:00 GMT  
 Eiffel "Gotcha" #8 - order of local attributes

Quote:

> I usually declare my local attributes in alphabetical order. Local attributes
> can be declared in any convenient order, can't they?

> Or can they? In what context will a routine containing this
> declaration

>   local
>     a: A
>     b: B

> behave differently at runtime from the same routine with the
> order of declaration reversed:

>   local
>     b: B
>     a: A

...if A and B are both expanded and each has a different creation
procedure with side effects...

...because expanded entities are objects rather than object references.
So if they each have a creation procedure, it must be called
automatically at the start of the routine to ensure the objects are in a
valid state before they are used, and if the procedures have different
side effects then the order they are called in will be detectable.

(Confirmed experimentally on TowerEiffel v2)

And many thanks Roger for these highly amusing diversions!

Ted



Mon, 08 Nov 1999 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Eiffel "Gotcha" #10 - discounts

2. Eiffel "Gotcha" #12 - onceness and invariants

3. Eiffel "Gotcha" #10 - cleaning up

4. Eiffel "Gotcha" #9 - postconditions

5. Eiffel "Gotcha" #7 - redundant parentheses

6. Eiffel "Gotcha" #8 - order of local entities

7. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

8. "Interning" objects based on multiple attributes

9. "Interning" objects based on multiple attributes

10. "Attribute variable must be global"?????

11. Visibility and access to "public" attributes

12. Extended Attributes ".NAME?"

 

 
Powered by phpBB® Forum Software