>>Because this is a really common functionality, I created a class with 10 standard properties (Value1 - Value10) and a property for Success. I use it everywhere:
>>
>>LOCAL loInfo AS Info OF Utils.vcx
>>loInfo = NEWOBJECT("Info", "Utils.vcx")
>>loInfo.Value1 = 123
>>loInfo.Value2 = "Test"
>>
>>THIS.CalculateEtc(m.loInfo)
>
>But now they don't have meaningful names. You have to remember their meanings for each case.

That is true, this is a disadvantage. I only use this class for cases where I have a very simple implementation and where a dedicated class would be overhead. There are some tedious cases where I usually only need one or two values, and they don't contain a lot of business logic. This kind of code should be easy to write and I don't want even think about property names. At least I can then depend on the interface that is being implemented, Empty would be too anonymous to me, as well as missing IntelliSense. This strategy is easily portable to other languages which do not allow creating objects on the fly.

For more serious business code I would usually create a dedicated class but based on the same interface (which has a few extra commonly used properties, like Recordkey etc):

DEFINE CLASS Info_Invoice AS Info of Utils.vcx
  InvoiceNumber = 0
  Linecount = 0
  Changed = .F.
ENDDEFINE

LOCAL loInfo AS Info_Invoice OF Invoices.vcx
loInfo = NEWOBJECT("Info_Invoice", "Invoices.vcx)
THIS.GetInvoiceDetails(m.loInfo)

IF loInfo.Success
    Messagebox(TEXTMERGE("There are <<loInfo.Linecount>> lines on invoice # <<loInfo.InvoiceNumber>>"))
    LOCAL loInvoiceFrm AS InvoiceFrm OF Invoices.vcx
    loInvoiceFrm = NEWOBJECT("InvoiceFrm", "Invoices.vcx","", m.loInfo)
    loInvoiceFrm.Show(1)
    IF loInfo.Changed
      Messagebox("You did change this invoice, didn't you?")
    ENDIF
ENDIF