So what should a .lucee do better in all this cases.
- ditch cfoutput-query, it is useless
- lucee is already passing arrays by ref, so no need to change here
- ditch cfm based custom tags, we have support for component based custom tags
- ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)
- ditch all the bullshit the local scope does for backward compatibility.
- if we already on this topic, ditch the argument scope, we only need one local scope for functions.
- ditch the variables scope in components and make the this scope private by default.
- ditch application.cfm of course.
- ditch dot notation upper case
- scope cascading to strict
- .... And lot more
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/cd5a1157-ab2b-4c3e-8eb2-1ff169db4ff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I have a wishlist of my own, maybe things already in the pipeline?
- Do away with 1-based arrays. It's just plain annoying now.
- What about deprecating direct access to some scopes ( session, application, server, cluster ) in favor of access through a built-in facade that could ensure locking. If a straetgy of RAD is help the programmer by taking care of low level tasks that seems like a logical move.
- How about a templating system like Mustache that separates logic from display? It could be in an extension. Inline logic in cfm pages has always been a doubled-edged sword, and in part enabled the "toy" moniker ACF has carried for so long.
On Sunday, February 8, 2015 at 12:18:44 AM UTC-8, Andrew Penhorwood wrote:This is a continuation from the tread Outsider perspective which was getting long and fragmented.Here are some suggestions off-the-cuff from Micha (see the other tread for context).So what should a .lucee do better in all this cases.
- ditch cfoutput-query, it is useless
- lucee is already passing arrays by ref, so no need to change here
- ditch cfm based custom tags, we have support for component based custom tags
- ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)
- ditch all the bullshit the local scope does for backward compatibility.
- if we already on this topic, ditch the argument scope, we only need one local scope for functions.
- ditch the variables scope in components and make the this scope private by default.
- ditch application.cfm of course.
- ditch dot notation upper case
- scope cascading to strict
- .... And lot more
- Then the conversion centered around local vs var in cffunction? I am not attached to var or Local but I like fast and I like being able to put thing into the variables scope inside the CFComponent. What makes sense from a technical perspective? I also like the idea of doing away with the argument scope. There would just be a local scope or a function scope.
- I think most people want to see looping cfoutput go away. For me I have never used cfoutput group unless it was forced on me by the creator of the original code.
- Application.cfm & OnRequestEnd.cfm should be removed - Application.cfc makes more sense.
Andrew Penhorwood
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/08327f58-4752-4021-a760-046adad027b5%40googlegroups.com.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/9fa5a66e-7258-4d0f-8629-db67530238dd%40googlegroups.com.
Wow that is a lot to digest! I like the direction it is headed. The current forms of discussion "google groups & google docs" seems like a poor place for the conversation. Is it possible to add a section on to the bug tracking system for these discussions. That way each item can be commented on. Just throwing out ideas.
maybe we could use https://www.uservoice.com/ for this or something similar...
This is a continuation from the tread Outsider perspective which was getting long and fragmented.Here are some suggestions off-the-cuff from Micha (see the other tread for context).So what should a .lucee do better in all this cases.
- ditch cfoutput-query, it is useless
- ditch cfm based custom tags, we have support for component based custom tags
- ditch "var" ( I know people love var, I do it as well, but it makes now sense, the "local" scope is the one following the logic of the language)
- if we already on this topic, ditch the argument scope, we only need one local scope for functions.
- ditch the variables scope in components and make the this scope private by default.
- scope cascading to strict
- Do away with 1-based arrays. It's just plain annoying now.
- What about deprecating direct access to some scopes ( session, application, server, cluster ) in favor of access through a built-in facade that could ensure locking. If a straetgy of RAD is help the programmer by taking care of low level tasks that seems like a logical move.
- How about a templating system like Mustache that separates logic from display? It could be in an extension. Inline logic in cfm pages has always been a doubled-edged sword, and in part enabled the "toy" moniker ACF has carried for so long.
Ok here the document with the details (anonymised):
In my experience, tallying votes from everyone means that over time only old issues can ever rise to the top. Maybe that's good in that it reflects long-term desire from the community, but sometimes it seems like a hindrance.
Ditch queries. Use arrays of objects (which could be lightweight structs). Build some grouping mechanism into a for() loop, eg:
for (row in result; group on 'col'){
// each distinct col value
for {
// each row with same col value
}
}
Yup. New variables declared within a block are local to the block, unless otherwise specified.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKf9vjY0J8JBj2EiEeQ3t1WH5%2B%2Bu89A6XWaNNsfCMGJ-aw%40mail.gmail.com.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ab876513-735e-48a3-b2d8-60a10e4937ed%40googlegroups.com.
I life in a country with direct democracy, that means that the people are voting about everything, mostly with no deep background knowledge, what sometime brings the politics in real trouble, but mostly we end with very wise decisions on a long run.Micha
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c84b2097-593e-4feb-8b9e-7ea182b9f75a%40googlegroups.com.
On 8 February 2015 at 13:01, Robert Munn <robert...@gmail.com> wrote:
- Do away with 1-based arrays. It's just plain annoying now.
I am undecided on this. 1-based arrays make more sense in the C21st and in a high-level language than 0-based ones, which are a legacy of earlier times which for some reasons some (OK: most) languages cling onto, but for no good reason.
That said... perhaps make it so it doesn't matter. One generally shouldn't need to know the actual number that an array element is indexed by. If yer direct-accessing an array via index, it does kinda suggest that an array might not be the correct way of structuring the data.
Are you going to try to convince me that’s consistent?
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxcKgJKGPhQJ7cLvq0asERC_Urje3Ka2wg5nEuAX1cUmw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2CBEBF9C-7F87-4489-9F39-90A952D2001A%40aria-media.com.
Also bear in mind that the people who actually do get to decide these things are the association members (or a subset of them on the language advisory), not just us hoi polloi who Micha opens a vote for. And I think offering a voting mechanism kinda implies the majority vote will get their decision actioned, which won't be the case.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/C8F6AEB1-6472-4D56-910E-40A3639163DB%40gmail.com.
What bugs me most atm is how the admin should look like...
Micha
Am Sonntag, 8. Februar 2015 schrieb Andrew Penhorwood :
On Sunday, February 8, 2015 at 12:50:44 PM UTC-5, Micha wrote:--I life in a country with direct democracy, that means that the people are voting about everything, mostly with no deep background knowledge, what sometime brings the politics in real trouble, but mostly we end with very wise decisions on a long run.MichaMy suggestion to move it to a better communication platform was not about voting. Though I am not against voting. It is being able to see the discussion about a change / idea / etc all in one place without having to filter thought about of other stuff. For example: If we used the bug tracking system or something else. There would be the "changes to queries". Then that discussion would be open to anyone to give their opinion, idea ,etc but we it would be limited to just queries. Here in the groups it is hard to see what people are replying too.Andrew Penhorwood
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.
Question for people pushing for local scope, is it being suggested that we should also prefix all our variables like "local.foo" everywhere in actual code. Because I LOATHE that. Even your simple functions become noisy with cruft that totally hurts readability. It drives me nuts to see every variable prefixed with "local" or ","variables". I understand why people do it because CF can exhibit some weird or unseen scope creep/cascades not always expected.
Variable defined in a function should be local to only that function. Arguments included. I don't see a reason to have its own scope. If you're having name conflicts and need to separate them by scope, its probably poor design. My own code, I use the arguments scope just to force CF to look where it should be and not do any scope traveseral. But its annoying and just gets in the way of writing succinct code.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/bee38ea7-bbee-4327-a6e0-c504735d6e6e%40googlegroups.com.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/8C1B4EEE-8708-4937-B9F8-D849D4628CE0%40corfield.org.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6DC15FAA-42B3-45D8-8CA3-3E63522C3861%40corfield.org.
maybe we could use https://www.uservoice.com/ for this or something similar...MichaOn Sun, Feb 8, 2015 at 2:28 PM, Andrew Penhorwood <penho...@gmail.com> wrote:Wow that is a lot to digest! I like the direction it is headed. The current forms of discussion "google groups & google docs" seems like a poor place for the conversation. Is it possible to add a section on to the bug tracking system for these discussions. That way each item can be commented on. Just throwing out ideas.Andrew Penhorwood
On Sunday, February 8, 2015 at 8:11:00 AM UTC-5, Micha wrote:Ok here the document with the details (anonymised):
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/9fa5a66e-7258-4d0f-8629-db67530238dd%40googlegroups.com.
+1 for something like UserVoice.
Of course, just because something is voted up the most or talked about the most does *not* mean that it should automatically be implemented; the need for a steering committee or editorial steer is still essential.
However, things like uservoice are a really easy way in to contribution for those who aren't brave enough to face the wrath of a vocal few on mailing lists, and for those who aren't sure that they should pester the core team by raising an issue in a tracker.
--
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKc41s_jbOFSqrS7iTfKgk9rp4VoQTC2460EnWqgOUE6sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
|
|
CONFIDENTIAL 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 |
On Feb 8, 2015, at 10:43 PM, Michael Offner <mic...@lucee.org> wrote:
> 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
(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.
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).
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.
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")?
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.
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.
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?
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>
(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… :(
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B4199D86-BE96-40AB-984C-23CF50BB67E9%40corfield.org.