Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Mdot question
Message
From
07/04/2021 00:28:23
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
 
 
To
06/04/2021 16:25:16
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Title:
Miscellaneous
Thread ID:
01679493
Message ID:
01679632
Views:
43
>>>>>>Hi.
>>>>>>
>>>>>>does it make any sense to have mdot used like this
>>>>>>
>>>>>>m.ObjName1.Name2()
>>>>>>
>>>>>>?
>>>>>
>>>>>The final point in this is again, that is how FoxPro works. If you want to ignore it, that's stupid.
>>>>>
>>>>>I have code where the original programmers did
>>>>>
>>>>>SCATTER NAME aliasname.
>>>>>
>>>>>Now, not only is mdot for fields an issue, but also m.aliasname to differenciate the cursor from the object name. It wasn't until the object name feature was added. These guys did not ever come to the user group meetings, or any online forums. They thought they knew better and here we are.
>>>>
>>>>Do you repeat your messages, or is LevelExtrem broken? I've answered this before.
>>>>
>>>>You run in circles with this non-argument that is how FoxPro works It is simply not true. It works without pretty well. Crappy XBase code is not the standard. I have less then 10 methods that touch GATHER SCATTER or something the like. Those are the only points where alias or field could cross a variables name. This should be used carefull, but for 99.9999% it's meaningless.
>>>
>>>Why are you *not* understanding what he means by that phrase "that is how FoxPro works"?
>>>
>>>If I'm not mistaken, it is being meant to convey that FoxPro has certain "quirks" in behavior (e.g. prioritizing field names over variables) and that use of mdot can be used to work around some of the problems (amongst others) that this behavior can cause. As you indicated you can avoid these problems by proper design, but if you're having to deal with existing code (that someone else wrote) you may not have that option to redesign it (nor do you want to even try -- there's a good chance you'll break something if you do) -- so you basically try your best to work within those confines.
>>
>>I read this different. The way and order how VFP tries to find a meaning for a name is clear as blue sky and where never doubt by me. I only say that this stubborn I know how it goes and this means vars only with mdot and mdot everywhere is wrong. And mdot on left side of an assignement or on an ARRAY access is nonsense.
>>
>>That crappy old cold need delicious handling is one thing. But spread this over any code is wrongness.
>
>That is only your opinion. It is not backed up by the fact that FoxPro STILL looks first for a field named like your variable reference and still looks for an alias like your object reference. You wish to let it waste time doing so because you don't like how some code looks. That is shallow.

That becomes boring. You repeat nothing than evident stuff. We all know the order of looking up names for a while. In fact this is as clear as blue sky and there was no point in mention it at all.
But what we discuss are the places where VFP acts different. Like left of a =, after RELEASE, after STORE TO, in front of ( / [, and, different after @. The places where mdot is superfluous. If it's you taste to add it there - I don't care. It's your code. I can do without, what's proven working for decades, so don't crusade.
The initial question was about if on ObjName1.Name2() THAT IS WITH BRACES, VFP would try to look up fields first, because it can not be a field. For example for
Name2(n) or Name2[n] it will not look up fields first. But ObjName1.Name2() is not Name2(n) so I just had a question. I don't need a crusade.

So: yes, no, tristate?
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform