>>>Using m. is really important, especially when dealing with inherited projects and third party tools. Just today I had a situation where I used Marcos nfJsonRead() function and it crashed under certain cases. After at least one hour of debugging and trials it turns out this legacy app has a table called OBJ, and nfJsonRead has an object variable called obj which is sometimes referenced with and sometimes without m.
>>
>>The requirement of using m. is negated by using LPARAMETERS and LOCAL declarations for every memory variable, using prefixes like "l" for local, "g" for global, "t" for parameters, with a second character indicating the type like "l" for logical, "c" for character, "n" for numeric, "i" for integer, etc., and then using an intelligent naming convention. lnI instead of i. llResult instead of result. And for table field names, leave off the leading locality indicator, so you just have cName instead of lcName or gcName.
>>
>>Calling something "obj" there is the issue, not a non-use of "m." prefixes. The memory variable should've been called loObj, or thisForm.oObj, or goObj, and probably not just "obj" if it's a global thing, but something like loClientObj or something intelligent.
>
>That is correct, in my projects I follow all these rules and never needed m. But in legacy applications that are based on the italian design pattern I put m. wherever I can.

I would probably encapsulate that code in its own process then. I would pass in a JSON string with whatever was needed, and setup the environment and let it process there. If that's not possible, then maybe a two-way communication between .exe's using messages. If it has to be in the same app, I probably wouldn't use it. I'd roll my own.

I do understand legacy issues. If I encountered a system that had such design aspects, I would use m. for the requirements of that app. But I would first spend a fair amount of time considering how I could work around it.