Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!bony1!richieb
From: richieb@bony1.bony.com (Richard Bielak)
Newsgroups: comp.lang.eiffel
Subject: Re: How can I do this in Eiffel?
Message-ID: <1991Apr17.133538.8189@bony1.bony.com>
Date: 17 Apr 91 13:35:38 GMT
References: <ajk.671419932@wren> <1991Apr15.131833.230@bony1.bony.com> <ajk.671767919@wren>
Reply-To: richieb@bony1.UUCP (Richard Bielak)
Distribution: comp
Organization: Bank of New York
Lines: 71

In article <ajk.671767919@wren> ajk@wren.cs.rmit.OZ.AU (Alan Kent) writes:
>richieb@bony1.bony.com (Richard Bielak) writes:
>
>>In article <ajk.671419932@wren> ajk@wren.cs.rmit.OZ.AU (Alan Kent) writes:
>>>I have a tree structure of nodes. These nodes are not all of exactly the
>>>same class....
>
>>You can do exactly what you need by using the "reverse assigment" in
>>Eiffel. Reverse assigment is one of few ways, in which you can check
>>that two objects are type compatible. Here is how this might work:
>
>>        visit (n : NODE; t : SPECIFIC_TYPE_OF_NODE) is
>>                do
>>                        t ?= n; -- reverse assigment
>>                        if not t.Void then
>>                                -- here t referes to the specific type
>>                                -- so apply whatever things
>>                                t.specific_routine
>>                        end;
>>                end; -- visit
>
>>This routine can then be called for every node in your tree.
>
>>In the above example, I assume that NODE is a parent of
>>SPECIFIC_NODE_TYPE. The "?=" will return a non-void value only when
>>"n" actually references SPECIFIC_NODE_TYPE.
>
>First, I assume you mean t is local, not an argument?
>I thought you were not allowed to assign to arguments.

You are right. "t" above could not be a parameter. It could be local.

>
>Also, I am not sure how this solves my problem. Say I have 30 different
>"specific_routine"s. Do I have to then write 30 different visit functions
>with 30 different walk functions to call the visit functions?
>

You could create a class like so:

        class WALK_TREE [S] is
        
        feature

                t : S;

                visit (foo : NODE) is
                        deferred
                        end; -- visit

                [.. whatever common code is needed for walking a tree ..]
        end;

Now, for various types of nodes you'd have to inherit specifying
the actual type "S". 

So, if you need to do 30 different things for different types of
nodes, you will have to write 30 different "visit" routines. But you
should only have to write the code to walk the tree once.

Actually, I believe that the library TREE class is already set up this
way. It has routines to scan the tree, and an action routine than can
be redefined in an heir, that will be called for each node scanned.


...richie
-- 
*-----------------------------------------------------------------------------*
| Richie Bielak  (212)-815-3072    | Programs are like baby squirrels. Once   |
| Internet:      richieb@bony.com  | you pick one up and handle it, you can't |
| Bang:       uunet!bony1!richieb  | put it back. The mother won't feed it.   |