Instantiating, returning object references, and destinations

[PathsAndAngles]

Here's something I'd like to gain a better understanding of, because I'm looking for anything that will speed up my processes. I will try to describe and pseudo-code this as well as I can. Apologies in advance if anything is unclear.

I have a CFC that is instantiated and utilized in two different ways. In the first way, the object is created, and a method within it is immediately invoked inline, which initializes some properties within that object, and finally returns This. The transient local object reference is then used to invoke other methods within it, and then it's abandoned as the request runs it normal course.

myLocalObject = CreateObject("component", "myCFC").setStuff(theseArgs);

if (myLocalObject.checkStuff(thoseArgs))

    myLocalStruct = myLocalObject.makeStruct();

In the second way, the object is created blindly, and the object reference is stored in a property of the calling CFC. Later, that stored object reference is used to invoke the same setStuff() method, but here I don't care about the object reference being returned by that method, and so I do not provide a destination variable for it.

This.myStoredObject = CreateObject("component", "myCFC");

...

This.myStoredObject.setStuff(theseArgs);

if (This.myStoredObject.checkStuff(thoseArgs))

    This.myStoredStruct = This.myStoredObject.makeStruct();

There are additional esoteric operational details relating to both usage scenarios which make doing things one way or the other sensible. So, without looking for answers regarding whether or not I should rethink how my objects are instantiated, I want to know more about how CF performs when a component method is returning a reference to the containing component, but that returned value has no destination. Should I always provide a destination, even if it's just a dummy variable? Or should this even be a concern of mine? Ultimately, I suppose I would feel better if the setStuff() method never bothered to return This, if I was invoking it as a void command, rather than a function returning a value. I'd just like to hear from the forum members whether what I am doing here should be changed in any way, to avoid any inefficiencies.

Thanks!

Christopher

[Charlie Arehart]

Hi, Christopher. Others may have more helpful thoughts, but I’ll share a couple.

First, I would note first that (other than the curious reference to “this” in the second example, as a prefix to the variable holding the instance) both will of course produce the same result, in terms of the method execution. But you’re asking “beyond that”, right?

The only substantial difference in the second is that you end up with an instance of the CFC (saved in myStoredObject), against which you can perform additional method calls. That would be the main reason one typically would do that versus calling the method WHILE instantiating it, as in the first example.

Indeed, if you WERE going to call more than one method in the instance then you’d want to go with the second. If you’re not, there’s no real substantial difference. A minor argument could be that if you’re not calling it more than once, the second example causes the instantiated instance of the CFC to live until unnecessarily to the end of the request.

As for that “this.” reference in the second example, that’s curious. Unless the code (doing the instantiation) is itself in a CFC, it would not make sense to refer to it with a this. prefix. Any thoughts there?

I would note finally that if it IS being called within a CFC, then if THAT CFC were itself stored in a shared scope, like session, application, or server, then that CFC living longer means that this CFC you would instantiate and store in that this scope would mean that this instantiated CFC would ALSO live still longer (beyond the life of this request doing the instantiation in the second example).

Is that helpful? Anything you may want to clarify? And any others want to chime in?

/charlie

[PathsAndAngles]

Thank you, Charlie.

Let's get the minor matter out of the way. My second example is indeed occurring within another CFC. That CFC is responsible for "priming" an engine which is comprised of several other CFCs, all of which are blindly instantiated, as shown, when the parent CFC is instantiated, and those object references are stored in the fields of a structure which is a property of the parent CFC. That's why This is being used there. And, yes, the key reason for the second methodology is that those little engine objects are called repeatedly during the request. The parent CFC is part of a larger instantiation of objects, and a loop is repeatedly calling into it, requesting things of those stored engine objects, which need to remain persistent throughout the loop.

My first example is from a completely different area of the application, where there is no loop involved, and the same engine objects are only ever invoked once throughout the request. It is there where having a method within the engine object return the object reference is advantageous, so that the necessary initialization based upon input args can occur, along with the return of the object reference to the calling code, all on the same line. A couple of other method calls are made using the local transient variable holding the object reference, but it does not need to be stored anywhere for the purpose of repeated access.

It just messes with my OCD to think that the setStuff() method is advantageously returning the object reference for my local use in the first example, where in the second example it is still doing the same, despite the fact that I have no use for what it is returning. I already have an object reference in the second example. I just don't want to maintain two separate chunks of virtually identical code, one that returns the object reference, and one that doesn't.

I take it that, overall, I don't need to worry myself over this?