between the lines
Sorry, seems I mixed you with Adam 
I agree that it is odd that you do in cfml
Query.column.row
And not
query.row.column
BUT (1) mostly I see in cml only
Query.column
Many people are not even aware that you can do
Query.column.row
BUT (2) why exactly is row.column the better choice? Because this is in
other languages the case where this has a techical backgrounds?
I’m not sure I understand you (sorry).
Here’s a specific question that might help focus on my concern:
for ( var row in myquery ) …
That works and implies myquery is a sequence of rows
nope it is not, a query is a collection of columns, when we implemented the
query object there was no support for the construct above a query objects
acts always as query.column.row
#query.firstname[1]# <!— outputs the first row of the column first name
—>
Lucee is using a warpper class to simulate your code example …
(and that each row is an associative structure whose keys are column
names). In other words, it behaves as if you could say
myquery[n][“colname”] - which you cannot, currently.
nope
https://bitbucket.org/lucee/lucee/src/e6ffd51e0eb0c16d730fc9bf9f6364df8bb63792/lucee-java/lucee-core/src/lucee/runtime/type/QueryImpl.java?at=master#cl-131
But we have myquery[“colname”][n] as the actual way you index into a query
object. That implies myquery is an associative structure (the keys are
column names) and each column is an array (indexed by numbers).
more or less yes, it is a little bit more complicated because CFML has a
lot of special behavior when it comes to queries, but this is an other
story… (working example:
#query.columnName.columnName.columnName.columnNam.# )
When you loop over an associative structure, you do:
for ( var key in mystruct ) …
So if myquery is really associative, you would expect:
for ( var colname in myquery ) …
Hence the inconsistency. It behaves like an array in one case but like a
struct in another.
i totally agree that there is a lot of inconsistency in that sector, even
worse is cfloop …
In particular, what should myquery.map( somefn ) do? Should it map over
the rows (and process each “struct”) or should it map over the columns (and
process each “array”)?
The underlaying implementation should not dicate the functionality, we can
change the unerlaying implemtnation that is not a big deal.
What matters is the user expierence, so what is the best way to handle 2
dimensonal data structures and this IN MY OPINION cfoutput/cfloop today
i myself use never a “for” loops at all in my cfml code, i prefer “loop”!
loop(query=myquery) {
echo(myQuery.firstname);
}
loop( array=arr index=“i” item=“v”){
}
…
nothing is simpler and faster than this!
What I’m proposing is to codify the behavior in terms of a well-understood
interface - and I’m suggesting an Indexable one, like an array - and then
add a method to obtain a named column as an array.
to be honest I (again my personal opinion) see that as a step backward!
That way it become clear exactly what for ( var thing in myquery ) …
should do. And by extension what myquery.map( somefn ) should do as well.
i never saw onces the question in the mailing list, that someone needs
explanation to use a query…
so i think we have not a big problem with that.
And you can still easily treat a query object as a collection of columns
(arrays of values) but you would need to be explicit about it by calling a
method:
myquery.getColumn( "colname" )
myquery.getColumnNames() // which already works I believe?
in what way is that better than simply do
myQuery.colname
myQuery.columnlist()
what is the most common task with queries, in all my cfml code i have only
a couple of rows where im really intrested in a certain line and then i
used mostly querySlice.
Remember that almost the only place you normally see myquery.colname is
inside a cfloop query= which is already a somewhat peculiar construct
(takes a query variable name, not value; manipulates currentrow “behind
the scenes”; treats the query name like a scope qualifier inside the loop).
If a loop tag continues in Lucee, I’d suggest something like this for a
query:
<lc:loop item="row" collection="#myquery#">
… #row.colname# ...
</lc:loop>
in my opinion we should retire “implcit query invocation” (what is a
setting in lucee), so you have always to write
#query.column# or #query.column[row]#
looping a query is btw extremly similar to looping a collection in java,
where you also have a internal pointer in the object, and you don’t have to
take care for a index (row), what is also the most common way to loop in
Java!
in the direct approach with for:
List list=getList();
for(String str:list){
System.out.println(str);
}
or more the classic way:
List list=getList();
while(it.hasNext()){
String str=it.hasNext();
System.out.println(str);
}
in both examle you don’t use a counter, of course we talk here about one
dimensonal structures,
but like i have writte before i see the something like this as equivalent
of queries in Java
class Address {
public final firstName;
…
public Address(String firstName,…) {this.firstName=firstName;…}
}
List addresses=getList();
for(Address address: addresses){
System.out.println(address.firstname);
}
what is nearly the same as
addresses=getList();
loop(query=addresses){
echo(addresses.firstname);
}
(just to emphasize that a consistently loop-over-the-rows approach is what
I’m looking for)
If this still hasn’t clarified things, I think I’ll give up… 
I’m sorry for that!
That i disagree does not mean i don’t get your point, i simply see the
focus on this different.
Different languages have different approch to do things and i simply see
the CFML approach in this case very good, better than other languages do!
that does not mean that other approaches are wrong, but rewrite everything
just to make it good in a other way seems to me a waste of time.
just my 2rp (2c)
MichaOn Mon, Feb 9, 2015 at 8:06 AM, Sean Corfield <@Sean_Corfield> wrote:
On Feb 8, 2015, at 10:43 PM, Michael Offner <@Michael_Offner> wrote:
Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)
–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/B4199D86-BE96-40AB-984C-23CF50BB67E9%40corfield.org
.
For more options, visit https://groups.google.com/d/optout.