Thanks for this Bertrand. I may be the only one, but I find the ECMA
document difficult to understand - I look forward to ETL3 being published.
Regards
Chris Saunders
-----Original Message-----
From:
es-devel-bounces@...
[mailto:
es-devel-bounces@...] On Behalf Of Bertrand Meyer
Sent: August 15, 2007 11:28 PM
To: 'Peter Gummer'; 'Eiffel Studio Development Mailing List'
Cc: Meyer Bertrand
Subject: Object test -- was [[Es-devel] ?= question
Perhaps this is an opportunity for a short tutorial on the Object Test,
since not many people may be familiar with it yet. This is an informal
introduction; for the exact specification see the ISO/ECMA standard
text.
Object Test is the best form we know of what is variously called
"Run-Time Type Identification", "Downcasting" etc.
Let exp be an expression of type T, and U a type conforming to T. You
want at run time, in case exp actually happens to be of type U
conforming, rather than just T, to apply to exp a feature fu of U. Using
an object test you write:
if {x: U} exp then
x.fu
... Possibly other U operations on x ...
else
... Optional clause as usual
end
The object test is `{x: U} exp'; it is a boolean expression, whose value
is true if and only if the type of the object attached to exp conforms
to U. It also causes x to be attached to that value throughout the
"scope" of the object test. "Scope" is a static notion; in the case of
an if... then ... end instruction as here, where the object test appears
in the `if' -- the most common scenario --, the scope is the `then'
part.
x, called an "Object-Test Local", is like a local variable that is
assigned the value of exp if the test succeeds (the type of exp conforms
to U) and keeps it throughout the scope; because x is of type U, not T,
you can apply U features to it, whereas that would not be possible for
exp which is only of type T. You may not assign to x, so the more
precise analogy is with a formal argument rather than a local variable.
You may think of the above code as
if "exp is of a type conforming to U" then
funnyproc (exp)
else
...
end
with
funnyproc (x: U)
-- Perform U-specific operations
do
x.fu
... Possibly other U operations on x ...
end
which would magically be made valid. As written it of course isn't since
you cannot pass exp, of type T, to funnyproc expecting a U.
The scope of an object test is defined by rules covering all the
relevant cases. For example if the test is negated, as in
if not {x: U} exp then .... else ... end
the scope is the "else" rather than "then" clause. In a loop
from ... until not {x: U} exp loop BODY end
the scope is the loop body.
The name of an Object-Test Local must be different from those of
arguments, local variables and features of the enclosing context.
The scheme equivalent to [1] using an assignment attempt would include
the declaration of a variable
x: U
(attribute or more commonly local variable), then
x ?= exp
if x /= Void then
x.fu
... Possibly other U operations on x ...
else
... Optional clause as usual
end
Assignment attempt was a great advance when it was invented and has
served us well for almost two decades. The advantages of the Object Test
over this venerable predecessor include:
1. No need to declare a local variable at some outer level, which causes
quite a bit of noise, especially since these variables are only used in
a very narrow context, such as the "then" clause in the last example.
The Object-Test Local is declared in situ and serves a local purpose;
it's unobtrusive and not a full-fledged variable (read-only in the
scope).
2. No need to use Void. While attractive at first, the use of Void is an
arbitrary and artificial ocnvention.
3. Object Test is essential for the attached type mechanism, for which
the convention of using Void is just about the reverse of what we need.
On the other hand, object test, a more sophisticated mechanism because
of the notion of scope, may be a bit harder to teach, especially to
beginners. We don't know yet; I hope we will find a good way to explain
it (I am trying to do this right now in the "Touch of Class" textbook).
As an aside I note that Wikipedia entries on topics such as RTTI don't
mention the Eiffel assignment attempt mechanism, which was a pioneer in
this area; perhaps someone could add a mention. This also applies to
other programming topics for which Eiffel has interesting solutions.
As Peter implied we are hoping to offer Object Test by 6.1 as part of
the first steps towards the attached type mechanism. In any case the
compiler will not stop supporting assignment attempt any time soon.
-- BM
> -----Original Message-----
> From:
es-devel-bounces@...
> [mailto:
es-devel-bounces@...] On Behalf Of Peter Gummer
> Sent: Thursday, 16 August, 2007 02:52
> To: 'Eiffel Studio Development Mailing List'
> Subject: Re: [Es-devel] ?= question
>
> Manu wrote:
>
>
> > No, conversion only apply to normal reattachment (i.e.
> argument passing
> > and
> > plain assignment).
>
> That makes sense. Conversion is compile-time syntactic sugar.
> Assignment
> attempt (and its ECMA replacement, object test), on the other
> hand, is a
> run-time operation.
>
> >> I tried looking in the ECMA standard document for "?=" but
> >> found no matches. Does this mean ?= is no longer Eiffel?
> >
> > That's indeed correct it has been replaced by the object
> test syntax.
>
> Note that, because object test hasn't been implemented yet,
> we still use
> assigment attempt; but according to
>
http://dev.eiffel.com/EiffelStudio_Roadmap, we will have
> object test very
> soon :-)
>
> - Peter Gummer
>
>
> _______________________________________________
> Es-devel mailing list
>
Es-devel@...
>
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel>
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
