I encountered this as well - a bit perplexing the first time. As pointed
out it makes sense on one hand (crossing the component name space boundary)
but just looking at code there's no cue to indicate which side of that
boundary you're on.

Maybe there could be another color option in the method editor for
Component Methods?

A more complex solution could be an attribute like "Execute on server" -
"Execute on host" as an extension of the "Share with host" attribute. But
that's most likely overkill.

I use all three of the instances discussed: direct referencing of the $1
object, pointers to the object and returning an object as $0. This is
ignoring using c-objects simply for param passing.

I'm tending to favor passing a pointer to the c-object when I want to
modify it for exactly the reasons you started out with - it works the same
way no matter where I call it. For me these aren't situations where the
time penalty for dereferencing the pointer matters.

I use direct referencing in very controlled situations - like on forms or
helper methods that are only called by some parent method.

This is another case illustrating the rich diversity of the 4D language but
also the inconsistencies of it.

On Wed, Nov 30, 2016 at 2:43 PM, Peter Jakobsson <>

> Consider 2 calls to exactly the same method but in different contexts:
> parseADDRESS($myAddressObject) <— host method
> parseADDRESS($myAddressObject) <— component method
> In the 1st case, parseADDRESS behaves like a pointer passing, where
> $myAddressObject will be modified.
> In the 2nd case parseADDRESS behaves like a non-pointer, makes a copy of
> the data and $myAddressObject will *not* be modified.
> --
Kirk Brooks
San Francisco, CA
4D Internet Users Group (4D iNUG)

Reply via email to