I opened up some (client) code this evening and saw something like this:

I looked at this and went *blink, blink*... That can't be right! You can't use colons for named arguments!

Er, can you?

Well, apparently you can. Incredulous, I went and wrote some test cases. You can even mix styles in a single call:

I always say you should learn something new every day so I figured I'd share today's lesson for me!

I prefer the : syntax.

I had a teacher that said "nobody knows *everything* about any one topic", while some of us try, this is proof that my teacher was right!

Neat!

Does that work on Railo or BD?

I think it dates back to original Flash Remoting. Flash did named arguments with colons. It's how I first learned to do named args in CFMX.

I actually showed you this back in '02 when I came and did a Flash Remoting preso to BACFUG. At that time you had the same reaction as now. But since it's not really considered 'the way', just 'a way', it's quickly forgotten. I'll look forward to this post from you again in 5 years or so :P

But this really is one of those things that you just can't believe no matter how many times it comes up...

just tested it with a small UDF on Railo 2.0... works perfectly.

I just wish Adobe would hurry up and fix the old problem of not being able to use named parameters when a function is inside a structure (or even just called be variables.foo(name = 'dave')).

Great tip though :)

The error it gives involves named arguments.

Personally, I don't like that because it confuses argument syntax with structure syntax and causes language problems like this.

Mike.

@Mike: That's not because of the syntax - it's because CF8 doesn't support nesting inline structures. (Railo supports nested inline structs and thus allows inline structs as function arguments.)

Not quite. Nothing prevents the parser from accepting argument syntax like this and parsing inline structures. Structures are delimited by the { and } so there's no ambiguity in the parsing context. I'm pretty sure Railo allows it anyway.

func({foo="bar","baz"={"bam"={"bar"=1}}})

Speaking of which, what's up with not being able to pass named arguments to a function in a structure?

These issues definitely seem to relate to issues with the CF parser design, not with the grammar of the language.

Bring CFScript to the forefront and lets be done with tags.

I think you're looking at this wrong. CF isn't "non-well formed XML," despite the fact that people like to add /> to the end of a lot of tags these days, there's huge gaps in the allowed syntax for CF compared to XML.

CF is neither a superset or a subset of XML, and considering that CF has been around longer than XML I'd hardly relate it that way.

Don't let those angle brackets fool you, saying CF is like malformed XML is like saying JavaScript is malformed Java. It's an entirely different language.

From what I can tell (by observation, not inspection), I'd say that what happened with CF8 is that the literal struct and array syntax was added to the assignment part of the grammar instead of the expression portion.

Such that:

Assignment := ((Identifier|QuotedString) =)? (Expression|LiteralStruct|LiteralArray)

The problem of course with this is that that you can't use the literal notation where an expression is expected, such as in a function call, an attribute to a tag, or all the other useful places outside a cfset and cfscript assignment.

If they had instead extended the parser to allow those anywhere an expression is expected (like in JavaScript), we could be using them in those contexts. I'm reasonably sure Railo's parsing is setup this way.

Now, how complicated that would have been to implement this way, I'm not sure, but considering that in an expression context, no other valid token can start with { or [ I'm not sure where the ambiguity was. Sounds more like they just didn't bother, or budgeted time for implementing other things.