Can't set property of Shared Object in Compiled Mode

Using 4D v17.2 HF1, the following works interpreted but fails compiled:

C_Object($oMyObject)
$oMyObject:=New shared object

Use ($oMyObject)
OB SET($oMyObject;“Test”;1234)
End use

Error -10719, “Shared Object needs a “Use” before altering a property. Any ideas?

Shared Objects, ORDA as well as many other new commands, are designed for object notation.

Rewrite your code to:
Use ($oMyObject)
$oMyObject.Test:=1234
End use

Much easier said that done and it’s not documented as far as I can tell. We have over 500 methods that use periods in their names, some of which are called via Execute Formula after constructing the name and so it’s not a simple matter of Find and Replace. Moreover, it works perfectly running interpreted. This is the second time I’ve found something in v17 that works differently compiled vs. interpreted because of Objects. The other was the fact that the interpreter allows you to use method parameters that have not been passed without reporting an error. If we can’t trust the interpreter then the ability to do rapid application development is greatly reduced.

The interpreter behaves in many areas very differently than the compiled code.
This was a design decision in 1992 (4D Compiler 1.0).
Interpreter behaves very “untyped” (variables can switch type during execution), the compiler is very strict.

To give a general answer:
as more “compatibility” settings you are using, as less new feature you should use.
Examples:
If your code is not “nested transaction” ready, don’t use any of the transaction features introduced with v11 or later.
If your code is not Unicode aware, don’t use any of the new text features.
If your code is not object notation ready, don’t use any of the new commands using objects (introduced with 4D v16 R2 or later). Not any of them.

See: https://blog.4d.com/?s=compatibility for a discussion about compatibility settings.

See: https://blog.4d.com/?s=object+notation for features or remarks to object notation.

Well, if the compatibility setting for dot notation affects functionality that does not use dot notation, then it should be renamed although I can’t imagine what it would be called.

The behavior of the interpreter regarding accessing method parameters that are not passed without error is a bug confirmed by 4D. It broke behavior that’s been around for at least 15 years.

: Richard WRIGHT

We have over 500 methods that use periods in their names, some of
which are called via Execute Formula after constructing the name and
so it’s not a simple matter of Find and Replace.
Maybe replacing the dot with another char (underscore?) would help? Anyway I encourage you to remove non https://doc.4d.com/4Dv17R5/4D/17-R5/Identifiers.300-4128320.en.htmlcompliant names> in order to use dot notation freely, if you regret after a while I promise I eat my hat!

I’ve often seen the interpreter saying “it’s ok” while it’s not in compiled mode, one always has to test compiled when there’s a doubt. On the other hand, it seems that interpreted behaviour is closer to compiled across versions, or less permissive at least.

: Arnaud DE MONTARD

I’ve often seen the interpreter saying “it’s ok” while it’s not in
compiled mode, one always has to test compiled when there’s a doubt.
On the other hand, it seems that interpreted behaviour is closer to
compiled across versions, or less permissive at least.

But in this case the compiled code is complaining that that shared object is not being accessed within a Use…End Use structure when it clearly is. It would seem that shared objects cannot be written to use OB Set when running compiled even though it works perfectly interpreted. The only other example of this kind of behavior in the past is when you try to use a local variable in Execute Formula running compiled. It sure seems like a bug in the compiler to me and not some inherent limitation. According to the manual, the Use…End Use structure sets an internal semaphore to ensure exclusive write access. This is being done so it seems very odd that the compiler would be fundamentally unable to handle writing to a shared object using OB Set.

The manual states clearly that Collections can only be used when dot notation is turned on but I’ve seen no such statement concerning shared objects.