Obsoleted assignment attempt

[Marco Trudel]

Dear all

What's the suggested replacement for the (since 7.1) obsolete assignment
attempt? I don't see a satisfying replacement for it.
Consider for instance (with the obvious corresponding classes):
dog ?= animal

I consider it syntactic sugar for:
if attached {DOG} animal as tmp_dog then
dog := tmp_dog
else
dog := Void
end
If I have to replace all assignment attempts (originally 1 line) with 5
lines of code where I have to specify the type again, that's not
extremely great and also quite detrimental to readability (nesting).

Another solution would be (slightly different semantics of course):
check attached {DOG} animal as tmp_dog then
dog := tmp_dog
end
This is about 3x slower than assignment attempt (already useless for
me), takes 3 lines instead of 1 and I also have to specify the type again.

Last but not least there would also be:
dog := {DOG} #? animal
Finally, only one line. But again about 3x slower and multiple
declarations of the type; also not satisfying for me.


Maybe an actual example might help the discussion:
I use(d) assignment attempt extensively. Almost exclusively in places
where I know it cannot fail like with INTERNAL.new_instance_of. In the
super unlikely case that it would fail, I would in the following
statement get a "call on Void target" exception; that's good enough. So,
originally I have:
dog ?= internal.new_instanceof_of (foo)
dog.bark
This would now become (I can't use "check" and "{DOG} #?" because it's
too slow):
if attached {DOG} internal.new_instanceof_of (foo) as tmp_dog then
dog := tmp_dog
else
dog := Void
end
dog.bark
-- more code
I can't remove the else branch. Otherwise (e.g. in a loop where "dog"
might be set multiple times), it would become undebuggable in case of
failure if there's already an old value. Another translation would be:
if attached {DOG} internal.new_instanceof_of (foo) as tmp_dog then
dog.bark
-- more code
else
(create {EXCEPTIONS}).raise ("Houston, we ran out of beer!")
end
I don't like either replacement.


So my questions:
- What is the recommended replacement for assignment attempt?
- Why is a "check-then" statement 3x slower than an "if" statement that
raises an exception in the else branch?


Thanks
Marco


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)

<*> To change settings via email:
eiffel_soft...@yahoogroups.com
eiffel_softwar...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
eiffel_softwa...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[LARRY RIX]

Good morning Marco,
I have not investigated the efficiency bits you refer to below, but the assignment attempt is only one-half of the needed code (e.g. dog ?= animal). The assignment attempt is an attempt and must be followed up with some form of condition or check. Therefore, we get constructs like:
dog ?= animalcheck has_dog: dog /= Void end
or
dog ?= animalcheck has_dog: attached dog end
or
dog ?= animalif dog /= Void then-- do somethingend
or
dog ?= animalif attached dog then-- do somethingend
In any of these examples (others I am not aware of) there is always the attempt followed by conditional check, which embodies some form of response (either a check assertion or a conditional execution of some code). Again, I have not investigated the efficiency of the C produced behind these, but I will. Nevertheless, it seems right to examine the whole code as presented above and reconsider the alternatives to compare them, such as:
check attached {DOG} animal as al_dog then-- do somethingend
Laying efficiency matters aside for a moment and speaking strictly from a readability viewpoint, I find this block of code to be much more expressive and a better teller-of-the-story than the assignment attempt construct. Here, I can naturally (from the self-documenting code) understand that what the writer is after is an attached (/= Void) `al_dog' from a possible range of `animal' instances. The assignment attempt leaves me to look elsewhere to define what `dog' and `animal' are. The code above reveals the matter plain and clear at that point without need of further code exploration to discover.
We have been using this form of attachment check assertion for quite some time and throughout our code. If there are efficiency issues with the generated C where it could be improved, I am thinking this is a matter to point out to Eiffel Software (e.g. Manu Stapf) and see about getting it tighter. Still, as simply a logical code construct, I am quite satisfied with the attachment checking code pattern.
Respectfully,Larry Rix
To: eiffel_...@yahoogroups.com
From: ma...@mtsystems.ch
Date: Tue, 25 Sep 2012 16:55:54 +0200
Subject: [eiffel_software] Obsoleted assignment attempt

[Non-text portions of this message have been removed]

[Marco Trudel]

Hi Larry

Of course, if after the assignment attempt you're checking if it worked,
then you can just as well use an object test. But my point was that I'm
using it mostly in cases it cannot fail (dog ?= INTERNAL.new_instance_of
(...)).
It's like "ANY.as_attached". One could just as well write an object test
for it, but it's more convenient and readable not to when it's clear
that it cannot fail (e.g. hash table access). There was an internal
discussion about that not too long ago where I think the final decision
was to keep the "as_attached" if the proper precondition (Current /=
Void) is added (and a check-then in the body).
So I hope for a consistent decision about assignment attempt (keep it to
allow creating readable code were possible).

Thanks
Marco

[Thomas Beale]

On 26/09/2012 11:15, Marco Trudel wrote:
>
> Hi Larry
>
> Of course, if after the assignment attempt you're checking if it worked,
> then you can just as well use an object test. But my point was that I'm
> using it mostly in cases it cannot fail (dog ?= INTERNAL.new_instance_of
> (...)).
> It's like "ANY.as_attached". One could just as well write an object test
> for it, but it's more convenient and readable not to when it's clear
> that it cannot fail (e.g. hash table access). There was an internal
> discussion about that not too long ago where I think the final decision
> was to keep the "as_attached" if the proper precondition (Current /=
> Void) is added (and a check-then in the body).
> So I hope for a consistent decision about assignment attempt (keep it to
> allow creating readable code were possible).

> *
> *
>

We have code with this same case as well - it's always the same
situation - it's in code that treats objects generically usually using
INTERNAL facilities. You know there is an object, you even know that it
is the correct type, but of course until you obtain it from the file /
db / other medium, the Eiffel runtime doesn't know that.

For now I have replaced such code with the usual 'if attached ...'
pattern, but I had the same misgivings as Marco, I have to admit. I was
unaware of the performance difference. I also wonder whether trashing
assignment attempt completely makes sense. There remains the need to
convert an object of ANY to a particular type due to reading from
serialised or other external data sources.

- thomas

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[r...@amalasoft.com]

Hi Thomas et al

I have similar cuts and bruises but after a while I concede defeat
(though it does take me a while).
A mechanism that captures this particular scenario would be handy, but
it must be not be as much an act of fair that the venerable assignment
attempt often was in practice - by others that is :)
If such an operator or other concise form were to exist, it would have
to bound to an assertion of some kind, with the option to disable it at
compile time. This is what the accompanying check instruction does in
effect and the check attached construct, while admittedly scary, is not
actually all that bad.
Perhaps something as simply as reviving the syntax but augmenting the
implementation would be satisfactory such that:

a ?= b

became shorthand for:

check attached {like a} b as la a := la end

This way, the safety is there but the (some would say superfluous)
wordiness would not be. I don't see this as being too tricky. For
those converting from versions before assignment attempt's exile, there
would be no backward compatibility issues but they would want to remove
any checking that would be rendered unnecessary by the new mechanism.

If the built-in check could also be labeled and therefore disable-able
independently, that would be extra nice.

For run-time type and/or assignment checking, the current syntax seems
just fine and more expressive, and indeed in some patterns of use is
actually less wordy than its predecessor (as illustrated by examples
from Bertrand a few years back).

R

==================================================
Roger F. Osmond