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().I could have sworn you just indicated that you didn't want to see logic in the pseudo-constructor area. Wouldn't logic be best suited for a constructor even if it didn't take arguments? I say yes.
Often (usually?) an object cannot be reasonably default constructed. Therefore this is also a problem in Java and BD.That is not my experience.
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.That didn't stop Macromedia from making other common identifiers reserved words. Further, there is nothing wrong with a new keyword that requires a full specified name. And, it would fit fine with CFML.
-Matt
----------------------------------------------------------
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]
