Passing Object Pointers vs References - slight 'gotcha'

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
Hi !

A while back there was a brief discussion about the relative merits of passing an object parameter directly vs passing it as a pointer. As I remember, the conclusion was that a pointer wasn’t needed because 4D is just passing a reference to the object - it isn’t copying the object in the called method as it would do for, say, a text field.

So I proceeded to do object library code just passing the object reference directly to save on dereferencing pointers etc. However, now I’ve realised a huge problem with this approach which is that it isn’t portable. For example, as soon as you use the code in a component it breaks because 4D can no longer reference the object across the component-host boundary.

Not only that, even if you pass the object to the component as a pointer, ANY further use if the dereferenced object pointer as a parameter in a subsequent method call will fail.

So, lets say you have a library method that does this:

===== myObjectMethod ===
C_OBJECT($1)

…and you use that anywhere in a component, it will always fail if its argument ultimately originated in a host. (Whereas it wouldn’t fail in a host-only call). This is actually consistent behaviour with other data types when you think about it, but what isn’t consistent is that the other data types wouldn’t work in the host either whereas objects do. (i.e. when you pass an object directly as a method argument, any processing on the object will be reflected in the calling method’s scope as well which would not be the case for, say, a text value).

CONCLUSION
====================
My inclination is to conclude that passing objects directly is not very good practice at all because it doesn’t result in consistent behaviour with other data types and isn’t portable. Worse, it makes the code difficult to audit if you use components because it only takes a single call to break an entire call chain that would otherwise perform 100% under test, either in a host environment or when unit testing the component.

To get consistent and portable behaviour we’d have to do this:

myMethod(OB Copy($object))  <— to behave like a classic parameter pass where the data is duplicated in the called method

or

mtMethod(->$object) <— to behave like a classic pointer, where the source data is processed and not duplicated in the called method

but not

myMethod($object)  <— Iceberg waiting for Titanic
====================

What do other people think about this ? Is anyone else bothering about this distinction ?

Best Regards

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Jeffrey Kain
I agree that the implicit pass-by-reference for objects only is not comfortable nor consistent with the rest of 4D. It will prevent some problems maybe for beginning programmers to not have to worry about initialization, allocation, and deallocation of objects, but it just doesn't 'fit' with how the rest of the language works.

That said, the projects I've used objects with have all been very easy to code in this style, and didn't really cause any problems. I see your point with components, though.

In all, I do wish it was more consistent and more like a blob, but in real life it doesn't seem to be that big of a deal. The only benefit I can see, however, is for beginning programmers who may not understand the ramifications of passing a large object as a normal parameter and not by reference. But how many beginning programmers are left in our community? :)

--
Jeffrey Kain
[hidden email]




> On Nov 30, 2016, at 3:55 PM, Peter Jakobsson <[hidden email]> wrote:
>
> What do other people think about this ? Is anyone else bothering about this distinction ?

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
On 30 Nov 2016, at 22:29, Jeffrey Kain <[hidden email]> wrote:

> I agree that the implicit pass-by-reference for objects only is not comfortable nor consistent with the rest of 4D…..but it just doesn't 'fit' with how the rest of the language works.

Ok, thats all the endorsement I need !

I’m going back to change them all to pointers. Thanks for the feedback Jeff ;)

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Wayne Stewart
Hi,

I'm happy to use them "bare" if they are really being used to pass
parameters to a method but if I want a result back then using pointers or
possibly return the altered object as $0.




Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart
<http://about.me/waynestewart>


On 1 December 2016 at 09:25, Peter Jakobsson <[hidden email]> wrote:

> On 30 Nov 2016, at 22:29, Jeffrey Kain <[hidden email]> wrote:
>
> > I agree that the implicit pass-by-reference for objects only is not
> comfortable nor consistent with the rest of 4D…..but it just doesn't 'fit'
> with how the rest of the language works.
>
> Ok, thats all the endorsement I need !
>
> I’m going back to change them all to pointers. Thanks for the feedback
> Jeff ;)
>
> Peter
>
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
>
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
On 30 Nov 2016, at 23:29, Wayne Stewart <[hidden email]> wrote:

> but if I want a result back then using pointers or
> possibly return the altered object as $0

Yes - I noticed that that works in components as well. The problem is heterogeneous behaviour:

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.

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Douglas von Roeder
On Wed, Nov 30, 2016 at 2:43 PM, Peter Jakobsson <[hidden email]>
wrote:

> Yes - I noticed that that works in components as well. The problem is
> heterogeneous behaviour:
>
> 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.
>

Doesn't this seem to be a function of variable scope?

--
Douglas von Roeder
949-336-2902
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
On 30 Nov 2016, at 23:48, Douglas von Roeder <[hidden email]> wrote:

> Doesn't this seem to be a function of variable scope?

Yes indeed. The component has to duplicate the object so that it can “work” on it within its own scope - thats the correct/classic behaviour. I just think the host should do that as well to get rid of the syntax ambiguity between host (does not duplicate the argument), component (does duplicate) and other variable types (do duplicate in both host and component).

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

David Adams-4
This thread has covered the main points effectively already, so I'll just
tack on some thoughts to the side.

Since it seems that your frustration fundamentally comes down to how
components are implemented in 4D, a couple of other ideas:

1) Give up on components in 4D.

2) If you're using components, consider a "tell, don't ask" approach.
(Miyako nodded towards this concept in recent weeks.) In this case, it
would mean storing the data in the component and telling the component what
to do. In other words, don't keep pulling stuff out of the component and
back into the host for manipulation - do the manipulation in the component.
This doesn't make a whole lot of sense much of the time in 4D, but there
are places where it does. At the least, it's an interesting design
perspective to consider...even if it isn't what you find to be the best fit
in some specific situation.

Okay, a couple of other thoughts:

* I think that what 4D did to use JSON for complex data types is kind of a
great idea. Bravo. But let's not think for a minute that these are
"Objects" in any interesting or meaningful sense of the word. *Nothing* has
been added to the language or compiler to assist with custom types, we
don't have closures ("lamda functions"), there's no object levels of scope,
and no object methods. So, they're structured text with benefits, that's it.

NTK's JSON is still a nice alternative since it's a full JSON
implementation. (Nice for getting JSON in and out of 4D, not just passing
data within 4D.) With NTK, you can pass around a longint reference to the
container very efficiently.

I did a bit of work with PHP a bit back and it gave me a new perspective on
a couple of things. First off, I was using it mainly for Mustache, which
gave me a new appreciation for logic-less templating. It's worth thinking
about before diving into 4DCODE, for example.

But more to the point, I really enjoyed the PHP style of jamming text
together and then explode()ing it into arrays for manipulation. It's very
convenient. Lately, I've found this creeping into my 4D style quite a bit.
Let's say you've got a bunch of content to manipulate and you want to pass
it around. Well, you can pass a bunch of arrays, a BLOB, an object, or a
block of text. Since 'objects' in 4D are nothing but chunks of structured
text, do I always need to hassle and overhead of JSON? No I do not.
Instead, I use TSV (Tab Separated Values) - another kind of structured text
with other benefits. Some benefits:

* Ideal for columnar data that doesn't contain unescapable tabs or carriage
returns as content.

* Small: JSON always adds data with all of that syntactic sugar.

* Easy: So, so easy to work with. Parsing on a CR is a snap and then
parsing lines in a loop on tabs, also a snap. Maybe you want arrays, maybe
you want JSON, maybe you want to do some calculations...it's all easy
enough.

* Flexible: I end up with routines that want some data from a larger
object. Say the host source has 8 values per row. Some routines want 8,
some want 5, and some want 3. And then another one wants a different 3.
Pass in a description of what's needed from the extract routine and get
back your custom collection of 'column'. Either way, $0 is still a block of
text. The calling routine knows what it ask for, so it knows how to parse
it out. The main extract routine only needs to know what to include, not
what to do with it after the fact. A very neat division of responsibilities.

Some disadvantages:
* JSON is prettier, likely to be more self-documenting, and all of the cool
kids use it. I'm actually totally fanatical about JSON, it's the
interchange format we've always needed. So great. Doesn't mean it's the
best fit for every problem.

* JSON is *great* for hierarchical data. It's just a natural fit.

* Larger text blocks are easier to store and see in JSON...they're hard in
flat text files...maybe that's just me.

So, I use JSON and I use TSV, but I find they've each got their uses.

A nod of the head to D3 as well here, it's all about JavaScript....but is
more than happy to read in CSV, TSV, etc. and auto-convert to a JS array of
objects. Why? Because TSV, etc. are a lot more compact wire formats than
JSON and That Is Good.

Right, back to your regular discussion
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2

On 1 Dec 2016, at 00:22, David Adams <[hidden email]> wrote:

> I think that what 4D did to use JSON for complex data types is kind of a
> great idea. Bravo. But let's not think for a minute that these are
> "Objects"

Some very useful points there David. Thanks for your thoughts !

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

John DeSoi
In reply to this post by Peter Jakobsson-2

> On Nov 30, 2016, at 2:55 PM, Peter Jakobsson <[hidden email]> wrote:
>
> myMethod($object)  <— Iceberg waiting for Titanic
> ====================
>
> What do other people think about this ? Is anyone else bothering about this distinction ?


I'm not sure I'm following the issue. I created a compiled component (15.3 Mac) with this method:

C_OBJECT($1)
OB SET($1;"test";True)
OB REMOVE($1;"cool")

Then I called it from the host (interpreted) with this:

C_OBJECT($oTest)
OB SET($oTest;"cool";False)
_TEST1 ($oTest)

After the call $oTest is:

{"test":true}

So the host sees both the added and removed property executed in the component. What am I missing?

John DeSoi, Ph.D.


**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2

On 1 Dec 2016, at 02:34, John DeSoi <[hidden email]> wrote:

> I created a compiled component... the host sees both the added and removed property executed in the component. What am I missing?

Hi John

It can work under various circumstances, but the results are variable. For example your example tends to work ok.

But if you do, say...

==============================================
CREATE RECORD([Table_1])
compSET_OBJECT_PROPERTY_o ([Table_1]object)
SAVE RECORD([Table_1])
==============================================

…where compSET_OBJECT_PROPERTY is a component method that has C_OBJECT($1) and sets a property, then the modification won’t find its way back into the table, even though it may display correctly in the debugger prior to saving.

Then again, if you make the host set a property PRIOR to calling the component, using OB SET then it does work. (But if you only initialise the object using [Table_1]object:=Json Parse({“”}) then it still gets saved as undefined - even if thecomponent set a property value.

I think it’s just undocumented behaviour that cannot be relied upon. You need to use a pointer to get total consistency.

Peter
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2

On 1 Dec 2016, at 10:26, Peter Jakobsson <[hidden email]> wrote:

>  You need to use a pointer to get total consistency.

Just for clarification, there is nothing wrong with C_OBJECT($1) per se.

I’m only talking about the case where we want to manipulate a variable in the calling method. i.e. the cases when one would normally use a pointer with all other data types. Inthose cases I’m saying it appears more reliable to use a pointer for objects as well and not rely on this “new” behaviour.

Also, using $0 to get the result back to the calling method works fine as well.

Peter

(Sorry for the double-posting "spam").

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Rob Laveaux

> On 1 Dec 2016, at 10:36, Peter Jakobsson <[hidden email]> wrote:
>
> I’m only talking about the case where we want to manipulate a variable in the calling method. i.e. the cases when one would normally use a pointer with all other data types. Inthose cases I’m saying it appears more reliable to use a pointer for objects as well and not rely on this “new” behaviour.


Hi Peter,

Thank for clearing this part up. Now let me try to clear up the other part :-)

The only thing to keep in mind is when you pass an undefined object as an argument to a project method. Changes you make inside the project method will not reflect to the calling method, since it was undefined there.

To solve this you can either use pointers as you suggested. Or you can return the initialised object in $0. The last things is what I would recommend. Use it like a constructor function. For example:

C_OBJECT($rob;$peter)
$rob:=Person_New(“Rob”;”Laveaux”)
$peter:=Person_New(“Peter”;”Jakobson”)
ALERT(Person_Greet($rob))
ALERT(Person_Greet($peter))

When you keep this in mind, than there is no problem at all passing objects around as references.

- Rob Laveaux

--------------------------------------------------------
Pluggers Software
Scholekstersingel 48
2496 MP  Den Haag
The Netherlands

Email: [hidden email] <mailto:[hidden email]>
Website: http://www.pluggers.nl <http://www.pluggers.nl/>

--------------------------------------------------------



**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

David Adams-4
In reply to this post by David Adams-4
> I think that what 4D did to use JSON for complex data types is kind of a
great idea. Bravo. But let's not think for a minute that
> these are "Objects" in any interesting or meaningful sense of the word.
*Nothing* has been added to the language or compiler to
> assist with custom types, we don't have closures ("lamda functions"),
there's no object levels of scope, and no object methods.
> So, they're structured text with benefits, that's it.

Rob Laveaux just posted me a note about some imprecisions in my comments
above. (Importantly, to remember that the C_OBJECT representation as JSON
is just that - a serialization of a more efficient underlying data
structure.)  I'm hoping that he'll make some comments here as it's always
good to get Rob's perspective and knowledge on the list.
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
In reply to this post by Rob Laveaux
On 1 Dec 2016, at 10:58, Rob Laveaux <[hidden email]> wrote:

> Use it like a constructor function

Yes - that looks a very nice way of doing it Rob.

(P.S. You’ve reminded me of my first foray into OO: pig=new(animal), pig.eat, cow.moo. I decided it was good for farming but not so great for business programming, so I stuck with 4D ;) )

(PPS - only joking, I know OO is good for other stuff as well ;) )

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

KirkBrooks
In reply to this post by Peter Jakobsson-2
Peter,
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 <[hidden email]>
wrote:

> 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)
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

KirkBrooks
In reply to this post by David Adams-4
David,


On Wed, Nov 30, 2016 at 3:22 PM, David Adams <[hidden email]> wrote:

> 1) Give up on components in 4D.
>
​They are getting better.



> 2) If you're using components, consider a "tell, don't ask" approach.
> (Miyako nodded towards this concept in recent weeks.) In this case, it
> would mean storing the data in the component and telling the component what
> to do. In other words, don't keep pulling stuff out of the component and
> back into the host for manipulation - do the manipulation in the component.
>
​This is the direction my experience has led me over the last few years.
Components are pretty useful to me for providing a library of basic
functionality (math, string, date, file functions). I've got a method
editor I like and ​a Structure Explorer that's handy.

​What I personally haven't had great success with is building complex
components (like 4DPOP or Peter's Code Wallet). I just may not have the
patience. But getting back to me I seem to have settled into the using
components as functions and independent tools which embrace that "tell,
don't ask" philosophy. ​

First off, I was using it mainly for Mustache, which
> ​ ​
> gave me a new appreciation for logic-less templating.

​+1 on this. I'm using it in a project where I need to convert a JSON into
a web page. I took a run at using 4D tags and doing it on the 4D side. Not
pretty. Mustache and Handlebars was so much easier. ​


> Instead, I use TSV (Tab Separated Values) - another kind of structured text
> with other benefits.

​I think TSV (and CSV) gets overlooked a lot because it's sort of like your
father's Oldsmobile - been around forever and no longer cool. But like you
say it's got some real advantages. In addition to the ones you outlined
I'll add how easy it is to manage and clean up the data prior to importing
using a decent text editor and/or google spreadsheets. I continue to do a
lot of this sort of thing with various price lists in various formats. ​

​And since the old 32k limit on text blocks went away (a long time ago)
​you can setup an import form allowing a user to paste in the TSV text. I
do this also with everything from a few lines to files a few megs in size.
Quick and easy.

--
Kirk Brooks
San Francisco, CA
=======================
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

Peter Jakobsson-2
In reply to this post by KirkBrooks
On 1 Dec 2016, at 16:16, Kirk Brooks <[hidden email]> wrote:

> I use all three of the instances discussed: direct referencing of the $1
> object, pointers to the object and returning an object as $0.

Hi Kirk

The problem is, it shouldn’t really work like this IMO.

Strictly speaking it’s a bug - the fact that a method argument remains coupled to it’s source in the calling method despite being explicitly passed by value rather than by reference.

myMethod($object)  <— 4D’s pass “by value” syntax
myMethod(->$object)  <— 4D’s pass “by reference” syntax

At least thats the way I’m increasingly seeing it ;)

4D have done a fantastic job of making this very complex data structure into “just another variable” for us in every other respect which I think is a bit of genius actually.

It’s just this 1 banana skin that’s been left in place. I think they should get rid of it (the coupling between caller and called) and make it observe the same syntax as all other data types. (The “banana skin” behaviour could be left in place with one of those compatibility options in future upgrades for safety).

Peter

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Passing Object Pointers vs References - slight 'gotcha'

KirkBrooks
Peter,
I'm not really disagreeing with you. Having all this flexibility isn't
always a good thing. I'm not sure it's strictly a 'bug' because it's
consistent behaviour within a context. But the boundaries of the context
aren't visible when you're using it and that is a problem.

And I could have phrased my meaning a little better when I said I use all
three approaches. I've used all three but I've mostly abandoned returning
an object in favor of the other two as I described. The main reason being I
write most function methods that do anything complex to return an error
message (blank is good) and write the results to objects or variables
passed as pointers.

On Thu, Dec 1, 2016 at 8:36 AM, Peter Jakobsson <[hidden email]> wrote:

> On 1 Dec 2016, at 16:16, Kirk Brooks <[hidden email]> wrote:
>
> > I use all three of the instances discussed: direct referencing of the $1
> > object, pointers to the object and returning an object as $0.
>
> Hi Kirk
>
> The problem is, it shouldn’t really work like this IMO.
>
> Strictly speaking it’s a bug - the fact that a method argument remains
> coupled to it’s source in the calling method despite being explicitly
> passed by value rather than by reference.
>
> myMethod($object)  <— 4D’s pass “by value” syntax
> myMethod(->$object)  <— 4D’s pass “by reference” syntax
>
> At least thats the way I’m increasingly seeing it ;)
>
> 4D have done a fantastic job of making this very complex data structure
> into “just another variable” for us in every other respect which I think is
> a bit of genius actually.
>
> It’s just this 1 banana skin that’s been left in place. I think they
> should get rid of it (the coupling between caller and called) and make it
> observe the same syntax as all other data types. (The “banana skin”
> behaviour could be left in place with one of those compatibility options in
> future upgrades for safety).
>
> Peter
>
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
>



--
Kirk Brooks
San Francisco, CA
=======================
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

RE: Passing Object Pointers vs References - slight 'gotcha'

Timothy Penner
In reply to this post by Rob Laveaux
I think this topic relates closely to a feature request from Rob:
http://forums.4d.fr/Post/EN/18642977/1/18642978#18642978 

-Tim


-----Original Message-----
From: 4D_Tech [mailto:[hidden email]] On Behalf Of Rob Laveaux

>The only thing to keep in mind is when you pass an undefined object as an argument to a project method. Changes you make inside the project method will not reflect to the calling method, since it was undefined there.

**********************************************************************
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:[hidden email]
**********************************************************************
12