- access (public, private, package, remote)
- return type
- argument types
- default values
public string function greet(string name, string greeting = "Hello") {
return greeting & " " & name;
}
The access and types can all be omitted:
return greeting & " " & name;
}
function greet(name, greeting = "Hello") {
return greeting & " " & name;
}
That's equivalent to:
return greeting & " " & name;
}
public any function greet(any name, any greeting = "Hello") {
return greeting & " " & name;
}
We also decided that arguments should be optional - which is a change to current behavior (but one that will not break any existing, working code which is currently passing all declared arguments). In order to specify an argument is required, we decided to add required:
return greeting & " " & name;
}
public string function greet(required string name, string greeting = "Hello") {
return greeting & " " & name;
}
This is one of many changes we've agreed should be in core CFML. We hope you like it!return greeting & " " & name;
}
26 responses so far ↓
1 Dan Vega // May 8, 2009 at 7:27 PM
2 Aaron Greenlee // May 8, 2009 at 8:31 PM
3 Russ // May 8, 2009 at 8:52 PM
Now how about adding support for component declarations inside cfscript?
Here's another idea: implement a specific file extension that compiles cfscript so we don't have to wrap everything in cfscript tags. Maybe you could name it ".cfs" (ColdFusion Script)? (I'm not the first one to suggest this idea)
4 Sean Corfield // May 8, 2009 at 11:29 PM
5 Sean Corfield // May 8, 2009 at 11:35 PM
component { ... }
should be core CFML, as should:
interface { ... }
So you would be able to write:
component extends="Base" implements="ICommand" { ... }
As for omitting the cfscript tags, we decided that is extended core, i.e., it's optional for vendors (to allow the tags to be omitted within a .cfc file), but if they support it, we are specifying how it should work - when those tags can be omitted and when they are still required.
6 Nathan Strutz // May 8, 2009 at 11:47 PM
Yes, I do like it. The ability to retain all my existing code, as well as the ability to be more specific. It sounds great. I can almost see cfscript becoming my dream language. Hard to say exactly what's missing, probably the same as all the other guys - closures, multiple inheritance, a better organized library, a more forgiving compiler, and on and on forever. For this, though, I like it.
Dan - I concur, but that would break some existing applications, and how could you specify output="sort of"? ;) Remember:
output=no/false = output is discarded once the method returns or completes
no output attribute = yes, but just plain text, use your own cfoutput tags if you have anything #dynamic#
output=yes/true = acts like your method has cfoutput tags wrapped around it.
7 Sean Corfield // May 9, 2009 at 10:42 AM
Also note my response to Dan: CFSCRIPT is already output="no" because you have to explicitly call writeOutput() to produce anything.
8 Russ // May 9, 2009 at 5:32 PM
Oh, and about function calls... will you be able to define arguments explicitly?
9 Ben Pate // May 9, 2009 at 7:47 PM
Thanks for expanding on this. From all the comments, it looks like there's a lot of interest in seeing CFSCRIPT bloom.
I totally agree with Nathan's "dream language" statement. I know CFSCRIPT has been a second-class citizen for a while, so I'm glad that the committee is moving forwards with things like this that make it an equal partner with markup. Thanks!
-- Ben
10 Sean Corfield // May 10, 2009 at 1:10 AM
@Ben, glad you like the changes the committee has approved.
11 David C-L // May 10, 2009 at 6:37 AM
12 marc esher // May 10, 2009 at 7:22 AM
thanks for the update, Sean.
13 Sean Corfield // May 10, 2009 at 9:46 AM
14 Sean Corfield // May 10, 2009 at 9:48 AM
15 Barney Boisvert // May 10, 2009 at 10:05 AM
In any case, if the tri-state behaviour carries through, it should be an explicit part of the spec that supplying a default to a 'required' argument is a syntax error (and if you ask me, CFARGUMENT should error on a default attribute if the required attribute is set to true as well).
16 Sean Corfield // May 10, 2009 at 10:30 AM
SomeType argName required="false"
optional SomeType argName
Given that the following makes an argument optional as well, neither of the above seemed like good choices:
SomeType argName = defaultValue
Also, given the amount of code out there today that does this:
<cfargument name="argName" type="SomeType" required="true" default="defaultValue" />
We did not want the script equivalent to be illegal:
required SomeType argName = defaultValue
(and we clearly could not make the cfargument format illegal due to backward compatibility)
Unfortunately, many of the past design decisions for CFML tie our hands to some extent since we cannot make arbitrary working code illegal and we have to consider consistency between new features and that existing code. I think most people know how I feel about 'private' access and the whole 'this' / 'variables' mess. There's a lot of things I'd change if we were designing CFML from scratch - but we're not.
17 Elliott // May 10, 2009 at 11:49 PM
required arguments are far more common than optional ones, so shouldn't the common case be less verbose?
If we look through the code in most frameworks the arguments are mostly required, not optional.
Now instead of getting an "Argument X is required for function Z" from most library code you'll probably get "Variabke X is undefined" or no error at all and have to go check the method signature, especially since stack traces don't have argument lists...
This really doesn't make sense to me.
function setX( string X ) {
variables.X = X;
}
This function does not do what most people expect it to do if called without arguments. It will NOT error, and will just reassign X to the original value already in the variables scope!
So now we need to add "required" to basically everything.
18 Sean Corfield // May 11, 2009 at 10:30 AM
As to the error you'd get from your setX() function, try it in tag syntax today - with <cfargument name="X" required="false"> - and that's what you should expect to get in the script version.
Also, bear in mind that in JavaScript, function arguments are all optional and JavaScript is considered one of the models for CFSCRIPT.
19 Henry Ho // May 11, 2009 at 11:07 AM
Save some typing. :)
20 Sean Corfield // May 11, 2009 at 11:25 AM
21 Elliott // May 11, 2009 at 12:32 PM
There would be no error from the setX() function, that was my point. ;)
While I still think this is a bad idea, fair enough with the argument about JavaScript. I suppose that makes sense.
22 Sean Corfield // May 11, 2009 at 12:51 PM
Variable X is undefined
on the assignment.
23 Elliott // May 11, 2009 at 6:02 PM
Did you actually read my post? ;P
<cfset variables.X = 1>
<cfset setX()>
There will be no error. Try it.
Re my statement: "It will NOT error, and will just reassign X to ***the original value already in the variables scope!***"
24 Sean Corfield // May 11, 2009 at 6:37 PM
Well, that's an advert for using ARGUMENTS.X instead I suppose (when you *do* get the expected errors) :)
I'm actually a bit surprised that the unadorned lookup of X doesn't find the declared-but-not-actually-present X in arguments scope (since structCount(arguments) and arrayLen(arguments) are both 1 and cfdump shows X is present in arguments scope but just null). An interesting side effect of yet another peculiarity of CFML variable lookup... :(
25 Barney Boisvert // May 11, 2009 at 10:33 PM
26 Sean Corfield // May 12, 2009 at 9:15 AM
Leave a Comment