Switch statement with Void safety / type casting checks

[Gachoud Philippe]

As mentionned here,

I still don't understand the reason of not having a structure such as being able to do:

    local
        l_pet: ANIMAL
    do
        l_pet := catch_it_from_the_sky
        inspect l_pet
        when attached {DOG} l_pet as l_dog
            l_dog.eat (meat)
        when attached {FISH} l_pet as l_fish
            l_fish.eat (plants)
        else
            io.put_string ("Strange animal how do I feed him???")
        end
    do

the compiler is complaining with the `attached` after when...

Why such a need? I think everybody had this case...

It just happened me to mess up with repeated copy-paste which is what a language tries to help avoiding. In the above case, the `l_pet` is written one time, with a N times if/else I'd have to write it as much times as ifs...

Just sharing my reflections hoping not to bother everybody, hope nobody will click the unsubscribe button after my arrival on the group ;-)

[williams Lima]

Hi Gachould,

I don't understand you point about the number of times 'l_pet' is written using 'inspect' in comparison

with 'if's. In the example above it is written three times (once per 'when')

By the way I think you are not using the 'inspect' construction properly.

regards

Williams

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

[Gachoud Philippe]

On Fri, Oct 12, 2018 at 2:35 PM williams Lima <dwillia...@gmail.com> wrote:

Hi Gachould,

I don't understand you point about the number of times 'l_pet' is written using 'inspect' in comparison

with 'if's. In the example above it is written three times (once per 'when')

you're right in fact... why does the inspect structure complain when I do that? why does the inspect not work with just `comparables` 

I'd like to write the l_pet just one time and only have to put the types, would be ideal... maybe I'm asking for too much..., I could

perhaps generalize it with MAP[PROCEDURE, TYPE] if you understand my point better, the idea is

inspect variable

when to_compare_with1

    procedure

when to_compare_with2

    procedure

else

   procedure

end

That was maybe my reductive conception of the inspect statement.

Actually the problem I have is not the first time in Eiffel but is the only language I risk myself to question because of it's top-down purpose and goals, the switch/case/inspect statement is a basic structure I hoped could be pushed farther than only INTEGER,CHARACTER, probably STRING, @ the end I was thinking it accepts COMPARABLES (or even less when they are is_equalable)...

--

**********************************************

Philippe Gachoud

Nuestra señora del Rosario 629

Las Condes

Santiago de Chile

0056 2 27 27 21 29
ph.ga...@gmail.com
**********************************************

[williams Lima]

Hi  Gachould,

It is a bit difficult (for me) to discuss this using abstract situations.

I suggest that we (you) create a project on GitHub where we could work

in a 'real' case and then experiment with the different situations and explore the language

through actual examples. I think it will be much more productive and interesting. And

in the end, we will have a good documentation of the issues and the solutions we found.

What do you think?

regards

Williams

[Gachoud Philippe]

On Fri, Oct 12, 2018 at 4:23 PM williams Lima <dwillia...@gmail.com> wrote:

Hi  Gachould,

It is a bit difficult (for me) to discuss this using abstract situations.

I suggest that we (you) create a project on GitHub where we could work

in a 'real' case and then experiment with the different situations and explore the language

through actual examples. I think it will be much more productive and interesting. And

in the end, we will have a good documentation of the issues and the solutions we found.

What do you think?

Perfect, I'll soon return to you when something is on gitHub ;-)

[r...@amalasoft.com]

Each 'when' case needs to be a constant value.  The dynamic type of an object is not a constant value, so inspect is not the right mechanism to use.

Each object makes available its 'generating_type', and that is of type TYPE.  Within the TYPE class is an integer 'type_id'.  While that could be used in an inspect clause, I recommend against that.

It is often useful, once an object is found to be attached as a dynamic type, to use that knowledge AND that attachment to do something.

If all you need to do is to find the dynamic attached type, then a set of if-then-elses is what you need to do. If you expect to perform that check often, then put that logic in a function.

If the set of possible attachments in your application is small and stable, then defining your own app-specific constants could streamline your code, and you could use those values in the inspect clauses you might need for that.

There are mechanisms available.  Choosing the right one sometimes is not that obvious.  While each of us might have used a screwdriver at some point when we really needed a chisel, that doesn't make the screwdriver the right tool for the job.

R

[Gachoud Philippe]

Perfect thank you...

[Karsten Heusser]

Dear Philippe,

if you decide to use a conditional of the following form

    local
        l_pet: ANIMAL
    do
        l_pet := catch_it_from_the_sky

        if attached {MAMMAL} l_pet as al_mammal then
            l_mammal.express_yourself
        elseif attached {DOG} l_pet as al_dog then
            al_dog.bark
        elseif attached {CAT} l_pet as al_cat then
            al_cat.meow
        else
            print ("The pet of type " + l_pet.generator +
                "%N slipped through the programmer's fingers!%N"
            )
        end
    do

take care of the correct order of branches.
If `l_pet' is of type DOG it won't bark,
because after its attachment to `al_mammal'
it won't be attached to any other `al_xxx'.

So if you want to execute the 'most specific action'
reverse the order of branches.

Important note: Try to avoid the pattern given above!
Often it is possible to exploit polymorphism and dynamic binding.
So, if `bark' and `meow' are redefined versions of `express_yourself'
the code becomes much easier:

    local
        l_pet: ANIMAL
    do
        l_pet := catch_it_from_the_sky

        if attached {MAMMAL} l_pet as al_mammal then
            l_mammal.express_yourself
        else
            print ("The pet is not a mammal!%N")
        end
    do

Best,
Karsten