Implicit Structures and Arrays

[WebFlint]

I never found these features to be usable, it was one of those
features that got me really excited with CF only to swear them off
when I actually tried to use them.

I want to test these and document the issues that CF has with them.

Here is one I just ran into on Adobe CF, it works in Railo, and OpenBD
does support the syntax at all.

<!--- Operators as keys = fail -->
<cfset test = { eq ="equals" } />

I believe there are also key case issues, where all the keys are
forced uppercase, and issues passing implicitly created arrays and
structures into functions inline.

For that second issue I work around it by having a st() function
available to simulate {} inline:

<cffunction name="st" access="public" returntype="struct">

<cfset var local = StructNew() />

<cfset StructAppend ( local, Arguments ) />

<cfreturn local />

</cffunction>

The purpose of the StructAppend is to force the arguments to the
struct datatype. Arguments in at least ColdFusion isn't the same java
class as a structure (I have to test this on Railo and Open BD
though), so if you are unit testing you'll run into issues.

Anyone have other problems with these they remember off hand?

.brett

Also, I'm not sure if this is part of the core CFML as defined by the
Advisory Committee (wiki only seems to list functions and tags). I
hope it gets added though, and supported by OpenBD which is another
driving factor in getting the current supported functionality
documented.

[Sean Corfield]

On Mon, Apr 27, 2009 at 3:42 PM, WebFlint <webf...@gmail.com> wrote:
> Here is one I just ran into on Adobe CF, it works in Railo, and OpenBD
> does support the syntax at all.
>
> <!--- Operators as keys = fail -->
> <cfset test = { eq ="equals" } />

You can use strings for keys (on Railo) to avoid that problem and I
believe Adobe are in favor of that change too:

<cfset test = { 'eq' = "equals" } />

This also addresses the key case issues.

> Also,  I'm not sure if this is part of the core CFML as defined by the
> Advisory Committee (wiki only seems to list functions and tags).

We're defining CFSCRIPT right now and struct/array literals will be
part of core syntax.
--
Sean A Corfield -- (904) 302-SEAN
CTO, Railo US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[WebFlint]

Good to hear Sean. I can't wait to hear what comes out of this.

Any chance we are getting implicit JSON compatibility? It would be
cool if we could serialize JSON directly into native CF types without
having to go through the JSON functions.

Hopefully this one is on the agenda too (this was just on my mind) -
one things that really bugs me about CFSCRIPT is the inconsistent
argument order across functions.

for instance,

REFind(reg_expression, string [, start, returnsubexpressions ] )

vs

REReplace(string, reg_expression, substring [, scope ])

I constantly have to look up function references because I never
remember the order....

Realizing that current functions won't be changing it would be cool if
there was a convention for the order of arguments for all future new
functions.

cheers,

.brett


On Apr 28, 1:21 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> On Mon, Apr 27, 2009 at 3:42 PM, WebFlint <webfl...@gmail.com> wrote:
> > Here is one I just ran into on Adobe CF, it works in Railo, and OpenBD
> > does support the syntax at all.
>
> > <!--- Operators as keys = fail -->
> > <cfset test = { eq ="equals" } />
>
> You can use strings for keys (on Railo) to avoid that problem and I
> believe Adobe are in favor of that change too:
>
> <cfset test = { 'eq' = "equals" } />
>
> This also addresses the key case issues.
>
> > Also,  I'm not sure if this is part of the core CFML as defined by the
> > Advisory Committee (wiki only seems to list functions and tags).
>
> We're defining CFSCRIPT right now and struct/array literals will be
> part of core syntax.
> --
> Sean A Corfield -- (904) 302-SEAN

> CTO, Railo US --http://getrailo.com/
> An Architect's View --http://corfield.org/

[Sean Corfield]

On Tue, Apr 28, 2009 at 2:12 PM, WebFlint <webf...@gmail.com> wrote:
> Any chance we are getting implicit JSON compatibility?  It would be
> cool if we could serialize JSON directly into native CF types without
> having to go through the JSON functions.

You mean like the returnformat= attribute on <cffunction> in Adobe
ColdFusion? The committee haven't voted on that yet so I don't know
whether it will be considered core or not.

> Realizing that current functions won't be changing it would be cool if
> there was a convention for the order of arguments for all future new
> functions.

Post-CFML2009, the committee will work on guidelines for vendors that
will (try to) address this sort of thing.

--
Sean A Corfield -- (904) 302-SEAN

CTO, Railo US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

[WebFlint]

> You mean like the returnformat= attribute on <cffunction> in Adobe
> ColdFusion? The committee haven't voted on that yet so I don't know
> whether it will be considered core or not.

Nope, but that would be good too. What I meant is using the JSON
format to implicitly create ColdFusion variables without having to go
through the JSON functions. i.e.

myStruct = { "name":"brett","city":"new york", "cfml":
["Railo","ColdFusion","OpenBD"] };

works in Railo, fails in openBD, ColdFusion.

JSON is widely popular and I don't see another reason to use another
syntax for CFSCRIPT. I guess I don't understand why CF didn't do this
from the beginning and gave us the half backed functionality we
currently have.

.brett

On Apr 29, 7:02 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> On Tue, Apr 28, 2009 at 2:12 PM, WebFlint <webfl...@gmail.com> wrote:
> > Any chance we are getting implicit JSON compatibility?  It would be
> > cool if we could serialize JSON directly into native CF types without
> > having to go through the JSON functions.
>
> You mean like the returnformat= attribute on <cffunction> in Adobe
> ColdFusion? The committee haven't voted on that yet so I don't know
> whether it will be considered core or not.
>
> > Realizing that current functions won't be changing it would be cool if
> > there was a convention for the order of arguments for all future new
> > functions.
>
> Post-CFML2009, the committee will work on guidelines for vendors that
> will (try to) address this sort of thing.
> --
> Sean A Corfield -- (904) 302-SEAN

> CTO, Railo US --http://getrailo.com/
> An Architect's View --http://corfield.org/