Brendan,

I share your concerns. The initial request didn't mention Fileman at all.

This is just a hint how a construct like this could be opened to SQL access. 
I've seen so many old MUMPS code that would have never taken its way to objects without.
It#s clear that this requires wise use and careful handling.

 

for pure object access, you have a getter and a setter method.  no magic

if also want to use it for SQL
- you need SqlComputed code. This will also replace your (object)Getter.

- to set your local variable also by INSERT or UPDATE you need to add  UPDATE and INSERT Trigger code.

example;

--

To anticipate critics:
Some people may say it's dirty coding.  YES !! But it works.

as a first suggestion, I would create a setter and getter method for this property that handles DUZ(2) in both directions.
If you add any property by the wizard it shows you the exact naming of the methods.
this property then goes in the first position of the IDkey
be aware of ProcedureBlock to have always access to your   DUZ(2)  or name it %DUZ(2) as hack

Yes you can! but not directly!
All you need is a an Abstract Class with 

Classmethods to read, set, kill Globals as you need either static with fixed names or Global references passed by params. As you like.
And if you add SqlProc to the method you can even use it over ODBC/JDBC.

You hit the point %Boolean s an excellent example  it can be TRUE, FALSe or NULL
in Caché terms: 1, 0, ""

Your example ^CODE("TNO","BIO",291,"AKI"))  is partially misleading in that sense that a global subscript can NEVER be ""
while the content of $LB() can be $LB(1,2,"",4)  or $lb(1,2,,4)  here you find your  "undefined" again,
similar to NULL in SQL (which is a different story)

there is a major difference between 1) and 2)

1) is also true if you have SET ^CODE("TNO","BIO",291,"AKI"))=""

this information is stored in ^|"%SYS"|SYS("Security","ApplicationsD")

you could extract it by MERGE ^mySAVE=^|"%SYS"|SYS("Security","ApplicationsD")
and then do any export of the global

Thanks!
One headache less in the discussion about the "right" way to write code.
+a tiny piece for "creative freedom".   

Procedureblock =1 

means ALL local variables except call parameters and %variables move to stack
and return when you return from your method (=procedure)

see Summary on Local Variable Scoping  for more 

this memory operation is not free but nothing to get a headache upon

Of course, if your utility classes are all ABSTRACT it is pure code.  As any .MAC, just easier to read.
OREF is just a special data type (object pointer) and not better or worse than any other variable.

I 'd guess variable scoping and procedure block has much more (microscopic) influence on performance.

My personal preference is to have only code tightly related to stored date in "object"-classes.
Anything else outside that is not only related to this class.

Use PuTTY instead

setting your terminal width to 132 will show the rest