> Don't you mean www.cflib.org? Yes, sorry (why did i say www.udflib.org...? I don't know, at least it is more clear for the explanation ;).
> Question: (dunno if anyone has the answer to this) Do CFC's share methods in > memory, or does each new component created have its own instances of all the > functions defined in the cfc which take up their own space in memory? This is an excellent question. I also wonder about this. The thing I know is that once a CFC instance is loaded in a persistent scope (session or application), if you modify the CFC definition, it is not taken into account by the "old" CFC instance. You have to reload a new instance to get the new definition. Benoit Hediard -----Message d'origine----- De : S. Isaac Dealey [mailto:[EMAIL PROTECTED]] Envoy� : lundi 30 septembre 2002 18:23 � : CF-Talk Objet : RE: UDF Vs CFC (was RE: So many problems with CFC scopes...) > But, in some cases CFCs might be more appropriate than UDF to encapsulate > generic logic : when you need to have an object-oriented logic. > Indeed, the advantage of CFCs over UDFs is their ability to have (or > simulate) an 'object-oriented/object-based' behaviour. > For example, CFC are great to be used as "wrapper" of existing java > classes > (it keeps the object behaviour of the java class and hide its complexity). > With CFC, you can manipulate objects that are "persistent" during the > request : > - create an object, > - call object.method1(), > - call object.method2()... > The object keep his state/properties in between each calls. > With UDF, you can't really have this kind of approach. Actually you can if you structure the UDF's correctly, however, I would expect CFC's in most cases to be a better solution... But as a for instance, you could define a library of UDF's for an application which take in ID's which the UDF's use to identify and manipulate objects which are persistent in request or other scopes or which take in structures from those persistent scopes. The syntax is different, but the end result is similar. request.myobject.dump(); dump(request.myobject); request.myobject.setShippingAddress("123 3rd St","Dallas","TX","55538"); setShippingAddress(reqeust.myobject,"123 3rd St","Dallas","TX","55538"); Even before CF 5 and UDF's, some people managed to create object-oriented features in ColdFusion using includes and cfmodules with things like cfObjects and smartobjects and Tapestry was on its way there, though the best of it didn't happen until CF5. However, the syntax provided by CFC's or other object-oriented languages does encourage thinking about the encapsulated functions or methods as a part of the object, which is helpful, and I suspect they have other advantages in addition. > So, for generic logic encapsulation, I would use : > - UDF / udflib.org for procedural logic (functions), > - CFC / cfczone.org for object-oriented logic. > But, again, this is in my opinion, so I prefer to stop here otherwise it > is going to be another never-ending thread... ;) > This is really a matter of personal preference/coding style. Don't you mean www.cflib.org? Question: (dunno if anyone has the answer to this) Do CFC's share methods in memory, or does each new component created have its own instances of all the functions defined in the cfc which take up their own space in memory? The one way saves memory, the other way theoretically might allow you to modify a method of one component on the fly without altering the definition of the CFC. S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
