It’s always best to be informed before putting one’s oar in, I find. Still:
I know I am an outlier in that regard.
Still a stupid idea.
No. Dogmatically going “it’s just a string”, and being in denial that CFML
has a concept that is a string-based collection is what’s stupid.On Tuesday, 2 June 2015 08:46:47 UTC+1, Mark Drew wrote:
It was just not very performant. I have seen code that had 100’s of
ListGetAt all over the place in one template hence my negative
attitude to use lists as a collection.
As I said before, I wouldn’t use it and if Lucee converts it to a nice
array under the covers for you, then great. Go for it.
Mark Drew
Sent by typing with my thumbs.
On 2 Jun 2015, at 08:48, Jean Moniatte <@Jean_Moniatte mailto:Jean_Moniatte> wrote:
On Tue, Jun 2, 2015 at 9:46 AM, Mark Drew <@Mark_Drew mailto:Mark_Drew> wrote:
I hasten to add that my “support” (which was more just an acknowlegdment
than any sort of advocacy) of this feature in no way ought to suggest I
actually think anyone should ever be using strings in this way. On the
contrary: ppl should be shot for doing so in most situations I see lists
being used.
However this has nothing to do with the language properly supporting a
concept it’s decided to implement.On Tuesday, 2 June 2015 08:49:19 UTC+1, Mark Drew wrote:
–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom
T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB
I personally agree with you, but the driving force behind fixing this
issue was ACF compatibility.
if anything, I would prefer
for (ch in someString) { /* ... to iterate over the characters of the
string … */ }
but then compatibility would completely break…
I’ve been mulling over a sensible syntactical tweak to disambiguate between
“by list element” and “by char”, but drew a blank.
However it’s perhaps better to join the current decade and take an OO & FP
approach to these things, by implementing String.each(), .reduce(), .map(),
.sort(), .filter(), etc
It makes for more clear code to use purpose-specific iteration methods,
rather than generic and procedural looping statements.On Tuesday, 2 June 2015 15:09:47 UTC+1, Igal wrote:
Adding my vote that this should be made to work in Lucee, or at least
document as deviating from Adobe CF. If your gonna claim that you are Adobe
CF compatible, then don’t complain when someone brings up an
incompatibility. Even if you think its a stupid idea.On Monday, June 1, 2015 at 11:28:48 PM UTC-5, Paul Kukiel wrote:
Code review was a freebie :-POn Tuesday, 2 June 2015, Paul Kukiel <@Paul_Kukiel> wrote:
Oh boy what have I done!
Lists have always been a part of cfml, can’t change that, I would think
that it you can cf loop list then for in would also just work.
Yes listToArray was used but it was one extra line if code to type in big
deal.
I simply asked if it should work not weather my code is shit.
On Jun 2, 2015 7:09 PM, “Adam Cameron” <@Adam_Cameron <javascript:_e(%7B%7D,‘cvml’,‘@Adam_Cameron’);>> wrote:
On Tuesday, 2 June 2015 09:54:20 UTC+1, Desmond Miles wrote:
If it is intended be a shorcut for converting string list to an array
then it must add a “delimiter” parameter.
Good point, the solution for this has not been implemented properly, as
the delimiter has been hard-coded (as a comma):
Because it is practical and avoids converting the string to an array.
Indeed. Whilst CFML makes a claim that there is such a thing as a list
(which is string with element delimiters in it: we get that), then it
stands to reason that all the usual collection-iteration possibilities are
availed to it.
In for a penny, in for a pound. Even if they penny is misshapen and not
accepted as legal tender anywhere else.
That said: hands up who’d like to list support in .lucee entirely? [raises
hand. Raises other hand too].On Tuesday, 2 June 2015 08:31:39 UTC+1, jmoniatte wrote:
On Tue, Jun 2, 2015 at 9:11 AM, Mark Drew <mark...@gmail.com <javascript:> wrote:
for (ch in someString) { /* ... to iterate over the characters of the
string … */ }
I’ve been mulling over a sensible syntactical tweak to disambiguate
between “by list element” and “by char”, but drew a blank.
As soon as I pressed send, I got it.
You’re stuck with the default syntax being used for looping over a
comma-delimited list. However - if the solution had been implemented
thoroughly - you could use a null delimiter to iterate by character, eg:
for (element in list[; delimiter[; multi-char]]);
EG:
for (char in “abc”;null){ // or “” should work too
echo char; //abc
}
It’s not as good as not needing to specifiy nothing (as it were), but as
you say, Adobe’s kinda stitched everyone up there.
And iteration methods are just better anyhow, so you’ve still got your best
option available to you, and you can lead the way with CFML quite happily
as CF doesn’t have anything in that space already.
Thoughts? More something for the language forum perhaps? It needs a bit of
love, after all…On Tuesday, 2 June 2015 17:16:18 UTC+1, Adam Cameron wrote:
On Tuesday, 2 June 2015 15:09:47 UTC+1, Igal wrote:
A native string.split( regex ) would be great too; avoiding the ‘list’
baggage and implementing more flexible splitting using regex rather than a
list of single character delimiters.On 2 June 2015 at 17:16, Adam Cameron <@Adam_Cameron> wrote:
On Tuesday, 2 June 2015 15:09:47 UTC+1, Igal wrote:
I personally agree with you, but the driving force behind fixing this
issue was ACF compatibility.
if anything, I would prefer
for (ch in someString) { /* ... to iterate over the characters of the
string … */ }
but then compatibility would completely break…
I’ve been mulling over a sensible syntactical tweak to disambiguate
between “by list element” and “by char”, but drew a blank.
However it’s perhaps better to join the current decade and take an OO & FP
approach to these things, by implementing String.each(), .reduce(), .map(),
.sort(), .filter(), etc
It makes for more clear code to use purpose-specific iteration methods,
rather than generic and procedural looping statements.
–
Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom
T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB
I would be against that for the same reason that you cannot specify the
“step” (eg, every other element) in a for…in array loop.
That doesn’t quite follow. step is never a feature of for…in loops of
any description, because a for…in loop is specifically for iterating over
all elements of the collection.
Correct, it is the simplest array loop that follows the most common use
case for looping over arrays. You also cannot specify direction or an
index.
The delimiter and multi-char parameters here are necessary to correctly
support lists that a) don’t use a hard-coded comma delimiter; b) have
multi-char delimiters. These are the opposite of the step concept: they are
required to facilitate looping over all list elements, not to omit them.
However you’re in good company (after a fashion)… the Adobe engineers
made exactly the same misreading of the situation.
It does follow if you expect for…in loops to be simple and representing
the defaults. The default for a cfloop over a list is that the list be a
simple comma-delimited list. Any other needs are addressed with different
(arguably better) constructs, of which there are at least 4.
On the other hand I completely agree that using lists as a “thing” should
be frowned up. However I believe that if one is going to support lists,
then one should do the job thoroughly. Which has not been done here.
Maybe not for this particular construct. However they are already
thoroughly supported with other constructs.
This is Adobe’s deal. Let them “fix” (preferably drop) it. If they
implement something along the lines of what you suggest, then by all means
implement that.
Again, I hope all of this doesn’t apply to the lucee dialect. I wouldn’t
mind for…in string. I would, however, expect it to follow the more
logical assumption of treating the string as a character array.
I would be against that for the same reason that you cannot specify the
“step” (eg, every other element) in a for…in array loop.
That doesn’t quite follow. step is never a feature of for…in loops of any
description, because a for…in loop is specifically for iterating over all elements
of the collection. The delimiter and multi-char parameters here are
necessary to correctly support lists that a) don’t use a hard-coded comma
delimiter; b) have multi-char delimiters. These are the opposite of the
step concept: they are required to facilitate looping over all list
elements, not to omit them. However you’re in good company (after a
fashion)… the Adobe engineers made exactly the same misreading of the
situation.
On the other hand I completely agree that using lists as a “thing” should
be frowned up. However I believe that if one is going to support lists,
then one should do the job thoroughly. Which has not been done here.On Tuesday, 2 June 2015 22:22:36 UTC+1, Jesse Shaffer wrote:
That doesn’t quite follow. step is never a feature of for…in loops of
any description, because a for…in loop is specifically for iterating over
all elements of the collection.
Correct, it is the simplest array loop that follows the most common use
case for looping over arrays. You also cannot specify direction or an
index.
The delimiter and multi-char parameters here are necessary to correctly
support lists that a) don’t use a hard-coded comma delimiter; b) have
multi-char delimiters. These are the opposite of the step concept: they are
required to facilitate looping over all list elements, not to omit them.
However you’re in good company (after a fashion)… the Adobe engineers
made exactly the same misreading of the situation.
It does follow if you expect for…in loops to be simple and representing
the defaults. The default for a cfloop over a list is that the list be a
simple comma-delimited list. Any other needs are addressed with different
(arguably better) constructs, of which there are at least 4.
We can agree to disagree. I think your analysis is a bit of a retcon sort
of thing, but hey. I don’t really care. One way or the other.
Again, I hope all of this doesn’t apply to the lucee dialect. I wouldn’t
mind for…in string. I would, however, expect it to follow the more
logical assumption of treating the string as a character array.
But we agree with each other on this one, yes.
Is there a ticket for this? Or perhaps a discussion on the language forum?On Wednesday, 3 June 2015 14:51:57 UTC+1, Jesse Shaffer wrote:
