lucee vs legacy CFML

[Andrew Penhorwood]

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

[Michael Offner]

To be honest we did already a lot of talking behind the scene a while back about exact this topic, the idea of the .lucee extension is new but doing a clean version not. We had a group of people participating in the process to define what means "clean".

The result of this talks was a detailed list, I will publish that list asap.

So you get a lot more details...

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/cd5a1157-ab2b-4c3e-8eb2-1ff169db4ff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Munn]

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.

[Michael Offner]

see my comments between the lines

Micha

On Sun, Feb 8, 2015 at 2:01 PM, Robert Munn <robert...@gmail.com> wrote:

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.

in my opinon 0 based array only exists because historically it has make sense, but handling 1 based array is simpler in the end.

if we go to 0 based all strin function need to be 0 based as well, query rows?...

 

- 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.

Lucee is using concurrent maps for all struct and scopes...

 

- 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.

no opinion on that atm

 

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.

[Michael Offner]

Ok here the document with the details (anonymised):

https://docs.google.com/spreadsheet/pub?key=0AjP06HZksE60dDRVdEJPSWZYZzhVRXkyYkYtYTNOSGc&gid=4

Micha

On Sun, Feb 8, 2015 at 2:01 PM, Robert Munn <robert...@gmail.com> wrote:

[Andrew Penhorwood]

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

[Michael Offner]

maybe we could use https://www.uservoice.com/ for this or something similar...

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/9fa5a66e-7258-4d0f-8629-db67530238dd%40googlegroups.com.

[Dave Merrill]

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.

Dave

[Adam Cameron]

On 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.

Each element should be raised as a feature request, with a category (not that I see the option for "categories" in Bitbucket?) of "lucee language" or something.

 

On 8 February 2015 at 13:42, Michael Offner <mic...@lucee.org> wrote:

maybe we could use https://www.uservoice.com/ for this or something similar...

I recommend, just use the bug tracker. You don't need yet another system for people to keep track of.

-- 

Adam

[Adam Cameron]

On 8 February 2015 at 08:18, Andrew Penhorwood <penho...@gmail.com> 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

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

    }

}

 

- ditch cfm based custom tags, we have support for  component based custom tags

Agreed. Although I think I know of one thing the CFC-based ones don't seem to support that the tag-based ones do, however I need to do some more research on that before raising it.

 

- 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)

Yup. New variables declared within a block are local to the block, unless otherwise specified.

- if we already on this topic, ditch the argument scope, we only need one local scope for functions.

Disagree here. It's handy to have a collection of all arguments, and that might as well be the current arguments scope. People just need to stop bloody actively scoping their arguments. It's pointless.

 

- ditch the variables scope in components and make the this scope  private by default.

Yup. Classes (and they should be classes, not components) should be able to have public properties, that said. But this is implemented by declaring a property as public.

 

- scope cascading to strict

If that means "do not do any scope cascading" then yes.

 

[everything I omitted I either agree with or don't care about]

-- 

Adam

[Adam Cameron]

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.

On the other hand, people do seem to not get that, so it might be the path of least possible resistance to just bite the bullet anyhow. Easier to change the language than to educate ppl.

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.

Lucee could do itself a favour by erring away from using generic indexed loops for the recommended way to access an array; instead use array-specific constructs like .each() / .map() / etc as appropriate.

- 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.

I thought about that this morning. But not for the locking reasons, as that's already dealt with anyhow.

I think the scoping approach is fine, especially if one thinks about them as objects with implicit getter/setters, rather than a struct. Basically the session scope already is the facade you're wanting.

 

- 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.

I'm now swinging away from this again. I think perhaps the language should not care about things like what makes best MVC practices, so having a different view syntax baked in is perhaps not right.

Other platforms (I cited PHP and Twig before) don't have the templating syntax baked in the language do they? They just also happen to have templating engines that ppl tend to use in MVC situations? So maybe a separate project?

But seen in that light, I'd drop all tags from Lucee's language. And perhaps the Association can lead a Lucee-friendly templating project too?

Again, can we pls remember that no-ones suggesting any changes to Lucee's CFML support. This is talking about something completely different.

-- 

Adam

[Adam Cameron]

On 8 February 2015 at 13:10, Michael Offner <mic...@lucee.org> wrote:

Ok here the document with the details (anonymised):

https://docs.google.com/spreadsheet/pub?key=0AjP06HZksE60dDRVdEJPSWZYZzhVRXkyYkYtYTNOSGc&gid=4

I have it on good authority that at least one of the columns there does not represent the opinions of the person concerned any more. Their opinions have moved on since that doc was created.

-- 

Adam

 

[Adam Cameron]

On 8 February 2015 at 13:55, Dave Merrill <enig...@gmail.com> wrote:

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.

Simple vote-only doesn't do any topic any justice. A lot of people with very uninformed opinions will be afforded the same weight as people who have participated in a discussion on the topic, and have had the chance to have different perspectives aired.

At the very least the conversation needs to be made on any given topic first, then ppl who have participated in the conversation (if only in a read-only capacity) might then vote on some options.

-- 

Adam

[Ryan Guill]

This is why I am advocating a formal proposal process (see the relevant parts of  https://groups.google.com/d/msg/lucee/huvpGM0K75Y/ma9F2Jn_cBQJ and https://groups.google.com/d/msg/lucee/huvpGM0K75Y/_uspQj_CKtwJ)

Maybe we use separate repos under the lucee account in bitbucket for these proposals? the readme.md of the repo could be the current state of the proposal, any relevant code examples could be included, and ideas and concerns about the proposal could be raised as issues against it.  Similar to this proposal from JS: https://github.com/tc39/Array.prototype.includes/ The hard part might be how to get the proposal repos created in the first place, but maybe someone from the community could be given access to coordinate that.

Not perfect but an idea.

[Ryan Guill]

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
    }
}

What is the benefit in ditching queries? It seems like the perfect abstraction for a recordset.  If you want to work with them as arrays of structs, why not provide an easy way to convert from one to the other? Or even have that as an option when running the query, to return a recordset or an array of structs.  I'm just not following what the downsides of the recordset are and what the benefits of an array of objects are.

Yup. New variables declared within a block are local to the block, unless otherwise specified.

I personally like scopes, especially the local scope, as a way to group variables together.  It's one of the things I miss from CFML when writing just about any other language.  It is super conventient to be able to writedump(local); when debugging.  Its also super conventient to be able to call other functions with argumentCollection=arguments. That said, there are plenty of things about the way some scopes are currently implemented that could be improved, including their names.  Also the variables scope in components.

[Michael Offner]

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/CAFwR%2BKf9vjY0J8JBj2EiEeQ3t1WH5%2B%2Bu89A6XWaNNsfCMGJ-aw%40mail.gmail.com.

[Michael Offner]

I completely agree with queries, i Love them and I see no reason to give them away.

If you need the argument scope separated, simply do

 local.args=duplicate(local);

At the begin of the function.

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/ab876513-735e-48a3-b2d8-60a10e4937ed%40googlegroups.com.

[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. 

Micha

My 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 

[Michael Offner]

What bugs me most atm is how the admin should look like...

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.

[Sean Corfield]

On Feb 8, 2015, at 8:41 AM, Ryan Guill <ryan...@gmail.com> wrote:
> What is the benefit in ditching queries? It seems like the perfect abstraction for a recordset. If you want to work with them as arrays of structs, why not provide an easy way to convert from one to the other?

I think people are missing the point here. The issue is consistency: queries are _almost_ like arrays of structs except when they’re not. This is intuitive:

for ( var row in myquery ) { … row.col … }

but this is not:

for ( var i = 1; i <= myquery.recordcount; ++i ) { … myquery.col[i] … }

If iterating over the query gives you rows in the first case, why isn’t it query[i].col in the second case? And then look at the original loop over a query:

<cfloop query="myquery"> <!— why not "#query#" here? —>
… #myquery.col# … <!— behaves like row.col in first piece of code —>
</cfloop>

Are you going to try to convince me that’s consistent?

> I personally like scopes, especially the local scope, as a way to group variables together. It's one of the things I miss from CFML when writing just about any other language. It is super conventient to be able to writedump(local); when debugging.

Having crappy debugging tools available to us isn’t a good argument for perpetuating a weird feature - named scopes - that other languages have very sensibly chosen not to provide. The fact that "just about any other language" doesn’t have this feature should make you question _why_, not bemoan that other languages don’t have this strange unique-to-CFML feature.

Most other languages out there were _designed_. CFML was not. If CFML alone has a particular feature, it probably flies in the face of good language design.

Which is also why a simple vote on language features from a population largely void of any language design skills has to potential to produce weird results… If all your first / primary language is CFML and you don’t have much experience of other languages in large production systems, you’re probably going to vote for CFML features that other languages have made conscious designs to avoid.

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)

[Sean Corfield]

On Feb 8, 2015, at 6:30 AM, Adam Cameron <dac...@gmail.com> wrote:

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.

Adam’s right here. And there _are_ modern languages that have chosen to break with this weird artifact of historical language design and use the far more intuitive "1 is the index of the 1st item" approach - which is what we use in "real life".

Wikipedia makes this observation:

"Referencing memory by an address and an offset is represented directly in computer hardware on virtually all computer architectures, so this design detail in C makes compilation easier, at the cost of some human factors. In this context using "zeroth" as an ordinal is not strictly correct, but professional shorthand. Other programming languages, such as Fortran or COBOL have array subscripts starting with one, because they were meant as high-level programming languages, and as such they had to have a correspondence to the usual ordinal numbers. Some recent languages, such as Lua, have adopted the same convention for the same reason."

(my emphasis)

Julia too (first appeared in 2012). And XPath. Fairly full list here:

http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Array_system_cross-reference_list

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.

Agreed. With for .. in loops and .each() / .map() / etc, there’s often very few times where the index is really needed (and having it passed as an optional argument to the function argument of .each() / .map() / etc is a good way to handle that when it is needed).

[Andrew Penhorwood]

+1111111

I totally agree with this and Sean's post about language design.  I started programming in 1980 so I have used numerous languages over the last 35 years.  Using 0 based arrays is just silly.  It was done because of lazy programmers.  I was a math person before I was a programmer.  No one counts 0,1,2,3... 

The query special cases are also silly along with <cfloop item="key" collection="#struct#".  Why change from index to item?  Why does <cfloop index="key" array="myarray">  put the next array item into key?   On collection I have to do struct[key].  These things make CF look like a silly language and show poor design by the people at Macromedia, Adobe, etc.  Overall I like CF, it has great parts too like, cfquery plus regular SQL, cfhttp, etc.  So now is the time to remove warts and fix items that slow down processing.  I want my code to look good and to run fast.

Andrew Penhorwood

[Dan Kraus]

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.

[Andrew Penhorwood]

+1.  I should only have to scope a variable that is outside of the function.  variables.myvar type of stuff.   I could go either way on block level or function level scoping.  There will always be a "scope" to a variable but I should not have to keep tabs on it.

Andrew Penhorwood

[Ryan Guill]

Are you going to try to convince me that’s consistent? 

No, I won't try to convince you of that, but I wasn't arguing anything was consistent.  But you can treat queries like an array of structs if thats what you'd like to do, you don't have to use the inconsistent syntax. But if the api of the recordset needs tweaks, lets do that. 

Recordset objects have their benefits though right? Query of queries, enforcing that there are always the same number and order of columns in the structures - I would also expect that they are / could be optimized for the use cases that recordsets are generally used for.

> Having crappy debugging tools available to us isn't a good argument for perpetuating a weird feature - named scopes - that other languages have very sensibly chosen not to provide. The fact that "just about any other language" doesn’t have this feature should make you question _why_, not bemoan that other languages don’t have this strange unique-to-CFML feature. 

Wheres the part that explains why this weird named scope feature is a bad idea? Just because CFML is the only one to have it, ergo it must be bad? I have written a non-trivial amount of code in quite a few other languages (although admittedly, likely not as much as you) and I fail to see why having scopes that group variables and define their lifetimes and purpose are a bad thing. I'm sure you have some good reasons, but you didn't share them.  What I find is that in other languages, the frameworks or the developers themselves come up with their own 'scopes' using objects or namespaces to try to solve the same problems.

> Which is also why a simple vote on language features from a population largely void of any language design skills has to potential to produce weird results… If all your first / primary language is CFML and you don’t have much experience of other languages in large production systems, you’re probably going to vote for CFML features that other languages have made conscious designs to avoid. 

This I agree with - discourse, pointing out the merits and demerits of features is necessary for an informed descision - although I don't think the derision of CFML'ers is.  We all know there are people who write CFML as a primary language and don't have the experience of other languages to know if something is a good idea or not - but surely we can educate why something is good or bad instead of hand waving and saying we wouldn't understand why our opinions are wrong.

[Nando Breiter]

Micha,  

I live in the same country. Direct democracy is indeed impressive, but thankfully, people here are smart enough to not bring forth referendums on how to design their bridges, for instance, voting on each concrete pillar, steel beam, and rivet! They just argue about whether they want to pay for them, or not. 

Your sentiment is noble, but I'm concerned that opening up the decision process too widely will simply create a mess. It already begins to feel like a free for all. Meritocracy is another model that might be more appropriate in our case. Invite comments freely from the community on feature proposals, but only those with sufficient experience with various languages should make the final design decisions - like how we do it when designing bridges, airplanes, buildings, etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxcKgJKGPhQJ7cLvq0asERC_Urje3Ka2wg5nEuAX1cUmw%40mail.gmail.com.

[Andrew Dixon]

Agree with Nando, someone, probably Micha and Igal, need to write up a draft RFC / spec for the Lucee language design and let people like Adam, Sean, Kai, etc.., etc.. comment on the RFC within a given timeframe, then revise based on the comments and then release a final specification and build from there. Too many cooks and all that. While what the community thinks is *very* important it still needs to be led from the front.

Kind regards,

Andrew

http://about.me/andrew_dixon

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2CBEBF9C-7F87-4489-9F39-90A952D2001A%40aria-media.com.

[Adam Cameron]

Thanks for pointing that out, Nando.

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.

I sure as hell hope that when this community here comes up with stupid ideas (and I've seen plenty in the past, and some made it into Railo), then the language advisory group in the association just go "actually no. Not happening".

We don't want PHP, and that's what you'll get if you try to listen to everyone. Simply put: not everyone's opinion should be given equal weight. Unlike, perhaps, in Switzerland.

-- 

Adam

On 8 February 2015 at 21:22, Nando Breiter <na...@aria-media.com> wrote:

[Kai Koenig]

That opens an interesting question.

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.

I’d strongly argue that just by virtue of being an association member (which people could be for various reasons: interest in the platform, depending on Lucee for their product, marketing reasons because it comes with a big logo on the website etc), members are not necessarily qualified technically to make any decision on a language spec or language features. I’m not saying they couldn’t as well be qualified to make those decisions, but that’s by far not a given.

Going with such a model would take the language right back to an Allaire/MM/Adobe-approach — “Yeah, that looks cool, I can use that for XYZ, let’s build it” — I assume Micha would veto stupid member decisions anyway though.

What Lucee needs is an independant technical/language steering group led by Micha and Igal, however such a group would be formed and it should be comprised of people who know multiple languages and paradigms and in a perfect world have done language spec work before (at least I know one very good candidate on this mailing list). But organisation membership should for the above reasons not be a criteria for such a language steering group at all.

Cheers

Kai

[Andrew Dixon]

As someone who works for one of the member companies I 100% agree with Kai on this one. I certainly would not qualify myself as being a suitable member of the language advisory board!!!

Kind regards,

Andrew

http://about.me/andrew_dixon

--
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.

[Robert Munn]

I hear you. I should have been more specific- what I find annoying is that CF is different than most other languages in this regard. And I prefer .each() and .map() iterating functions instead of for() loops.

[Robert Munn]

 I just looked at the Google Doc, you guys have been busy! :-)

I didn't see anything really specific about the API except in the tags section. Is there a clean API for everything in the admin? You could have a clean admin API and modular UI components that could used for a unified admin app but could also be embedded individually in other applications with granular ACLs to allow access only to specific functionality. I would love to see a JavaScript implementation of the UI components with a standard JavaScript UI library. How cool would it be to be able to do something like this:

var dsnpanel = new org.lucee.admin.ui.DatasourcePanel();

The UI components could encapsulate all the functionality to deal with the data behind it, so implementation code outside the components would be minimal. You could add event hooks to layer in additional functionality as needed, but the basics of managing datasources in my example could be provided with a single line of code (apart from loading the JavaScript libraries in your app).

I like the idea of implementing the UI library in JavaScript, though I realize that's probably not going to be the popular choice for CFML developers. Even in CFML, making modular admin UI components that encapsulate their functionality and operate against an admin API strikes me as a good thing.

Does it make sense to put the admin API in its own servlet? I can see the benefits, but I don't know enough about it ...

On Sunday, February 8, 2015 at 10:59:54 AM UTC-8, Micha wrote:

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. 

Micha

My 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.

[Robert Munn]

Agreed. There are plenty of people qualified to make suggestions or be used as a sounding board for ideas, but ultimately a small group of the most qualified people should be responsible for guiding the language specification. I don't think the wisdom of crowds applies in this space. Most of us don't have the knowledge, training, and experience it takes to make those sorts of decisions.

[Sean Corfield]

On Feb 8, 2015, at 1:14 PM, Ryan Guill <ryan...@gmail.com> wrote:
> But you can treat queries like an array of structs if thats what you'd like to do, you don't have to use the inconsistent syntax. But if the api of the recordset needs tweaks, lets do that.

You’re still missing my point.

> Recordset objects have their benefits though right? Query of queries, enforcing that there are always the same number and order of columns in the structures - I would also expect that they are / could be optimized for the use cases that recordsets are generally used for.

But there’s nothing to stop QoQ running against an array of structs - and it would be very convenient.

What does a query object provide that a raw array of structs does not (in terms of API, not implementation)?

* qry.recordCount - why not qry.len() which would be consistent with myArray.len()?
* qry.currentRow - really not needed with for ( var row in qry ) … but see below
* qry.colname[i] - as noted, at odds with intuitive qry[i].colname expectation, but qry.col("colname") would be a reasonable addition
* query metadata - again qry.metadata() or even getMetadata(qry) would be reasonable

Note that there’s nothing inherently problematic in having a query object have methods and yet still implement the same API as an array (in terms of iteration and indexing). I’m not suggesting query objects go away completely, just that they conform to an "array of structs" API in terms of behavior - they could still have additional methods to afford the conveniences people like about query objects.

For folks who want indexes when looping over arrays - or queries - what about an extension to for loops like this:

for ( var (elem,ix) in myArray ) {
… elem is the element, ix is the index (1..)
}

for ( var (row,ix) in myQuery ) {
… row is the row(!), ix is the row number (1..)

[Kai Koenig]

>> Recordset objects have their benefits though right? Query of queries, enforcing that there are always the same number and order of columns in the structures - I would also expect that they are / could be optimized for the use cases that recordsets are generally used for.
>
> But there’s nothing to stop QoQ running against an array of structs - and it would be very convenient.
>
> What does a query object provide that a raw array of structs does not (in terms of API, not implementation)?
>
> * qry.recordCount - why not qry.len() which would be consistent with myArray.len()?
> * qry.currentRow - really not needed with for ( var row in qry ) … but see below
> * qry.colname[i] - as noted, at odds with intuitive qry[i].colname expectation, but qry.col("colname") would be a reasonable addition
> * query metadata - again qry.metadata() or even getMetadata(qry) would be reasonable

I think the main difference that is left is that the query object’s “columns” have SQL types attached to them. For QoQ purposes that’s a handy thing to have. A stock-standard implementation of Queries as Arrays of Structs wouldn’t be able to provide that, I assume — but could surely be implemented.

Cheers
Kai

[Ryan Guill]

This all makes sense, and I think making the recordset object fit the interfaces that an array of structs is a great compromise.  I personally like your loop syntax - python has something similar with enumerate() - but like someone mentioned earlier (possibly a different thread), .each() ,.map() and .reduce() is a much more useful abstraction most of the time.

And perhaps with linkedHashMap structures and safe evaluation operators the other benefits of recordsets (that column order and existence is guaranteed) can not be unique either.

Best of both worlds.

[Sean Corfield]

On Feb 8, 2015, at 6:05 PM, Kai Koenig <grmb...@gmail.com> wrote:
> I think the main difference that is left is that the query object’s “columns” have SQL types attached to them. For QoQ purposes that’s a handy thing to have. A stock-standard implementation of Queries as Arrays of Structs wouldn’t be able to provide that, I assume — but could surely be implemented.

Right, the bare array of structs wouldn't have that metadata (but the updated query object that behaved like an array of structs still would). So it would be a matter of whether basic SQL-like metadata could be derived from the data in a bare array of structs - doesn't something already try to do something similar by inspecting the first row of a query? I'm blanking on where that happens...

[Michael Offner]

I completely agree on that, that is the reason I suggested strict as scope cascading mode, with strict you don't have to scope the nearest scopes (arguments, local,variables) but all the ohers.

So #susi# looks for Susi in local and arguments , but not in url,form,cgi,cookie... What i silly and slow.

Micha

On Sunday, February 8, 2015, Dan Kraus <dsk...@gmail.com> wrote:

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.

[Michael Offner]

I remember when the iPad cames out, I was thinking I don't need this kind of device, it's just a big iphone, but I want to have one anyway because I love gimmicks.

But today I could not even imagine to have none.

I feel the same about queries, queries maybe something you can easily do with array of struct, but it is not the same, you loose the 2 dimensional structure. I see query objects the perfect fit for 2 dimensional, data container.

When you check out the cfadmin tag you will see that I have chosen  this type a lot as a return type.

My primary language is Java for more than 10 years and I have seen a lot of code over the years and storing 2 dimensional data in a "array os struct" is seen as a bad choice for sure, because it does not bound you to a structure.

Much more common is using a array/list of specific types:

List<Address> or Address[] (old style)

Sure that is because Java is strictly typed, but like queries I have also in this case the "columns" fix, you could also do 

List<Map<Object>> or Map[] 

but that is simply very bad practice and has no place in clean code.

Maybe queries are not perfect, but to handle 2 dimensional data structures in a untyped languages there is nothing better I know and I do not say that because I only know cfml and nothing else. 

To make it short, array of struct is a bad replacement for queries, array of components is a overkill, of course I'm open for suggestions to replace queries or improve it, but please not with array of structs or array of components.

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/8C1B4EEE-8708-4937-B9F8-D849D4628CE0%40corfield.org.

[Sean Corfield]

Gah! You’re missing my point as well!

I’m not saying _replace_ query objects with array of structs - just make them _behave_ consistently like an array of structs when you’re iterating over them and accessing elements of them.

We already have for ( var row in myquery ) … and row looks like a struct and that’s great. But let’s consistently have myquery[n] behave like row n, and streamline the language to make query objects fit better as a collection type.

Heck, I’m happy with myquery.colname behaving like an array as well (so a query is both an array of structs and a struct of arrays).

I don’t want the _implementation_ to change, I want the _interface_ to be a more consistent set of collection "classes".

Does that help clarify what I’m talking about?

In Clojure terms, I want a query object to be Countable, Indexable, Associative…

Sean

[Michael Offner]

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?

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/6DC15FAA-42B3-45D8-8CA3-3E63522C3861%40corfield.org.

[Sean Corfield]

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… :(

[Dominic Watson]

+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.

In short, great as an open, community driven funnel for a sense of direction, without being the authoritative steer.

My opinion, of course.

Dominic


On Sunday, 8 February 2015 13:42:29 UTC, Micha wrote:

maybe we could use https://www.uservoice.com/ for this or something similar...

Micha

On 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):

https://docs.google.com/spreadsheet/pub?key=0AjP06HZksE60dDRVdEJPSWZYZzhVRXkyYkYtYTNOSGc&gid=4

--
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.

[Adam Cameron]

On 9 February 2015 at 10:15, Dominic Watson <dominic...@pixl8.co.uk> wrote:

+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.

Provided that is the understanding, yeah.

 

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.

Very good point. 

Although it would be better if when people held opinions they had the bottle to stand by them and explain them too. However I understand that people often aren't like that.

-- 

Adam

[Dominic Watson]

> Although it would be better if when people held opinions they had the bottle to stand by them and explain them too. However I understand that people often aren't like that.

People are different. There's a great 40 yo book on fostering creativity in teams, "The Practice of Creativity" http://www.amazon.co.uk/The-Practice-Creativity-Dynamic-Problem-Solving/dp/0963878484. It talks alot about creative meetings and how to run successful ones. I think the rules it sets out apply well to community discussion. One of the fundamentals is that the ego's of each team member are protected. Key to that is a meeting facilitator whose role is probably easier replicated in forums and the like, where editors have a little more power, than mailing lists.

Anyways, enough off topic already, I'm all for UV ;)

As for arrays, I'm all for 1 based. CFML templating language? I think that we already have a pretty good one and that that would potentially be a large waste of energy; solving the mix of logic and display code problem could perhaps be better done by more code quality lead in the documentation and guides (Adobe's code examples are a perfect way of how not to do this!).

Dominic

--
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.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

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

[Michael Offner]

between the lines

On Mon, Feb 9, 2015 at 8:06 AM, Sean Corfield <se...@corfield.org> wrote:

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

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<String> list=getList();
for(String str:list){
   System.out.println(str);
}

or more the classic way:

List<String> 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<Address> 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)

Micha

 

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.