loops and misc. suggestion

[Martin Lafaix]

Here are three suggestions I would like to make to enhance
NetRexx.  (I hope I'm not opening Pandora's box :-)

1 - Over loops

    NetRexx supports "over loops" to work through the sub-values
    in a collection of indexed strings.  Additionally, the
    reference implementation allows to step through the contents
    of objects inheriting of Dictionary.

    I suggest the extension of this support to Vectors and arrays.

    This way, we could write things like:

      anArray = [10, 30, 60, 20, 40, 50]  :
      loop i over anArray                 : loop i = 0 to anArray.length - 1
        say anArray[i]                    :
      end                                 :

    or:

      aVector = Vector()                  :
      aVector.addElement(...)             :
      ...                                 :
      loop i over aVector                 : loop i = 0 to aVector.size - 1
        ... aVector.elementAt(i)          :
      end                                 :

    This makes the code easier to read (the intent is simple to
    understand) and prevents the possible omission of the '-1'
    correction factor.

    [Expanding this construction further to support the JDK 1.2
     collection classes when applicable would fit this spirit.]

2 - In loops

    Sometimes when stepping through collections/structures, only
    the values are of interest, not their indices.  So I suggest
    the following extension to the loop construct:

      loop <vari> in <termi>
      end

    where <vari> successively takes all the available values in
    <termi>.  The type of <vari> would be the type of the
    elements contained in <termi> (Object for dictionaries,
    vectors, etc., the array element type for arrays, etc.).

    It may be interesting to also support Enumerations.

    This would allow us to write things like:

      -- finding the maximum value contained in anArray
      max = anArray[0]
      loop i in anArray
        if i > max then
          max = i
      end

    This suggestion adds a new construct, but should not break
    existing code.

3 - Delegates (or delegators or forwarders or ...)

    [This proposal is snarfed from a recent discussion in
     advanced-java.  I did not participated in it but I do find
     the idea appealing.]

    Sometimes, we are simulating multiple inheritance of
    implementation by mixing simple inheritance and delegation.
    Lets take the classic example of a grapher with an "abstract"
    representation of a node ("Node") that we want to display.
    For this, we have a Graphic class.  Our class, called
    NodeGraphic, would ideally inherit from both Node and Graphic.

      class Node
        method setName

      class Graphic
        method setX(x)
        method setLabel(label)

      class NodeGraphic extends Node
        -- delegation takes place here
        properties private
        _graphic = Graphic

        method setX(x)
          _graphic.setX(x)

        method setLabel(label)
          _graphic.setLabel(label)

    A lot of easily automatically generated code has to be typed
    by hand.  Additionally, we can't pass a NodeGraphic to a
    method expecting a Graphic (we can define an interface, but it
    does not solve the two other problems).  Worse, if methods are
    added to Graphic, we have to add them to NodeGraphic too.  A
    recompilation does not solve the problem.

    Adding a "properties delegate" instruction to NetRexx would
    provide a very simple answer to it.

      class NodeGraphic extends Node implements Graphic
        properties delegate
        _graphic = Graphic

    (Graphic is here turned to an interface.)

    This enhancement

    - is simple to explain (I hope :-) ;
    - fits well with NetRexx's "properties indirect" and "adapter"
      concepts ;
    - doesn't break existing code ;
    - only requires simple code generation (the methods defined in
      the Graphic interface are defined as above) ;
    - provides coding gain (no need to write boring code; a simple
      recompilation applies the modifications made to the
      ancestors).

    [It forces a new interface to be introduced, but it would
     have been necessary in the 'traditional' solution too to make
     NodeGraphic a Graphic too.]

Comments ?


Martin
--
[hidden email]
Team OS/2
http://wwwi3s.unice.fr/~lafaix/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>