Well,
Much has happened since my original email but I thought I would share with you all (most probably already knew it but for those in the back who haven't).
In CFMX, it's a managed language as we know so the whole Garbage collection is pretty much automated. I thought about that a bit and agree that its probably a very good thing as this way we don't have to think about "memory" allocation problems like most other languages.
This didn't help me though in the end as if I have a "Controller" object that handles its subset of objects and one of these subsets makes a reference to another object outside of its little working model - things start to go pair shaped.
That being said, I always had a nagging feeling about making object references deep down, as I felt it was making this node of objects dependent on another node(s) resulting in this object house of cards. I'm all for coupling when it needs to be done but as someone pointed out on here, if things don't fit look to break realtionships off.
It wasn't until I had to help a co-worker with a VISIO concept where we needed to take a .NET QuerySet and dynamically loop over each "shape" within visio and populate it with custom values via VB Script.
I looked at it and it hit me clear as day as to the power of an Object Model such as COM or DOM (not sure on the actual differences of the two not a vber) but ownerDocument or Application is always on each nodes object tree so to speak. It always has a reference to its top most parent and hardly ever to its actual parent (Ie an object doesn't have to know who it belongs to just its topmost parent).
This to me seemed a far better solution then having subset objects relying on other objects by reference simply so it can make sure when it validates itself the object in question is Live and in memory.
This got me thinking and I took a closer look at Mach-II framework again and sure enough I noticed AppManager being passed around heaps. Can't but help see the MachII guys saw the need to refer back to its parent "domain" for better word, for information about its existance outside of itself. It's a fine line to tread though in that it's easy to object chain itself rather then simply ask a question and let the manager do it..
In DOM for example if you were nested 20 levels deep and needed to know if an object by the id of "scott" does infact exist (to carry out some logic of some kind) - you made use of the method "document.getElementById('')" rather then "document.body.mynestednode.nodeblah.scott" because that's a fixed address ...for now....
Document being the key, its always accessible by "ownerDocument" much like in Mach-II "AppManager" is our "ownerDocument".
This also has me thinking more about the merits of DSN arguments and so forth, in that a large majority of the time in CFMX we always need to refer to the "applications" top most part to hunt stuff out.. DSN's, Objects Existance, cachemanagers etc..by passing down a reference per object creation (that's needed mind you, not all objects need to know about its top) its far easier to handle validation and get central routines.
This then basically allows you to simply snip that top objects existance from the entire system by simply removing what ever reference there was to the actual top _root resulting in a cascade of deletes via the internal garbage collection. It does carry a key burden, your entire object tree relies on your top most object - not a bad thing considering articles like Hals recent one about Domain Models and relationships within them.
Amazing how some things stare me in the face for years and I consider myself to "know" DOM..yet I really didn't. I found profound religion in the thought everything is a node. A node can be element, attributes, plain objects etc...
I know most here will object (heh no pun intendend) but I, like hal, would of liked a inbuilt propery of objectId for each runtime instance created in memory - further more a parentObject system would also be useful - for thos pro-DOM'ers hehehehe.
Regards
Scott Barnes
http://www.mossyblog.com
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Barry L Beattie
> Sent: Thursday, 20 January 2005 12:03 AM
> To: [email protected]
> Subject: Re: [CFCDev] Objects byReference
>
>
> >> If you have copied the struct into another variable (inside your
> >> objects) then the key will remain in the copies
>
> sure the key will remain as a local copy but that also means
> it's no longer pointing to the origional copy, yes?
>
> so "<cfset objA = objB />" is just making "objA" as a
> reference to "objB" since they're complex values?
> the same holds for "<cfset _config = arguments.objConfig />", yes?
>
> imagine some decorated objects ("controller" with a "service"
> and a "config") stored in, say, application scope.
>
> if I pass a reference to the "config" as an argument to the
> init of the "service" - *and then* clear that config struct
> key from the "controller", have I still got a reference to
> the origional from deep within the "service"?
>
> thanx
> barry.b
>
> (code written from memory - excuse the errors)
>
> <cfcomponent displayname="objController"> <cfset _config =
> structnew() /> <cfset _service = structnew() /> <cffunction
> name="init">
> <cfset _config = createObject("component", config).init() />
> <cfset _service.student = createObject("component",
> student).init(objConfig="#_config#") />
>
> <!--- so what happens if I delete the passed CFC reference
> here? --->
> <cfset structDelete("variables", "_config") />
> <!--- have I just passed in a reference to a (now)
> non-existant object
> or forced a copy to be made in the service --->
>
> <cfreturn this />
> </cffunction>
> ... ... ... etc ... ... ...
>
>
> <cfcomponent displayname="objStudent">
> <cfset _config = structnew() />
> <cffunction name="init">
> <cfargument name="objConfig" type="struct" />
> <cfset _config = arguments.objConfig />
> <cfreturn this />
> </cffunction>
> ...etc...
>
> NOTE: why bother doing this? so I can call up to it within
> the services - like this <cfset dirRoot =
> _config.getRootPath() /> which means that if I run
> "_config.setRootPath(path)" elsewhere, the changes should be
> picked up here in "the deep"
>
> --
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com
> http://promo.mail.com/adsfreejump.htm
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by
> Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
