abort - function or keyword?

18 views
Skip to first unread message

Alan Williamson

unread,
Feb 16, 2010, 10:35:32 AM2/16/10
to CFML Conventional Wisdom
Consider this:

<cfscript>
abort;
</cfscript>

Personally that doesn't feel quite right to be a keyword - it would
feel better if it was a function.

Would people be instinctively putting in the (); to make it abort();
without realizing its a keyword?

The broader question of course is what conditions must be satisfied
before something comes part of the language keyword syntax instead of
merely a function.

Keen to hear peoples input on this.

Mark Drew

unread,
Feb 16, 2010, 10:43:24 AM2/16/10
to cfml-convent...@googlegroups.com
I totally agree with you, I spend all day doing

abort(); ... delete, delete, delete

There might be different ways to abort in the future... but how do you constitute it as a keyword rather than a function? I mean, I am guessing that something is a keyword until it takes some kind of parameter or returns something?

Please let me know if I am wrong?

MD

> --
> CFML Conventional Wisdom
> http://groups.google.com/group/cfml-conventional-wisdom?hl=en?hl=en

seancorfield

unread,
Feb 16, 2010, 12:10:29 PM2/16/10
to CFML Conventional Wisdom
On Feb 16, 7:35 am, Alan Williamson <a...@aw20.co.uk> wrote:
> Consider this:
>
> <cfscript>
> abort;
> </cfscript>
>
> Personally that doesn't feel quite right to be a keyword - it would
> feel better if it was a function.
>
> Would people be instinctively putting in the (); to make it abort();
> without realizing its a keyword?

FWIW, the CFML Advisory Committee originally selected this:

abort; // no params
abort("message"); // function call, since it takes a message

The same stands for exit; / exit("method");

Then, after further discussion, there was broad consensus that the
parentheses should be required in all cases.

Given the approach taken in some other modern languages targeting the
JVM, there is a good precedent for allowing optional parentheses for
the no-param case.

My personal preference for CFML would be to make "all" tags into
functions and therefore required () for the no-param case.

("all"... there are a couple of tags that work better as directives /
declarations: component, interface, function, param, import)

Sean

Jim Priest

unread,
Feb 16, 2010, 12:15:55 PM2/16/10
to cfml-convent...@googlegroups.com
On Tue, Feb 16, 2010 at 12:10 PM, seancorfield <seanco...@gmail.com> wrote:
> My personal preference for CFML would be to make "all" tags into
> functions and therefore required () for the no-param case.

Agree! If they are all consistently: function(); the less I have to
remember - the better. :)

--
Jim Priest - thecrumb.com
Triangle Area ColdFusion User Group - tacfug.org
Without deviation from the norm, progress is not possible. ~ Frank Zappa

Alan Williamson

unread,
Feb 16, 2010, 12:18:56 PM2/16/10
to CFML Conventional Wisdom
On Feb 16, 5:10 pm, seancorfield <seancorfi...@gmail.com> wrote:
> My personal preference for CFML would be to make "all" tags into
> functions and therefore required () for the no-param case.

I agree.

> ("all"... there are a couple of tags that work better as directives /
> declarations: component, interface, function, param, import)

agreed, although param is an interesting one, i would have put that in
the "all" broad category

param( type, name, default );

Although it does bring up a broader context, which is, is it wise to
make the whole CFML language accessible via CFSCRIPT?

If that happens, is CFML still CFML? The ML (Markup Language) kinda
disappears with no tags present.

Andy Wu

unread,
Feb 16, 2010, 12:19:00 PM2/16/10
to cfml-convent...@googlegroups.com
seancorfield wrote:
> My personal preference for CFML would be to make "all" tags into
> functions and therefore required () for the no-param case.
>
> ("all"... there are a couple of tags that work better as directives /
> declarations: component, interface, function, param, import)
>

I certainly favour that approach.

I'd love to know what the logic was behind Adobe's implementation. It
certainly doesn't seem obvious at least.

Andy

Glen dunlop

unread,
Feb 20, 2010, 9:35:19 PM2/20/10
to cfml-convent...@googlegroups.com
Which I am going to take was because of backward compatability.

The question I would have asked is why, cfdump and abort would have only being used as wrappers because it didn't exist in script in the first place.

So does that mean the near future, we are going to see abort as a function rather than a statement. Or is that wishful thinking?
Reply all
Reply to author
Forward
0 new messages