Both in Java and BD, you don't need to call the constructor explicitly if it doesn't have arguments.
Right, but if you don't need constructor arguments, you can just use the pseudo-constructor anyway. This discussion is only about the situation where you need to pass in constructor arguments, i.e., where you *do* need to call init().
Again, in Java and BD, this won't happen because of implicit construction.
Often (usually?) an object cannot be reasonably default constructed. Therefore this is also a problem in Java and BD.
<cfset obj = createObject("component","foo",arg1,arg2,arg3) />I don't like that syntax at all. I rather have a new operator any day.
Well, yes, so would I but I suspect we're more likely to get optional arguments in createObject() than totally new syntax like this:
<cfset obj = new foo(arg1,arg2,arg3) />
For a start, making 'new' a keyword might well break code that uses it as an identifier (I know people who define a method called "new" in their CFCs as a constructor instead of using init()). Next, the current syntax uses a string to identify the component / class to be instantiated (and in fact the string can be a file path, e.g., "path/to/my/component") whereas the 'new' syntax requires an identifier directly and treats path.to.my.component as a package name (CF would normally treat that as a variable 'path' with a struct key 'to', which in turn is a struct with a key 'my' etc). So 'new' wouldn't 'fit' CF as well as extending the createObject() function would.
Regards, Sean
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
