Thanks for the response sammy.
thats true, I hadn't thought of the fact that you can type things with
just the name.
I guess the real question is, if this is a problem, that an external
resource to your application, whether its something you wrote or
someone else wrote, is strictly types with fully qualified object
names, is there anything you can do if you need to have multiple
copies of the resource and need the ability to use both at the same
time?
On 1/29/07, Sammy Larbi <[EMAIL PROTECTED]> wrote:
Hi Ryan,
I'm not a huge fan of typing my arguments and return types, so I'll get
that out of the way and you can take the rest of this with that in mind.
1) There isn't really a parallel that I can think of in the Java world.
Basically, any external libraries are built with your code, so there
aren't really any "mappings" to speak of in that regard.
2) I'm not in the habit of providing absolute paths when I do type my
arguments, and as you've pointed out, it isn't a good idea at least in
that regard. I'll just provide "foo" as the return type. Not sure how
that works in very complicated directory structures, but at least within
each component, it will work. It is one of the problems I had with how
CFUnit relied within itself all the way down from the org package.
-Sam
Ryan Guill wrote, On 1/29/2007 12:07 PM:
> Hey guys,
>
> I'm working on designing a new project, and in thinking through some
> of it I came across this. Sorry if this is a newbie question, but
> just thought I would get some reactions.
>
> When typing objects in cf, the typing depends on how the objects were
> created, not on the actual path to the objects (physical path).
>
> For instance, say I create an object called foo in the {application
> root}/com/ directory, so {root}/com/foo.cfc
>
> and I give it an init call like so:
>
> <cffunction name="init" access="public" returntype="com.foo">
>
> <cfreturn This />
> </cffunction>
>
> Okay, so now I go to a new page somewhere and I create an obect out of
> the component like so:
>
> <cfset variables.foo = createObject("component","com.foo").init() />
>
> All good right? The return type says com.foo, the create object uses
> com.foo and everything works fine.
>
> Okay, now lets say I make a new mapping in cf to the com directory,
> called com_mapping.
>
> So now I try to create an object out of the cfc using the following code:
>
> <cfset variables.fooWithMapping =
> createObject("component","com_mapping.foo").init() />
>
> An error is thrown, because the path to the cfc that you are using the
> create the object is not exactly the same as the type specified in the
> returntype of the init... Since foo is still accessible using
> com.foo, and that is the actual path to the cfc, shouldn't it still
> work?
>
> If you change it to returntype="any" both calls work, but you loose
> that type checking.
>
> Now, I know all about duck typing and the possible performance
> concerns of typing, but at the end of the day, the typing was intended
> to be used like this, and this seems a little illogical? I don't have
> a java background and don't know if this issue would translate well to
> the java world, but I would be interested in seeing if there was some
> sort of correlation.
>
> For an example of why this matters, imagine that you had multiple
> releases of the same application, myApp v1 and myApp v2 that you
> wanted to have both available at the same time on the same server. So
> for example:
>
> {domain}/myApp/v1/ and {domain}/myhApp/v2/
>
> The same code base except v2 is just a newer copy with some new
> features right? Well lets say the application uses an external
> resources such as some sort of framework. Lets say for example its
> transfer. So v1 of the application uses v0.5 of transfer, and v2 of
> the application uses v0.6 of transfer. If transfer uses typing in its
> objects (I really have no idea, ive never used transfer, this is just
> an example) then you can't just use a new mapping to get to the new
> version in v2 from v1.
>
> Sorry for the long email, just curious if anyone has ran into this and
> possible workarounds... because if the framework uses typing in its
> objects (this would also apply to inheritance of objects I would
> think) then its not really an option to go through and change return
> types to "any" everywhere...
>
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
Ryan Guill
A Deep Blue
[EMAIL PROTECTED]
www.ryanguill.com
(270) 217.2399
got google talk? Chat me at [EMAIL PROTECTED]
www.ryanguill.com/
A Deep Blue Blog: www.ryanguill.com/blog/
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
