ummm... been there doing that. I am editing that article :) I am just not sure what the right level is to edit it to....
Dana On 2/6/07, Cameron Childress <[EMAIL PROTECTED]> wrote: > > Zaphod is right - they are not the same thing. The article is > confusing that though. > > I wouldn't generally expect the average CF person to know this stuff, > but that's really just because most of the CF community grew up in > procedural-land. We are now heading squarely into OOP-land. I would > definitely expect a college CS grad to know it, and it's old hat for > Java people. I would also strongly encourage you to actively seek out > and learn about OOP and Patterns - knowing about them will help your > ability to write effective code, to understand other people's code, > and to find a job. It will also help you get more from the articles > like the one you're quoting from. :) > > -Cameron > > On 2/5/07, Dana <[EMAIL PROTECTED]> wrote: > > ah thank you for explaining that to me. That helps a lot. But my > > question still remains: does the average CF user already know this? > > > > On 2/5/07, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > > > decorators are not the same as inheritance, more like a different type > of > > > inheritance. If you take for instance a cfc that in your init > function, > > > you pass in another cfc that has a base set of functions. Your cfc > can use > > > those functions and "decorate" it with more functions. > > > > > > That said, you could have a manager cfc that in your init you pass in > a > > > person cfc and that would be mimicking inheritance. The main > difference > > > there would be normal inheritance is a compile time event vs decorator > is > > > runtime. > > > > > > > > > > > > On 2/5/07, Dana <[EMAIL PROTECTED]> wrote: > > > > > > > > hehe. Ya well, overly wordy it is, and yes, it does look a lot like > > > > inheritance, good point. Which your average developer does not need > to > > > > have explained, correct? SO that is one issue -- how is this > different > > > > than inheritance, and if not all all, why are we explaining it. The > > > > other is this decorator mentioned in passing, which is not > explained, > > > > and I am thinking should be? I should probably mention that I am > > > > trying to elicit a rewording from someone, not just trying to read > it, > > > > and that is why I am asking these questions > > > > > > > > On 2/5/07, Cameron Childress <[EMAIL PROTECTED]> wrote: > > > > > That sounds like a overly wordy description of inheritance. > > > > > > > > > > -Cameron > > > > > > > > > > On 2/4/07, Dana <[EMAIL PROTECTED]> wrote: > > > > > > ok so...suppose I say > > > > > > > > > > > > ' ...provides functionality for the specified decorator to also > > > > > > automatically extend all the public methods of the generated > Object. > > > > > > This means that within the CFC designated to be the decorator, > it has > > > > > > access to all the methods that are generated, but also has the > ability > > > > > > to overload those methods, and overwrite or extend the default > > > > > > functionality." > > > > > > > > > > > > this requires no further clarification? I find this slightly > rough > > > > > > going, but I am entertaining the possibility that this is cause > I'm > > > > > > me... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 Experience Flex 2 & MX7 integration & create powerful cross-platform RIAs http:http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Community/message.cfm/messageid:227001 Subscription: http://www.houseoffusion.com/groups/CF-Community/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.5
