OpenEuphoria

Re: SS

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 07, 2007
• 571 views

Pete Lomax wrote:
> 
> Problem is that eg:
> }}}
<eucode>
> for i=1 to length(list) do
>     ?list[i].phone
> end for
> </eucode>
{{{

> Effectively ".phone" might be [15] for customers, [17] for suppliers, and
> invalid
> subscript on anything else. Nasty.

Proper OO design would put the 'phone' member into a super class of both, so
that they would be inheriting the same thing, and the indices would be the 
same.

In a related vein, for 'true' OOP, you really need late binding, which 
basically means virtual functions.  I think this is very doable for ooeu.
My idea is that, as soon as the user declares a routine as virtual, a
data member vtbl is automatically added (if it hasn't already).  Or maybe
it's just something that's invisible to the coder, which might make 
initialization easier...but I'm getting off topic.  The basic idea would
allow something like the following:

euclass person( sequence p )
    sequence name
    virtual procedure print_name()
    end procedure
end euclass person

euclass customer( person c )
    virtual procedure print_name()
        printf(1,"Customer: %s\n", {this.name})
    end procedure
end euclass

euclass supplier( person s )
    virtual procedure print_name()
        printf(1,"Supplier: %s\n", {this.name})
    end procedure
end euclass

customer cust = {"Matt"}
supplier supp = {"Pete"}

sequence of person people
people = {cust, supp}
for i = 1 to length(people) do
    people[i].print_name()
end for
--  Output:
--          Customer: Matt
--          Supplier: Pete

 
> Possibilities still exist with "sequence of customer" etc, but the problems
> and limitations are mounting up now I feel. Fun while it lasted, though.

I agree with you if we are still talking about the types of structures that
Karl had proposed (and basically agree with Rob, especially about the
backend issues).  However, I don't see a problem with the sort of thing
I've done with ooeu.

My approach, I suppose, is to allow the user to have extra tools for dealing
with data.  It allows a different way to organize and use the data, but 
doesn't preclude using it in a normal way, or in a halfway mode that uses
more dots, but doesn't use the same OOP-style syntax:

? cust[customer.name]
customer.print_name( cust )

Matt