Function argument order consistency

[Mark Jones]

Here's an issue that causes me some annoyance. Every time I use a
date function I have to look up its syntax, because it doesn't match
pretty much every other "datatype"-related function:

ArrayAppend( array, item )
StructFind( struct, key )
ListAppend( list, item, delimiter )
DateAdd( datepart, number, date )
DateDiff("datepart", "date1", "date2")

Why is "datepart" first in those two examples? Especially for
DateAdd, shouldn't the date be first?

[Baz]

I agree, I think that's the way they do it in most other langs, so it slipped in - I know its like that in SQL Server

[Marko Simic]

I am annoyed by arguments order, but not so much of its inconsistency
(+1), but because it sounds unnatural to me.
What I would say is: "Add this item here", never "Add here this item".
So arrayAppend(array,item) would have different arguments' order
arrayAppend(item, array)

But that is how it is and impossible to change because backward
compatibility.

Best Regards,
Marko Simic

[Sean Corfield]

Perhaps the solution moving forward would be to take a cue from other
languages that overload built-in operators on more types, e.g.,

a = [ 1, 2, 3, 4 ];
a += [ 5 ];
s = { a = 1, b = 2 };
s += { c = 3 };

and also:

b = a + [ 6 ];
t = s + { d = 4 };

Sean

[Sean Corfield]

BTW, lists are problematic because they are just strings - they don't
really exist as a separate data type in CFML - but you have a slew of
built-in functions to manipulate string 'as if' they were real lists.
However the list*() built-ins don't behave like the array/struct
modifiers because they return the new list (string) instead of
modifying it in place:

a = [ 1, 2, 3 ];
arrayAppend( a, 4 ); // updates a in place
l = "1,2,3";
l = listAppend( l, "4" ); // must assign back to l

Sean

[Matthew Woodward]

I also like the Groovy notation of things like:
a = [1,2,3,4]
a << 5

But the overloaded arithmetic operators are more common and work equally well.

On Tue, Mar 9, 2010 at 10:28 AM, Sean Corfield <seanco...@gmail.com> wrote:

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

--
Matthew Woodward
ma...@mattwoodward.com
http://blog.mattwoodward.com
identi.ca/Twitter: @mpwoodward

Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

[Marko Simic]

+1 for overloaded arithmetic operators.
Less typing, if nothing else.

On Mar 9, 7:35 pm, Matthew Woodward <m...@mattwoodward.com> wrote:
> I also like the Groovy notation of things like:
> a = [1,2,3,4]
> a << 5
>
> But the overloaded arithmetic operators are more common and work equally
> well.
>

> On Tue, Mar 9, 2010 at 10:28 AM, Sean Corfield <seancorfi...@gmail.com>wrote:
>
>
>
>
>
> > Perhaps the solution moving forward would be to take a cue from other
> > languages that overload built-in operators on more types, e.g.,
>
> > a = [ 1, 2, 3, 4 ];
> > a += [ 5 ];
> > s = { a = 1, b = 2 };
> > s += { c = 3 };
>
> > and also:
>
> > b = a + [ 6 ];
> > t = s + { d = 4 };
>
> > Sean
>

> > On Sun, Feb 28, 2010 at 2:17 AM, Marko Simic <marko.si...@gmail.com>

> > wrote:
> > > I am annoyed by arguments order, but not so much of its inconsistency
> > > (+1), but because it sounds unnatural to me.
> > > What I would say is: "Add this item here", never "Add here this item".
> > > So arrayAppend(array,item) would have different arguments' order
> > > arrayAppend(item, array)
>
> > > But that is how it is and impossible to change because backward
> > > compatibility.
>
> > --
> > CFML Conventional Wisdom
> >  http://groups.google.com/group/cfml-conventional-wisdom?hl=en?hl=en
>
> --
> Matthew Woodward

> m...@mattwoodward.comhttp://blog.mattwoodward.com