Tuples, iterators, and multiple return values in Eiffel? 
Author Message
 Tuples, iterators, and multiple return values in Eiffel?

: ... So the answer here is to _remove_ feature replication and the
: "select" clause from the language.

Quote:

> Even though the bathwater seems murky, let's not throw it out, it may
> contain our baby!

Have you any evidence that there might be a baby there? Certainly I've
heard the rumours, but no-one has ever presented any hard evidence.

Can you, or anyone else, post an example of a useful application of
feature replication under repeated inheritance which could be made
to always work correctly in the presence of polymorphism and dynamic
binding (even allowing for alternative rules such as Loryn's "dynamic
seed")?

I've asked that question several times before, and never seen
a convincing example.

Examples like HOME_BUSINESS (ETL p169) leave me cold. They fall prey
to the existing insecurities in Eiffel (e.g. a call to 'insured_value'
on a RESIDENCE will actually return the insured value of the
BUSINESS). Loryn's "Dynamic seed" proposal would remove this
problem but leaves another problem: if a HOME_BUSINESS object is
attached to a HOUSE entity, a call to 'insured_value' will retrieve
the selected version of 'insured_value' when in fact the insured
value is the sum of the business and residence insured values.
Sure, we could modify the language to "fix" this too (e.g. by
allowing the 'select' clause in HOME_BUSINESS to specify a new
feature which would return the sum of the results of both its precursors),
but for each such language hack I can construct a more complex
example that will give meaningless or incorrect results.

Another example, which does not leave me quite so cold, is the following:

   deferred class NAMED
   feature
      name: STRING
      set_name(new_name: STRING)
   end

A class can multiply inherit from NAMED and rename the features (e.g. an
ELECTRONIC_COMPONENT may have both an 'iso_name' and an 'ansi_name'). But
even with Loryn's "Dynamic seed" proposal we still have the problem that
the "select" clause forces a quirky asymmetry and any call of feature
'name' on an entity of type NAMED will only tell us "one side of the
story".

Examples like NAMED can be trivially re-implemented as client
classes rather than ancestor classes - resulting in a simpler language
with no insecurities. Sure, there's an extra indirection: in our
ELECTRONIC_COMPONENT class we would need to write

   ansi.name

instead of

   ansi_name

but I don't have a problem with that.

Eiffel without replication under repeated inheritance (and therefore
without the need for a "select" clause) would be simpler, easier to
teach, and without the problems that are currently associated
with this construct.

In the absence of any substantial evidence of a baby, let's throw
out the murky bath water!

Regards,
Roger



Fri, 30 Mar 2001 03:00:00 GMT  
 Tuples, iterators, and multiple return values in Eiffel?
Loryn Jenkins:

Quote:
> 2. Franck reports that in some circumstrance calls to `f' and
> `Current.f' can execute different features. (I don't understand what
> context will cause this, though.)

That's easy:

class A ...
feature
        call_a is do a; Current.a end
        a is deferred ...

class AA inherit
  A rename call_a as call_a1, a as a1 select call_a1, a1 end
  A rename call_a as call_a2, a as a2 end
feature
  a1 is ... print (1) ...
  a2 is ... print (2) ...

Result with Eiffel as in ETL:

AA.call_a1 produces:
1 -- a
1 -- Current.a
AA.call_a2 produces:
2 -- a
1 -- Current.a (select-ed)

If both 'Current.a' did the same as their respective 'a' calls, it would
mean that it is possible that Current /= Current in a single object!

Quote:
> 3. Magic rebinding not intended to be deep. (! Again, something I
> don't understand.)

Separate the renames and selects page 176 in a diamond hierarchy instead
of a single class.

Quote:
> 4. It's impossible to get more than one part object.

class COMMAND ... execute is deferred ...

class MULTICOMMAND inherit
  COMMAND rename execute as exec1 select exec1 end
  COMMAND rename execute as exec2 end
feature
  exec1 is ... implemented ...
  exec2 is ... implemented ...
  init is ...
        something.set_command (Current) -- using exec1
        other_thing.set_command (?) -- using exec2, not possible.
...

Quote:
> others over the years have posted to c.l.e., asking why their code
> wasn't working as described in ETL.

I know (it's a FAQ!). I did ask it myself too. It's not surprising that
people are puzzled by this feature, want to understand it, and find
funky things they could do with it. But it's not something you miss when
doing everyday programming. No project has been cancelled waiting for
replication to be implemented.

Quote:
> I suggest we clean this issue up, whether or not we also accept
> the ROUTINE proposal.

Indeed, removing replication under repeated inheritance is the safest
way to clean it up.

--



Fri, 30 Mar 2001 03:00:00 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software