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?
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?