> That's all well and good, but CF has set a precedent of flexibility in that > you can pass arguments, in any order, as name/value pairs. This > flexibility doesn't occur when calling methods in the "super" object, which > is unexpected behaviour. Macromedia agree with me, as it's being > addressed.
Oh - I am not saying that super.init() should not work the same as the rest of CFMX. It should be possible to pass named arguments or an argument collection. My comments are very much in tune with the tone of the rest of the post in which CFMX is being compared to other OO languages. In addition, I am answering Taco's questions in the context he has asking them - rather than taking a stand on any quirks in CFMX specifically. > Now, I'd *prefer* if the typeful <cfargument> tags were used simply to > identify overloaded methods (so you could have methods of the same name > with a CFC, but different argument-sets), and there was no sense of > REQUIRED="FALSE". Yes, this would be nice. There are lots of other things that would be nice in CFMX as well (such as interface's - which would also help resolve some of these issues). But from what I can tell we aren't getting all those things (even with some super "strict" mode flag that can be set somewhere). > foolish to draw parallels to how *other* languages do it I agree - which sort of makes the general argument of the post fairly impotent. It's a catch-22. On one hand there is some expectation that CFMX should behave like other OO languages - but that we shouldn't compare it to other OO languages because it is different. At some point in time we either have to have CFMX in the OO fold or out of it. I'd prefer it to be IN (but argue that it lacks some of the sophistication required to keep it IN). As Sean put it in a previous post "why cant you work around it" and the answer was "I dont want to". Hence the expectation that some OO functionality that isn't in CFMX should be in there. > So do you have all your <cfargument> tags marked as required, and always > pass all of them as an ordered list, as opposed to name/value pairs? In an INIT method I have the following rule: "All arguments passed to an INIT method must have DEFAULT parameter (i.e. they should be able to be called like a default constructor in traditional OO) and that the descendant class calling the INIT method must ensure the parameters they do pass on to any ancestor INIT method are passed in the correct order." In fact, a traditional OO environment would enforce this automatically. In other methods, the rule of "best fit" applies. So it is up to the individual developer to either use named pairs (generally preferred) or correct order. This may be based on context or readability more than maintainability. > Well you *can* but only via inheritance: an extending component's methods > will overload the extending component's ones. This is where the problem > crops up. I am a stickler for terminology. There is a difference between "overloading" and "overriding". Inheritance is an "overriding" mechanism. The descendant class completely replaces the method that the ancestor class provides. "Overloading" allows for a method of the same name to have different implementations depending on the parameter set passed. So, "overloading" in CFMX is accomplished by having ARGUMENTS with a REQUIRED='true' (as you previously mentioned) and then determining (with logic in the method against the arguments provided) what the method should do. SO - once again - this is WHY super.init() MUST have named arguments and argument collection (because it is then possible to write a base method INIT that can decide at runtime how it should behave). --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
