Well the reason I am interested is because COAL was intended to be a
good example of the service locator pattern. One of the parts (a big
part) of the service locator pattern though is the caching of objects,
so that if you request the same object (or service) over and over
again that it would hold a copy and save you some cycles. and now
that I am writing this its starting to make more sense that it is the
"service" locator pattern, and a service is stateless, so it wouldnt
matter if it was cached, it should be cached, its a singleton! damn.
well, while the other part of the service locator pattern works very
well for COAL, the caching part of it (it was designed to be cached
before instantiation, so that you could pull a "fresh" copy out and
isntantiate it again and go, it just would just save the
createObject()...) is basically worthless in this situation. I had a
sneaky suspicion of this for a while and just haven't found the time
to test it out. Guess this answers it.
On 9/26/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> While I'm at it, I should mention that I store my object state in a
> very specific way:
>
> 'this' contains immutable constants (even though CF doesn't have such a
> concept)
> 'variables' contains ethereal state (like caches)
> 'variables.my' contains "real" state
>
> 'variables.instance' seems to be a more common name for
> 'variables.my', but I got into the habit of calling instance variables
> "my" long ago (before I started doing CF), and the convention has
> stuck.
>
> Creating a memento for such an object is as simple as duplicating the
> 'variables.my' struct. That's not opaque, of course, but it is an
> encapsulated representation of the object's state, which is really
> what you're looking for. If you want it to be opaque, you could
> serialize it and encrypt it, but if you ask me, that's way overkill.
>
> cheers,
> banreyb
>
> On 9/26/05, Ryan Guill <[EMAIL PROTECTED]> wrote:
> > alright, i follow you...
> >
> > hmmm
> >
> > On 9/26/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> > > Not native to CF. Implementing a 'clone' method is pretty trivial though:
> > >
> > > function clone() {
> > > var newObj = createObject("component", getMetaData(this).name);
> > > newObj.setMemento(getMemento());
> > > return newObj;
> > > }
> > >
> > > Where getMemento and setMemento return and accept an opaque
> > > representation of the object's internal state.
> > >
> > > cheers,
> > > barneyb
> > >
>
> --
> Barney Boisvert
> [EMAIL PROTECTED]
> 360.319.6145
> http://www.barneyb.com/
>
> Got Gmail? I have 100 invites.
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
--
Ryan Guill
BlueEyesDevelopment
[EMAIL PROTECTED]
www.ryanguill.com
(270) 217.2399
got google talk? Chat me at [EMAIL PROTECTED]
The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com
www.ryanguill.com/
The Roman Empire: www.ryanguill.com/blog/
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
