Daniel Stenning kirjoitti:
> Now of course RB could implement this FR internally by wrapping the two 
> integers inside a "hidden" struct.  This would nicely avoid us having to
> define such a struct ourselves, cluttering the project editor with endless
> tiny structs and classes.
>   
No, no hidden structs and no multiple return values either. I agree that 
at first look a custom class seems to be overkill while it's actually 
question about messaging (in OOP sense). The problem lays , IMHO, in 
that many OOP languages (RB included) don't provide a clearly defined 
structure for messages. One mind think that what comes closest to a 
message in RB is a struct, but due its limitations it may not suit one's 
needs.

Let me elaborate on messages. I have some experience with Component 
Pascal (http://en.wikipedia.org/wiki/Component_Pascal) where messages 
are constructed as records (in Pascal sense). You don't have to 
create/construct them, just define, and they can be inherited.

E.g. in Component Pascal syntax

TYPE
  MyAbstractMsg = ABSTRACT RECORD END; /* no instances allowed */
  MyIntMsg = RECORD [MyAbstractMsg]
                            i: integer;
                         END;
  MyStrMsg = RECORD [MyAbstractMsg]
                            str: string;
                         END;

FUNCTION IntFoo(...): MyIntMsg;
VAR
    msg: MyIntMsg;
BEGIN
    msg.i := 1;   RETURN msg;
END;

FUNCTION StrFoo(...): MyStrMsg;
VAR
    msg: MyStrMsg;
BEGIN
    msg.str := "foo";   RETURN msg;
END;

Now, let's have a procedure which needs to call these both:

PROCEDURE MyFoo(...);
VAR
    msg: MyAbstractMsg;
    i: integer;
    str: string;
BEGIN
    /* type casting */
    WITH msg: MyIntMsg DO
       msg := IntFoo(..);   i := msg.i;
    END;


    /* type casting */
    WITH msg: MyStrMsg DO
       msg := StrFoo(..);   str := msg.str;
    END;
END;

(Although convention in CP is to use messages as call-by-reference 
parameters.)

So in order to have inheritable messages, one must use Dictonaries in RB 
which requires some memory management. Perhaps a simpler solution would 
be clearer tagging of formal parameters, i.e. to loan Component Pascal 
again VAR for call-by-reference parameters (RB's byRef), IN for 
read-only parameters, OUT for output parameters (accessing them within a 
procedure/function/method before assigning a value causes a compile-time 
error) and no tag for call-by-value parameters (RB's byVal).

Metsis


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to