>Especially in building SQL parts I find inheritance can save unneccesary repetition - so I would recommend
>at version 8 clearly
>

>  PROCEDURE GetCursor
>	PARAMETERS tcMessageType, tcCursorType
>        = Dodefault() && no Parameter fwd ??
>        local loX, luRet
>        loX = createobject(m.tcMessageType + "_ParseHelp_" + m.tcCursorType)
>	luRet = loX.Doit()
>        return m.luRet
>  ENDPROC
>
>  define class HL7_ParseHelp_Demographics as xxx_ParseHelp_yyy
>  enddefine
>
>  define class xxx_ParseHelp_yyy as base_ParseHelp_base
>  enddefine
>
>  *-- version 2 re-using private parameters"
>  define class aggregator as custom
>    func doit()
>        local ;
>             loMess, loCurs ;
>           , luMess, luCurs
>        loMess = createobject(tcMessagetype )
>        loCurs = createobject(tccursortype)
>        luMess = loMess.Doit()
>        luCurs = loCurss.Doit()
>        return &&& whatever
>
>  enddef
>

>
>If you have the need for independant inheritance you can build an aggregating stable object which initialzes 2 objects identified by the parameters - but if case was enough at first this might be overkill. It cuts down on lines even more, but maintaining it is slower as you always have to recheck the current coupling. But for cursor-building via select statements I usually can reuse property settings for path and so on. YMMV...
>
>my 0.02 EUR
>
>thomas

Yes, this is good. His case was somewhat special. Rethinking about it he may simply have the
empty tables serving as structures and his code would be:

  PROCEDURE GetCursor
	PARAMETERS tcMessageType, tcCursorType, tcCursorName
        Dodefault() && no Parameter fwd ?? - yes a bit odd but may be
        select * from (m.tcMessageType + "_" + m.tcCursorType) ;
          where .f. ;
          into cursor (m.tcCursorName) readwrite
  ENDPROC

Cetin