>>>>3 The decision to first look up in the table, and only then look up in the list of variables, is killing for routines that were developed with no such table in the developer's imagination at the time of developing. Imagine a developer constructing a routine that e.g. checks for the existence of an app; why on earth must this developer be aware of the possibility that a table could ruin the code?!
>>>
>>>Since the dot is possible in object and table syntax, following your argumentation the memvar should be "inspected" first. In this situation, how could you write any routine (using the table-dot) accessing a table field without the danger that a combination of object with the same name as the table and propertyname like the field name might corrupt it without your notice ? The case of having a error from a different field type or non-existing property would be better than the danger of "silently acessing" the object instead of the table. And NOW forcing back the notation for tables to "->" ?
>>
>>Thomas, I tried hard to understand your point, but find it a bit too hard. Please, could you rephrase your point, because I think you try to make a good point.
>
>Hi Peter,
>
>

>CREATE CURSOR myCurs (cMyField C(20))
>INSERT INTO myCurs (cMyField) VALUES ("MyField in MyCurs")
>= anylib()
>myCurs = createobject("custom")
>= ADDPROPERTY(myCurs, "cMyField", "in Object")
>? m.myCurs.cMyField, myCurs.cMyField
>*-- ***simulate*** m.mycurs will be evaluated first: Peter's wish
>USE IN myCurs
>*-- this would use the objects property under Peter's rule
>= anylib()
>myCurs.cMyField = 5
>*-- errors are WELCOME here!
>= anylib()
>
>FUNCTION anylib
>*-- Supposed(!) to work on the cursor field
>? ALLTRIM(myCurs.cMyField)
>

>
>this scenario would be even worse!
>
>You ***must*** use ? ALLTRIM(myCurs->cMyField) if memvars are used first, because m.myCurs.cMyField would take precedence if it exists. OTOH, if you always mDot, the code in anylib will not be broken by any object the developer hasn't foreseen. It is the same situation...
>
>I hope this explains it better....

Explanation is now understood. :)

I had to change the addproperty line to:

= myCurs.ADDPROPERTY( "cMyField", "in Object")

Your quest is: And NOW forcing back the notation for tables to "->" ?
I see no direct need though. The function anylib(), as built now, assumes that the cursor is open. If it has reason to suspect that it could be non-existing, then it should first test: IF USED('mycurs')
That would be a better security measure than using ->, IMO.