On 1 Dec 2016, at 20:56, Rob Laveaux <rob.lave...@pluggers.nl> wrote:

> Honestly I disagree with you on this. There are other “data types” in 4D that 
> are passed by reference. For example hierarchical lists, plugin areas, menu 
> references, XML references.

AH ! I you might just have given me a lightbulb moment Rob.

After you posted that I went back and re-read your other comment about 
“Undefined” vs “Defined” as well as re-reviewing my original code in the light 
of your post. So you’re saying the “inconsistency” is not where I thought it 
was (i.e. in the syntax) but rather in the fact that we're so used to 4D 
language objects always being pre-defined as soon as we start to use them ? But 
if those same objects (of any type) weren’t pre-defined we’d discover that they 
behaved consistently with the object behaviour ?

Well in fact I just tried it and of course you’re right !…..If I do this:


…and assign a value to that variable inside the method (via the pointer) then a 
different result occurs depending on whether the passed variable is defined or 
not. If we do this:


mySetValue(->$anyUndefinedVar) `     (where mySetValue assigns $1»:=1)

….then the values remain coupled. If we inspect the debugger while still 
executing the method, but after the assignment then it reports $1->=1 (in the 
called method’s scope) and $anyUndefinedVar=1 (in the calling method’s scope). 
But if we do this…

mySetValue(->$anyUndefinedVar) `     (without pre-defining it)

…they they decouple. Debugger reports $1->=1 (in the called method’s scope) but 
$anyUndefinedVar reports undefined (in the calling method’s scope) - exactly 
the same behaviour I saw with the objects.

I think what’s confusing (if you don’t already know about it) is that when you 
call CREATE RECORD, we are used to all the fields being defined. (Even text 
fields contain “”). So when I passed an object field as a parameter to a 
C_OBJECT($1) method I was unaware that I wasn’t actually passing anything at 
all (i.e. there is no handle to pass) and that the calling method would create 
a handle with the first OB SET….a handle which would never find its way back 
into the field. All is becoming clear now.

So, in summary:
1. the object handle is like an XML reference. We can pass it all over the 
place as long as it’s already defined
2. But we need to watch object fields because they are not initialised on 
create record and so we need to test if they are already defined or not before 
passing them as a parameter to any methods
3. If we pass an object field (or variable) as a pointer then it’s ok to define 
the object in the called method as long as we assign the object reference back 
to the field via the pointer
4. We don’t need to worry about components - they work exactly as the host. It 
only depends on where the object is defined because that’s where the object 
reference “comes alive"
5. There’s no syntax inconsistency as I was alluding to previously because we 
are passing a reference to the object data, not the object variable (just like 
we do with XML references)

Is that correct ? If so, thats 2 beers I owe you now (+ the rest). Can’t 
remember what the last one was for….oh yeah, NTK/Active4D enhancement.

Apologies to everyone for the wild goose chases in getting to this point but I 
just had to get to the bottom of this due to some object-intensive work I’m 
doing at the moment. Also many thanks for all the contributions and patience !!

Best Regards


4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to