Lucee and the future

[Michael Offner]

there is a lot of discussions going, on about a possible support for an additional dialects for Lucee that is controlled with help of a file extensions.

First of all, atm this are just discussions nothing more!

It is great to talk about everything, there should be nothing we do not question! but again that does not mean it will happen!

We talk here only about a dialect of the language, that mostly already can be done with the settings in the administrator. The cf prefix for example is changed in seconds.

So not a fork with an other direction, only a dialect on top of the engine.

What I can say for sure, Lucee is the best CFML engine out there and we have no plans to change that. the only purpose of the Lucee Association Switzerland  is to maintain and extend the language and to spread the word about it (like defined in the articles). 

The only question is, how we can do the last thing (spread the word). In our opinion this can best be done by not using the word "CFML" to much, that is also the reason we do not use the word "CFML" on the homepage. This dialect is in only a possible way to spread the word about lucee further and not doing a new language!!!

Remember lucee (former Railo) is not only CFML, that is only the base lucee is and was always more, but the base will remain!

Micha

[Dave Merrill]

Thank you for that clarification Micha, very important to some of us.

I get that you're in a bind trying to make that clear, while leaving the ColdFusion stigma behind. It's hard to see how that separation will be possible at the developer level though -- it doesn't take a lot of digging at the code or history level to discover the connection. Hopefully developers can focus on actual capability, where there's a really good story to tell.

[Andrew Penhorwood]

Thanks Micha for the explanation.  What are some of the initiatives on things like documentation and spreading the word on Lucee?  I guess where do I sign up to help.

Andrew Penhorwood

[Jesse Shaffer]

Thank you for this - it calmed many concerns of one of my co-workers.

[Sean Corfield]

On Feb 10, 2015, at 9:35 AM, Jesse Shaffer <dajest...@gmail.com> wrote:
> Thank you for this - it calmed many concerns of one of my co-workers.

Well, if CFML devs weren’t such Chicken Little about this whole thing -- "OMG! CFML is Dead! You’re taking away my tags! You’re forcing me to learn something new!" — they would have realized all along that that was EXACTLY what was being discussed :)

Seriously folks, the ridiculous panic and silly assumptions in these threads lately is exactly why so many non-CFML developers think the CFML community aren’t "real" programmers. Change is a _good_ thing! It’s how _progress_ is made. Sheesh.

Languages evolve. Breaking changes get introduced in all languages over time. In fact part of what’s held CFML back so much is Macromedia and Adobe’s extreme commitment to _not_ breaking any CFML code — and having to ensure that even really bad code from a decade or so ago still runs! That’s been one of the biggest problems for Railo — maintaining compatibility with really stupid behavior in ColdFusion. Other languages are much more pragmatic about that, and that’s how they’ve evolved faster than CFML and why CFML looks old-fashioned by comparison. Because Macromedia and Adobe never forced you to change, now you’re set in your ways and you don’t want to change and you’re afraid of change.

So now we have the idea that today’s CFML will run "as-is" on Lucee in .cfc and .cfm files and a new language — evolved from CFML — will run in .lucee files. Your current CFML applications will continue to run "as-is". You can leverage the new, improved language if you want in .lucee files. You can — if you wish — migrate some of your .cfc and .cfm files to .lucee files, updating the code to match the new dialect.

This seems to be the best of both worlds: Lucee can offer a much improved scripting language that might appeal to non-CFML devs, as well as letting all that primordial code still run in "compatibility mode".

Win-win!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Dave Merrill]

Right, I get it, we have a lot of production code that references the arguments scope and other quaint antiquities, and so do our customers. We'd prefer not to rewrite it, and so would they, so we're all Chicken Littles, not Real Programmers(tm). Sheesh.

This wasn't about assumptions, it was about a clear statement of intent, which we now have. Win-win!

Perhaps there was one somewhere before, but since there's no place where such things are known to live, folks were effectively if not actually in the dark.

Just like newcomers will be in the future until they find this thread, or a mission statement to this effect gets published in some appropriately obvious place. Except that there won't be one because we don't want to associate Lucee with CFML in public. I'm having trouble seeing how this whole conversation doesn't just keep happening.

*ducks*

[Michael Offner]

Between the lines

Micha

Am Dienstag, 10. Februar 2015 schrieb Andrew Penhorwood :

Thanks Micha for the explanation.  What are some of the initiatives on things like documentation and spreading the word on Lucee? 

The wiki is open to everybody, I try to force everybody to contribute there, please do!

We are already working together with pixl8 to improve the website.

Mark drew is working on doc.lucee.org, he can for sure also need help on this.

But our resources are limited, but we do our best.

 I guess where do I sign up to help.

It's funny I just added a text to the website for exactly this question (not published yet)

 

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/9167f74b-f7a0-4679-94e9-662fcef235a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Judith Barnett]

Yes, languages involve. Yes, change happens.  However the concern from the programmers isn't the wild-eyed, OMG panic you describe.  It is more a real concern that existing code will break when there is neither time nor budget to fix or rewrite it.  I support a lot of legacy sites in both CF and PHP.  When languages change with no thought for the damage to the existing code base, it creates havoc for those of us doing the support.  I've recently spent weeks refactoring some of the PHP sites for exactly this reason, on my own dime, because the client couldn't afford it.  Small businesses, tough times.

While it was clear to me in closely following the messages here that a new dialect was being suggested for lucee, use of words like "ditch" and "kill" certainly created some degree of concern among some of the developers, mostly those who are not clear on why the change from Railo to Lucee happened, who perhaps do not have English as first language, or who do not have time to read every message and follow the detains of the changes.

We aren't all just a bunch of CFML fan boys thinking we will lose our toys.  There are real business concerns involved in this.

[Dominic Watson]

> Seriously folks, the ridiculous panic and silly assumptions in these threads lately is exactly why so many non-CFML developers think the CFML
> community aren’t "real" programmers. Change is a _good_ thing! It’s how _progress_ is made. Sheesh.

I hate to bring this up, but I feel I must after seeing a lot of this kind of messaging over the last week or so.

What has disappointed me, far more than people raising concerns, is the belittlement of those opinions. I'm quite sure you don't mean it this way Sean, but your wording translates to calling anyone who raises any objections "silly" and "ridiculous".

No one in these past few threads has mentioned that CF is dead and there has been little or no hyperbole, just legitimate choices to be made by businesses and legitimate fears (and also a difference of opinion on which particular changes are needed / wanted).

A branding change, and change or direction, is going to leave people disoriented and will take time to settle. Reassurance, respect and positivity should be the order of the day. I hope that will prevail.

Respectfully,

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/C55556AE-33CF-47BD-9FBA-634462B054B0%40corfield.org.

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]

I think the biggest misunderstanding was that people was thinking that we will fork lucee and have 2 products in the future and that on a long run there will be a loser and a winner and they could end up on the losing site.

That will not happen! Whatever the outcome is, we always will have only one project!

Micha

[Sean Corfield]

On Feb 10, 2015, at 12:05 PM, Dominic Watson <dominic...@pixl8.co.uk> wrote:
> I'm quite sure you don't mean it this way Sean, but your wording translates to calling anyone who raises any objections "silly" and "ridiculous".

Not **any** objections. Just certain uninformed, unfounded objections. About things that aren’t even being proposed for .cfm / .cfc files. And the problem is those folks are getting in the way of discussing what .lucee could be by constantly bringing the issue back to what they want .cfm / .cfc to remain.

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 10, 2015, at 11:59 AM, Judith Barnett <jmba...@gmail.com> wrote:
> When languages change with no thought for the damage to the existing code base, it creates havoc for those of us doing the support.

"no thought"? Really, you believe language designers and projects change language features on a whim, and apply "no thought" to their decisions? That’s pretty insulting to the folks who lead these projects…

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

[Sean Corfield]

On Feb 10, 2015, at 11:58 AM, Dave Merrill <enig...@gmail.com> wrote:

We'd prefer not to rewrite it, and so would they, so we're all Chicken Littles, not Real Programmers(tm). Sheesh.

And you wouldn’t have to rewrite it. No one is suggesting you rewrite existing CFML code. That’s the whole point.

[Judith Barnett]

No, it is only insulting to those who "ditch" a significant feature of a language that has been used for years simply because they don't like it.  I'm not saying that has happened in Lucee, just that the rhetoric being thrown around in these threads, if not read carefully, suggest it could.  And it has certainly happened in other languages.

On Tue, Feb 10, 2015 at 3:13 PM, Sean Corfield <se...@corfield.org> wrote:

On Feb 10, 2015, at 11:59 AM, Judith Barnett <jmba...@gmail.com> wrote:
> When languages change with no thought for the damage to the existing code base, it creates havoc for those of us doing the support.

"no thought"? Really, you believe language designers and projects change language features on a whim, and apply "no thought" to their decisions? That’s pretty insulting to the folks who lead these projects.

[Michael Offner]

Please have in mind that this is and was a open discussion and this discussion will not end with a final product, it will lead to official process to define this dialect and we will communicate as open as possible, but again nothing is decided yet...

About arguments scope, that was just a example of many, I have no strong opinion on that, I just tried to explain why I think the argument scope is a bad thing, but of course this is just my opinion, in my code you will find never a argumentcollection=arguments because I personally don't like that. So whatever a possible outcome will be there will be always something you will not like. When you want to have black there will be someone that prefers white.

Best example are tags, some would love to seem the gone, others hate cfscript, black and white ...

So again a pragmatic and simple solution.

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/f30a90ef-7bf4-43a5-a13a-67348c43f9a3%40googlegroups.com.

[Dominic Watson]

> That’s pretty insulting to the folks who lead these projects…

You've a track record there Sean: https://issues.jboss.org/browse/RAILO-3001

And you are also missing my point, or choosing to ignore it. When people miss the point, or get the wrong end of the stick, they don't need or want to be publicly belittled. This attitude causes far more harm than people raising their "unfounded" objections and opinions.

Having multiple dialects *is* a concern that needs to talked through carefully. People want to be able to keep up with where the project is focused. If that focused energy is on a dialect that will leave them unable to upgrade, they will be left behind and the community will shrink further.

Whether or not that is actually what is going to happen, it certainly feels like it might and fears are legitimate. Not stupid, silly or ridiculous.

--
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/E5FCC9B3-E5E9-48AE-BE66-114D3D886618%40corfield.org.

For more options, visit https://groups.google.com/d/optout.

[Dominic Watson]

> About arguments scope, that was just a example of many, I have no strong opinion on that, I just tried to explain why I think the argument scope is a bad thing, but of course this is just my opinion, in my code you will find never a argumentcollection=arguments because I personally don't like that.

This a great example of the kind of thing that should be approached very carefully when talking about moving forward. I personally think that ditching the arguments scope, even in the new Lucee dialect would be a bad choice, not least for it being a dramatic departure from something that I have never heard anyone object to until now.

The objection, as I understand it, is against needing to scope arguments within a function. Its ugly and there is a performance hit if you don't do it. I dislike needing to do this, and I expect you would get almost unanimous agreement with this.

A compatible, less abrasive solution to this problem might be to automatically make passed arguments available in the function local scope (as you have suggested), but to also keep the arguments scope available to those who need or want to reference it distinctly from the function local scope.

So:

function someMethod( required boolean someArg ){

    if ( someArg ) { // << no scope crawling, good performance, good readabilty - everyone wins

        // ...
        // ...
        // ...
      

        logSomethingTerrible( message="somethingHorribleHappened", method="someMethod", argsPassed=arguments ); // << still possible (and useful)

    }

}

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwJsvCJLWViW1puBjQx-SedaTp-UOdN7A4DVm22%3DenLCA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

First of all, let's try to be nice, being mean never proves a point.

Dominic you should measure me not about what I'm saying, you should do it on what I did the last 8 years with Railo. I tried hard to be as compatible to CFML as possible, even this voices to break compatibility with acf was always there and even it was a pain in the ass sometimes...

Micha

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

[Jesse Shaffer]

Having multiple dialects *is* a concern that needs to talked through carefully. People want to be able to keep up with where the project is focused. If that focused energy is on a dialect that will leave them unable to upgrade, they will be left behind and the community will shrink further.

That is exactly the concerns that were being felt over this way.  How far can a "dialect" go before it becomes a language competing with itself?

[Michael Offner]

Let's make me an example , Railo Is supporting the  "scope cascading setting" or the support of "no variables scope in cfc setting" a long with many others since version one.

Yes this was a extra effort to implement them, but it takes no real extra effort to maintain the engine when they are there.

We are speaking about that you can control this setting with help of a extension.

Remember my dvd/cd example in the beginning.

Maybe we will add some features, but that will take for sure no extra effort in maintaing the engine, I will make sure for that, believe me, then that is the most important task. It always is whe. We add settings like this.

Techically all this is not a big deal anyway, implementing most of the changes we talked so far is done in a couple of days, including the list is posted.

It not about adding this features it more about adding a template based switch that produces no overhead.

Micha

Am Dienstag, 10. Februar 2015 schrieb Jesse Shaffer :

Having multiple dialects *is* a concern that needs to talked through carefully. People want to be able to keep up with where the project is focused. If that focused energy is on a dialect that will leave them unable to upgrade, they will be left behind and the community will shrink further.

That is exactly the concerns that were being felt over this way.  How far can a "dialect" go before it becomes a language competing with itself?

--

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/f93f00d6-182f-4680-8d2f-d2316e789795%40googlegroups.com.

[Dominic Watson]

> Dominic you should measure me not about what I'm saying, you should do it on what I did the last 8 years with Railo. I tried hard to be as compatible to CFML as possible, even this voices to break compatibility with acf was always there and even it was a pain in the ass sometimes..

Absolutely. I measure you with the highest regard Micha.

Another concern to do with a multitude of feature and language behaviour switches is maintaining compatibility with frameworks and extensions. i.e. your application might want to use project X but can't because it's using project Y that relies on a fundamentally different set of settings.

Has there been discussion around being able to set these behaviour switches at a more granular level than server context / web context / application? Or is this indeed possible already? i.e. Something like this would allow for much greater freedom and cross compatibility I think (slight brain fart):

Some.cfc
--------------

/**

 * @languageFeatureXEnabled true
 */

component output=false {
    // ...

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwtyyQyLAf10WD%2BV3p-bn3FmXiO2PS6FtUQ%3D8-LBpVmvg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Adam Cameron]

Wouldn't something along the lines of an import statement work better there, and seem less "weirdo CFML way of doing stuff" there?

Semantics aside, it's a good suggestion. Having all these detached switches / settings in various places that are nowhere near the code concerned has always seemed a bit dubious to me.

--
Adam

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Dominic Watson]

Yeah, wasn't a massive fan on the syntax I used either ;) Something along the lines of javascript's strict mode, with a terse and clear syntax: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B54D9975-36E0-4E76-893D-E88C126E267C%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Shaffer]

That makes plenty of sense - and keeping in mind that I sponsored Issue 82 concerning classes, realize I am personally all for additional, new syntax.

I think the key is understanding exactly what you mean by this phrase:

Remember lucee (former Railo) is not only CFML, that is only the base lucee is and was always more, but the base will remain!

I read this as the Lucee is an underlying Java framework supporting CFML's syntactical constructs (pages, tags, functions, components, etc), loosely coupled with the CFML syntax itself.  So if a new .lucee extension is introduced - with its own parser - it is still utilizing this same framework producing compatible bytecode, just getting there a different way. Therefore, if the bytecode is compatible, then similar constructs should be interoperable between syntaxes. For example, I would expect that then that a CFM template could use <cfinclude> to load a Lucee template (even if lcml [lucee markup language] templates resemble handlebars/mustache/whatever else is hot) - and vice versa.  As for my class syntax proposal - CFCs could then be instantiated within by a Lucee Class, and vice versa.  Perhaps it means that they can even extend each other.

I love the extension concept.  Looking around in the code, the thought occurred to me as how nice it would be if the parser was modular, or at least where it could support plugins, so that additional constructs could more easily be introduced.

[Jesse Shaffer]

I love the extension concept.  Looking around in the code, the thought occurred to me as how nice it would be if the parser was modular, or at least where it could support plugins, so that additional constructs could more easily be introduced.

So... I didn't finish that paragraph.

You could support modular parsing by introducing Lucee extensions (the OSGi bundled extensions that is) which bind a file extension to its own provided parser.

[Dominic Watson]

Per file declarations could get annoying too. It would be great to be able to target a package of code with a particular set of settings (without that package needing it's own Application). I'm not sure that I can come up with a palatable suggestion for achieving that from a programming language perspective (much easier to implement in a framework or somesuch). The first outrageous thing that comes to mind is a Package.cfc(?!):

/myApp

--- /myappfiles

--- /someframework

------ /system

------ Package.cfc <!-- define settings that would apply to everything in the 'someframework' folder. Potential lifecycle hooks too?!!

Application.cfc

That may be a bit far out.

[Sean Corfield]

On Feb 10, 2015, at 12:27 PM, Dominic Watson <dominic...@pixl8.co.uk> wrote:

> That’s pretty insulting to the folks who lead these projects…
You've a track record there Sean: https://issues.jboss.org/browse/RAILO-3001

One ticket is a "track record"? :) Oh, I know… I’m no stranger to heated debates… and I’ve been on the receiving end too as someone who has worked on dozens of FOSS projects over 20+ years...

I won’t air dirty laundry but let’s just say there was some background to that exchange — and, with Lucee, the prospect of compatibility with .cfm / .cfc files and the evolution that could be .lucee files makes me much more positive about the future :)

Having multiple dialects *is* a concern that needs to talked through carefully.

Yes, indeed, but if one those dialects is today’s CFML — which Micha (and several others) have said will continue to be supported — then let folks who want to continue to program in CFML use that dialect, and let’s talk about what the other dialect could be without these constant interjections about legacy code bases ceasing to work.

Does a company look at two programming languages and say "You know, we’d have much less risk if we pick the language that is going to stay the same and never change or evolve" rather than pick the one that’s going to improve and modernize and help their business deal with more complex problems?

[Adam Cameron]

It's fairly normal to need to import functionality into each class that uses it though, yes? It's not THAT much of a hardship.

--
Adam

[Sean Corfield]

On Feb 10, 2015, at 1:44 PM, Dominic Watson <dominic...@pixl8.co.uk> wrote:
> Another concern to do with a multitude of feature and language behaviour switches is maintaining compatibility with frameworks and extensions. i.e. your application might want to use project X but can't because it's using project Y that relies on a fundamentally different set of settings.

I think this is the most promising aspect of the .cfm/.cfc and .lucee extension possibility: a framework that expects CFML behavior can be written in CFML, just like it is today, and be portable across CFML engines (as Mura, PresideCMS, ColdBox, FW/1 and countless other projects are). A framework that wants to leverage the "language behavior switches" implicit in the Lucee dialect can choose to do so, by providing .lucee files instead, with the trade off being that it would only run on Lucee.

The multitude of switches in Railo has always been a big concern for me as a framework author because a user could always decide "Oh, you know, we want all our code to use strict scopes" (or some other optional feature) and then be upset if framework code doesn’t work on it. Railo provided a vast number of potential target "dialects" but — fortunately for most of us trying to write portable software — most Railo users don’t tend to use them all that much and thus the compatibility issue has not been the headache it could have been.

On the other hand, with the idea that Lucee supports essentially just two dialects, it’s a much more appealing platform.

Consider FW/1: the first version was tag-based and ran on CFMX 7+, Railo 3+, and even OpenBD (sort of). When I developed 2.0, I started from scratch in cfscript, and supported CF9.0.2+ and Railo 3+ (a testament to how much more advanced Railo 3 was compared to ACF back then!). Not OpenBD, not CF8 or even CF9.0.0. It was really nice to be able to use the much improved version of the language. Lately I overhauled cfmljure and targeted just Railo 4. A community member - Andrew Myers - got it running on ACF11 (nothing earlier I believe) and even that was a bit painful. I look forward, at some point, to creating a future version of FW/1 and friends that are Lucee-specific so I can leverage the improved scripting language there. But FW/1 1.x still exists and gets occasional updates for folks still using it on CFMX7/ACF8 - it’s had three point releases supported those older versions.

Some features of FW/1 3.5 will require Railo 4 / ACF11 I suspect — but the core functionality will probably still run on ACF9.0.2 although I’d prefer to only go back to ACF10 at the earliest — so it’ll be at least a couple of years before I’d even get to a version of FW/1 that would be Lucee-specific. And the then-current FW/1 would continue to be CFML and run on ACF/Railo/Lucee-as-CFML anyway — it would only be version-next that might decide to break with CFML.

At work we have 90kloc CFML. We’re already switching to Lucee — for its CFML support — and I look forward to writing .lucee files with an improved language in the future but I don’t plan to rewrite that legacy CFML wholesale to .lucee files, and I wouldn’t expect anyone else to do so.

That’s why this proposal — two dialects that let people migrate piecemeal or even just stay on CFML — is such a win-win idea IMO.

[Michael Offner]

see my answers between the lines

Micha

On Tue, Feb 10, 2015 at 10:44 PM, Dominic Watson <dominic...@pixl8.co.uk> wrote:

> Dominic you should measure me not about what I'm saying, you should do it on what I did the last 8 years with Railo. I tried hard to be as compatible to CFML as possible, even this voices to break compatibility with acf was always there and even it was a pain in the ass sometimes..

Absolutely. I measure you with the highest regard Micha.

Thx, i give my best ...

 

Another concern to do with a multitude of feature and language behaviour switches is maintaining compatibility with frameworks and extensions. i.e. your application might want to use project X but can't because it's using project Y that relies on a fundamentally different set of settings.

Has there been discussion around being able to set these behaviour switches at a more granular level than server context / web context / application? Or is this indeed possible already?

There is no general approach for this,

"local scope mode" for example can be set in admin, the application.cfc/cfapplication and within the function 

function test() localmode="true"{}

then the most underestimated tag is <cfapplication action="upadte">, this tags allow to update the current application context in any place at any time:

https://bitbucket.org/lucee/lucee/wiki/Cookbook_ApplicationContext_Update

 

i.e. Something like this would allow for much greater freedom and cross compatibility I think (slight brain fart):

Some.cfc
--------------

/**

 * @languageFeatureXEnabled true
 */

component output=false {
    // ...

see example above 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxnUpnu%2B%3DvCxKwGiYmPruWrFcH0Z41N15qx%2Bx-UT5%2BNASQ%40mail.gmail.com.

[Robert Munn]

lucee.json.

You don't need code, just structured data to define settings. If you want to use the Lucee engine to protect the file, then what about a file called ".lucee", like the *nix convention for hidden files.

[Walter Seethaler]

In general I like the idea of the .lucee approach. On the other hand it is pretty obvious, that we will ran into the same problems like now, with the subsequent releases of the .lucee dialect - e.g. the backward compatibility, correcting wrong decisions etc. As ACF will probably not support .lucee, we would have more freedom to evolve the dialect, for the price of a less homogenous lucee engine and a general incompatibility with ACF (if the .lucee source code is involved in frameworks, tools etc.).

On a sidenode. Let's get rid of ACF! Well, I would like to, but we are simply not able to port all our legacy applications mainly because of the mass of (undocumented) incompatibilities with ACF. (In our case we update the legacy applications regularly with knew releases of our CMS, which has to stay compatible with ACF as long those legacy apps are supported). I have a list of around 50 issues, which are not so easy to report because some are ACF bug, some Railo bugs, some in between, some where reported but refused. I guess a lot of people have similar problems. Before we sails to new shores, I would like Lucee to put major effort in solving every (sane) compatibility issue and provide a red carpet for the people who wants to migrate. One problem is the resolve time of a blocker - when I try to migrate, I want to do it now. Maybe we could plan some weeks/month to fully concentrate on that problem, with the aim to solve or document every known incompatibility. After that, I would be ready to board the ship.

On the switches. I did some framework stuff and had the same problems as Sean described. While Micha invented the "dialect switches" to evolve the language while staying compatible with ACF, it was painful to me to hear "we can add a setting in the administrator for that". How can you develop a framework that supports all the scope options in Railo? Its pretty difficult. Even more important, we have a small community and few OS tools out there should be usable on as much as plattforms as possible. But those settings are bad for portability, maintainability, testability etc. 

How can we turn that weakness into a strength? I think we need to get rid of the settings in the administrator and provide it on a package level. The main unit of reuse is the package, if we can define the required settings in the package, frameworks and OS tools and libraries could use their own settings, decoupled from their consumer's codebase. This would only work if those settings are "a blackbox" to other packages, eg. how would a full null support work with inheritance in other packages without full null support. So I guess its not that easy. I think a major point would be to identify the settings that are compile time settings, because those could be easier implemented as "a blackbock", eg. replace component{...} the new syntax class{...}. Other things to discuss and clarify would be:

- Which settings are reasonable on a package level.

- Definition in the package, e.g. package.lucee in json-Format, with json schema validation?

- Do the templates get recompiled after setting changes. 

- How can the package definition format evolve in future Lucee versions.

- Tools to generate and edit the package definition.

- ...

If we could solve those problems, we would gain much more freedom with backward compatibility in the future.

So, yes to .lucee, but let all willing people participate (migrate) and lets think about how .lucee is going to evolve.

[Dominic Watson]

> It's fairly normal to need to import functionality into each class that uses it though, yes? It's not THAT much of a hardship.

Yeah, I guess. Just thinking out loud.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/28C83238-4CAE-49D8-B4AD-45B7E2F48106%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

Please see my answers between the lines

Micha

On Wed, Feb 11, 2015 at 4:18 AM, Walter Seethaler <seet...@nbsp.com> wrote:

In general I like the idea of the .lucee approach. On the other hand it is pretty obvious, that we will ran into the same problems like now, with the subsequent releases of the .lucee dialect - e.g. the backward compatibility, correcting wrong decisions etc. As ACF will probably not support .lucee, we would have more freedom to evolve the dialect, for the price of a less homogenous lucee engine and a general incompatibility with ACF (if the .lucee source code is involved in frameworks, tools etc.).

When we started Railo we never only want to be only a ACF clone, so we had from beginning features only supported in Railo, every feature only supported by Lucee/Railo can be seen as a incompatibility to ACF, but that what it is...

 

On a sidenode. Let's get rid of ACF! Well, I would like to, but we are simply not able to port all our legacy applications mainly because of the mass of (undocumented) incompatibilities with ACF. (In our case we update the legacy applications regularly with knew releases of our CMS, which has to stay compatible with ACF as long those legacy apps are supported). I have a list of around 50 issues, which are not so easy to report because some are ACF bug, some Railo bugs, some in between, some where reported but refused.

we can only fix reported issue and we decide from case to case what is a bug in Railo or ACF, sometime we do "bug compatibility", so even something is clearly a bug in ACF but many users are using the site effect of that bug we do implment it, like for example:

<cfsilent>

<cfabort>

i'm visible

 </cfsilent>

 

I guess a lot of people have similar problems. Before we sails to new shores, I would like Lucee to put major effort in solving every (sane) compatibility issue and provide a red carpet for the people who wants to migrate.

We try that very hard believe me, but do not forget this is a open source project with limited resources, so issues that concern more people always come first.

Maybe you should give a example of a not solved sane incompatibility isse (take the best you have) and then i will explain why this one is not solved yet.  

 

One problem is the resolve time of a blocker - when I try to migrate, I want to do it now. Maybe we could plan some weeks/month to fully concentrate on that problem, with the aim to solve or document every known incompatibility. After that, I would be ready to board the ship.

On the switches. I did some framework stuff and had the same problems as Sean described. While Micha invented the "dialect switches" to evolve the language while staying compatible with ACF, it was painful to me to hear "we can add a setting in the administrator for that". How can you develop a framework that supports all the scope options in Railo?

Maybe you realized that with Railo 4.2 we added support for A LOT of the settings you can do in the admin in the application.cfc

You can even generate a application.cfc (export page) based on your settings in the admin.

For every single setting in the admin that is also possible in the application.cfc you get also a hint directly on the page where you do the setting.

We did that only to address exactly that problem. So simply add that switch in the application.cfc and you are fine, so this is no isse anymore!

I was even thinking to support in the future this settings ONLY in the application.cfc

 

Its pretty difficult. Even more important, we have a small community and few OS tools out there should be usable on as much as plattforms as possible. But those settings are bad for portability, maintainability, testability etc. 

How can we turn that weakness into a strength? I think we need to get rid of the settings in the administrator and provide it on a package level.

what we do (application.cfc) and a .lucee extension can give us the opportunity to do in on template level, but of course i'm open for suggestions, but remember it need to be easy.

 

The main unit of reuse is the package, if we can define the required settings in the package, frameworks and OS tools and libraries could use their own settings, decoupled from their consumer's codebase.

you can do as many application.cfc in you application as you like...

 

This would only work if those settings are "a blackbox" to other packages, eg. how would a full null support work with inheritance in other packages without full null support.

full null support is a other case, this is a compiler setting and not a runtime setting...

 

So I guess its not that easy. I think a major point would be to identify the settings that are compile time settings, because those could be easier implemented as "a blackbock", eg. replace component{...} the new syntax class{...}. Other things to discuss and clarify would be:

- Which settings are reasonable on a package level.

like i said we already have package level with help of the Application.cfc, i'm personally strongly against adding more complexity here,

that is not the job of the engine, whatever we do limits possible framework used with the engine

 

- Definition in the package, e.g. package.lucee in json-Format, with json schema validation?

- Do the templates get recompiled after setting changes. 

yes if it is a compiler relevant setting like full null support

 

- How can the package definition format evolve in future Lucee versions.

best by not adding this to the engine (see above), better do this as part of a framework like coldbox or FW/1

 

- Tools to generate and edit the package definition.

- ...

If we could solve those problems, we would gain much more freedom with backward compatibility in the future.

So, yes to .lucee, but let all willing people participate (migrate) and lets think about how .lucee is going to evolve.

please do not forget, when you do a .lucee file you give up compatibility to ACF, ACF has copied a lot of Railo features lately but they managed to make them always sligthly different, in my opinion this is not by accident. so they will for sure never do a .lucee extension.

 

--
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/f2ddc8ec-1ec0-4613-a8bc-3fbfec01d993%40googlegroups.com.

[Dominic Watson]

Great points all round. I hear you Sean, particularly on the compatibility nightmare. I still disagree that having a .lucee will solve that problem though; Future versions of Lucee will want to introduce breaking features and potentially start adding feature switches - you then get feature switches for two dialects (may not happen, but it is a reasonable vision I think).

Some kind of "use strict"; directive might be a gentler alternative with the same overall benefit (the downside being extra markup, of course). For me, I see:

* Multiple dialects: benefit of a fresh start and clean break. That freshness may not last though. Mixed marketing messages?

* Gazillion feature switches: Benefit of gentler compatibility upgrades bu no clean break + potentially fiddly configuration. Revisited approach *could* improve the situation, but would have to tread carefully.

Overall I think we all want the same thing - how it is actuated is a hot topic that demands respectful debate.

Sean, apologies for the dirt raking. Was a lame move.

Dominic

[Michael Offner]

A small site note, in version 4.2 we added the possibility to do a lot of the admin settings in the application.cfc, so if your app is depending on a certain feature, make sure of it in the application.cfc...

The admin will show you a hint with every setting that is possible in the application.cfc in addition you can export a application.cfc file based on you admin settings.

Micha 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxkACK_25V547LQFOWfOb2-Vgf1m512wOAxqbs45_extiA%40mail.gmail.com.

[Dominic Watson]

> A small site note, in version 4.2 we added the possibility to do a lot of the admin settings in the application.cfc, so if your app is depending on a certain feature, make sure of it in the application.cfc...The admin will show you a hint with every setting that is possible in the application.cfc in addition you can export a application.cfc file based on you admin settings.

+1 this is awesome sauce and really convenient. I hear you around being skeptical about adding this ability on a more granular level too, but I still think it an idea worth exploring. Take this bug with CfStatic: https://github.com/DominicWatson/cfstatic/issues/111

This could potentially be fixed with a few directives in each of the effected files around how the arguments scope is to be treated and about how local variables are to be retreated. Applications then would not be able to break this utility by having conflicting settings.

Of course, the author of that utility should have known better than to experiment with not scoping their arguments ;) - but the point remains.

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

For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

in that case you can simply set

function whatever() localmode="false" {

}

so you no longer have to care about the setting in the admin/application.cfc

Micha

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

[Dominic Watson]

Exactly, that could work well. Also:

component localmode=false {
}

It would want careful planning though, again. There could potentially be a whole host of flags to switch and could get messy.

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

For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

this is not planned this is working ...

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUx%3DeiwSHtX2B%3DDF9F7TZHJPUTKgMJJhrZAyAtTOjobUcCw%40mail.gmail.com.

[Dominic Watson]

Aha! That's awesome. Apologies for not looking - I've not run into this issue other than the CfStatic bug (which I don't currently have the time for). Will make a note in there.

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

For more options, visit https://groups.google.com/d/optout.

[Walter Seethaler]

Hi Micha, thank you very much for your reply.

we can only fix reported issue and we decide from case to case what is a bug in Railo or ACF, sometime we do "bug compatibility", ...

Yes, I will report everything and provide TestCases. I postponed it to Railo 5 because I hoped to have a better chance to get it fixed then. The new wiki may also be a good place to comprehensively document everything. And I will try to follow Adams example and try to do things instead of point the finger at it. 

We try that very hard believe me, but do not forget this is a open source project with limited resources, so issues that concern more people always come first.
Maybe you should give a example of a not solved sane incompatibility isse (take the best you have) and then i will explain why this one is not solved yet.

This was not meant as a dig at all, I realy appreciate your work. I just meant, you do not need to solve everything. I understand that there always will be some open stuff. I can provide some examples, but please don't see it in a "why this isn't fixed yet" way. You asked about the future and I just wished to concentrate on current issues first (especially when the different behaviour makes not much sense).

• RAILO-3120 completely killed my first approach to Railo. Everyone who rans into this issue and has no clue about it, will not be able to migrate anything from ACF to Lucee
  
• Some issues with package access
• Can not call a package method in a CFC from a .cfm in the same package. This was reported by Gert in ~2009 but refused. I prefer the ACF way here.
• Call of package function init() from another package doesn't throw an error, but returns an instance without calling the the constructor.
• Can not catch(any e){} a request timeout in railo, which creates different behaviour. Only in the onError on Application
  
• lock timeout=0 {} does not deactivate the timeout. To code robust, you have to put a catch around every of those locks.
• Typed arrays are not supported: User[] function getFriends(required User[] users)

All those examples are not critical, but they show that you can not use your ACF legacy code on Lucee without refactoring alot.

On the switches and Application.cfc.

Thanks for the input. I realised the possiblility in the Application.cfc and appreciate it, it will make deployment of applications easier. I was not aware that you can place multiple Application.cfc in your application. Not sure how this works, but I will check it out. This will of course not solve any ACF compatibility issues, because ACF propably has completely different Application.cfc behaviour there.

My (private) solution for the ACF incompatibility will simple be, not to care about it anymore and concentrate on Lucee. 

Cheers

Walter

[Michael Offner]

please see my comments between the lines

Michi

On Wed, Feb 11, 2015 at 3:15 PM, Walter Seethaler <seet...@nbsp.com> wrote:

Hi Micha, thank you very much for your reply.

we can only fix reported issue and we decide from case to case what is a bug in Railo or ACF, sometime we do "bug compatibility", ...

Yes, I will report everything and provide TestCases. I postponed it to Railo 5 because I hoped to have a better chance to get it fixed then. The new wiki may also be a good place to comprehensively document everything. And I will try to follow Adams example and try to do things instead of point the finger at it. 

We try that very hard believe me, but do not forget this is a open source project with limited resources, so issues that concern more people always come first.
Maybe you should give a example of a not solved sane incompatibility isse (take the best you have) and then i will explain why this one is not solved yet.

This was not meant as a dig at all, I realy appreciate your work. I just meant, you do not need to solve everything. I understand that there always will be some open stuff. I can provide some examples, but please don't see it in a "why this isn't fixed yet" way. You asked about the future and I just wished to concentrate on current issues first (especially when the different behaviour makes not much sense).

• RAILO-3120 completely killed my first approach to Railo. Everyone who rans into this issue and has no clue about it, will not be able to migrate anything from ACF to Lucee
  
• Some issues with package access
• Can not call a package method in a CFC from a .cfm in the same package. This was reported by Gert in ~2009 but refused. I prefer the ACF way here.

what was the ticket, we never simply refuse, so there was for sure a explanation why we refused 

• Call of package function init() from another package doesn't throw an error, but returns an instance without calling the the constructor.

with "constructor" you mean the body of the component?

in the end init is also only a function, that has simply a special meaning for the comonent, does acf act different in this case? 

• Can not catch(any e){} a request timeout in railo, which creates different behaviour. Only in the onError on Application

i assume you speak about "request timeout", that is in my opinion clearly a bug in ACF take this example:

done=false;

do{

    try {

        doSomethingTimeConsuming();

        done=true;

    }

    catch(any e) {

       continue;

    }

}

while(!done);// try again

it is not a very goood example, but the point is, when you reach a request timeout, the request must end when you can catch the event and go on with the event, then there is something wrong! there is also a ticket about this in the Railo bugtracker ...

 

• 
  
• lock timeout=0 {} does not deactivate the timeout. To code robust, you have to put a catch around every of those locks.

have you tested -1? please raise a ticket for it 

• Typed arrays are not supported: User[] function getFriends(required User[] users)

should be, please raise a ticket for it 

All those examples are not critical, but they show that you can not use your ACF legacy code on Lucee without refactoring alot.

that is higly depending on the application.cfc you migrate, i have helped to migrate a lot of applications in the last years, mostly this was not a big deal and we could always sort out all problems. most of your point are very specific and not a problem for most applications

 

On the switches and Application.cfc.

Thanks for the input. I realised the possiblility in the Application.cfc and appreciate it, it will make deployment of applications easier. I was not aware that you can place multiple Application.cfc in your application. Not sure how this works, but I will check it out. This will of course not solve any ACF compatibility issues, because ACF propably has completely different Application.cfc behaviour there.

nope, Lucee (by default) and ACF are always picking the nearest application.cfc from the current location (curr2root).

This is the case in CFML as far as my expirence with CFML goes back (Coldfusion 3).

so you can for example have one in the webroot and one in the folder /admin that then has different settings.

When you for example call /lucee/admin.cfm or /CFIDE/Administrator/ (in ACF), you use a application.cfc inside this subfolders that has for sure different  settings than the application.cfc you have in your webroot.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/423598ef-9b07-42f8-b489-bf6bbd6c08bc%40googlegroups.com.

[Jesse Shaffer]

• Call of package function init() from another package doesn't throw an error, but returns an instance without calling the the constructor.

with "constructor" you mean the body of the component?

in the end init is also only a function, that has simply a special meaning for the comonent, does acf act different in this case?

I've run into this before also, and it is somewhat of a head-fake.

Let's say you have a special internal component that for whatever reason, you are the master of the secret knowledge needed to instantiate that component.  You set the "init" method's access to package.

/my/protected/Component.cfc

component {

   package function init(required dependency) {
      // I intend that this component can only be created by other components within the my.protected package.
      this.setMyDependency(dependency);
      return this;
   }

}

 

Then, you create a factory for it:

/my/protected/Factory.cfc

component {

   public Component function getComponent() {
      var comp = new Component(); // blows up - missing required argument.
      var comp = new Component(theDependency);
      return comp;
   }  

}

The issue is, the developer's first guess is that trying to create my.protected.Component from an outside package would fail, except it doesn't:

/some/thirdparty/Factory.cfc

component {

   public my.protected.Component function getComponent() {
      // sadly, this will "work" in that an instance is returned, except the init method is ignored because it's a "package" method.
      var comp = new my.protected.Component();

      // even worse, so will this - except the dependency never gets set, because the init method was again, ignored.
      var comp = new my.protected.Component(badDependency);

      return comp;
   }  

}

I understand in the 3rd example there, it is behaving just as if you called comp = createobject("my.protected.Component"); so I get "why" it behaves the way it does.  I do wish it would throw an error though when you use the "new" keyword.

[Jesse Shaffer]

Forgot to mention - I don't remember how ACF works in this case...

[Mike Rankin]

One of the ideas I read was about making Lucee modular.  That could go a long way towards solving the whole compatibility issue if we have some sort of dependency management tool. Imagine a part of Application.cfc (or some other configuration settings location) being used to add in the specific parts you need for your app.  You could choose to add in the legacy parts or not.  Specific libraries could be used for things like pdf generation or lucene integration.  We might need a utility that fetches the individual parts from a repository and adds them to your web-inf.

Take this idea a step further and allow the point version of lucee be defined in the setup as well.  Then, any time your app needs to fetch a piece that it needs it would draw from a version specific repository, either local if already downloaded or remote.

I'm sure something like this is not a trivial undertaking and would certainly have some fits and starts as it got off the ground.  Being able to target specific aspects of the language and a specific version of Lucee would go a long way in helping us manage all sorts of backward compatibility issues and also allow for somewhat graceful breaking of old code.

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 lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/E5FCC9B3-E5E9-48AE-BE66-114D3D886618%40corfield.org.

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

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

--

[Walter Seethaler]

As I use package accessors a lot I ran into some little issues on Railo that behave different than on ACF. I will try to report em in detail and provide TestCases.

• The example: var comp = new Component(theDependency); should throw an error like "You cannot access a package init() from..." (ACF) instead it silently returns the instance without calling the init-Method like in createObject() without the .init() call.
• Minor. A call to package methods (other than init()) from another package results in the error "method does not exist", it should say "You cannot access package method..." (ACF).
• Package methods in CFCs called from templates (RAILO-108).
• Open /foo/index.cfm in the browser. The index.cfm you can not access any package method in the package. ACF allows it, which is right in my opinion.
• If the index.cfm is included in a CFC, the access rights depend on the CFC. So the index.cfm behaves different, wheater you call it via URL or include it in a cfc.
• And I think package works different on inheritance, eg. (ACF) package methods can be called in subclasses no matter where the subclass resides. Not sure about that yet.

[Walter Seethaler]

Please see my comments below.

Am Mittwoch, 11. Februar 2015 15:44:24 UTC+1 schrieb Micha:

please see my comments between the lines

Michi

On Wed, Feb 11, 2015 at 3:15 PM, Walter Seethaler <seet...@nbsp.com> wrote:

Hi Micha, thank you very much for your reply.

we can only fix reported issue and we decide from case to case what is a bug in Railo or ACF, sometime we do "bug compatibility", ...

Yes, I will report everything and provide TestCases. I postponed it to Railo 5 because I hoped to have a better chance to get it fixed then. The new wiki may also be a good place to comprehensively document everything. And I will try to follow Adams example and try to do things instead of point the finger at it. 

We try that very hard believe me, but do not forget this is a open source project with limited resources, so issues that concern more people always come first.
Maybe you should give a example of a not solved sane incompatibility isse (take the best you have) and then i will explain why this one is not solved yet.

This was not meant as a dig at all, I realy appreciate your work. I just meant, you do not need to solve everything. I understand that there always will be some open stuff. I can provide some examples, but please don't see it in a "why this isn't fixed yet" way. You asked about the future and I just wished to concentrate on current issues first (especially when the different behaviour makes not much sense).

• RAILO-3120 completely killed my first approach to Railo. Everyone who rans into this issue and has no clue about it, will not be able to migrate anything from ACF to Lucee
  
• Some issues with package access
• Can not call a package method in a CFC from a .cfm in the same package. This was reported by Gert in ~2009 but refused. I prefer the ACF way here.

what was the ticket, we never simply refuse, so there was for sure a explanation why we refused 

RAILO-108 - I guess you followed the path of the ACF documentation, while ACF didn't. In my opinion the ACF solution is more consistent right now.  

• Call of package function init() from another package doesn't throw an error, but returns an instance without calling the the constructor.

with "constructor" you mean the body of the component?

in the end init is also only a function, that has simply a special meaning for the comonent, does acf act different in this case? 

Please see Jesse's example. ACF behaves different for new Foo() and createObject(). The new operator works correct and ACF throw an exception saying "You cannot access the package init...". Using createObject().init() is the same. But with createObject() you can still get an instance without calling the init method. The right thing for the future would be, that nobody outside of the package can instanciate a cfc with a package init method - thats exactly the reason why I use package init. I ACF you can still extend the class, implement init() and call super.init(). 

• Can not catch(any e){} a request timeout in railo, which creates different behaviour. Only in the onError on Application

i assume you speak about "request timeout", that is in my opinion clearly a bug in ACF take this example:

done=false;

do{

    try {

        doSomethingTimeConsuming();

        done=true;

    }

    catch(any e) {

       continue;

    }

}

while(!done);// try again

it is not a very goood example, but the point is, when you reach a request timeout, the request must end when you can catch the event and go on with the event, then there is something wrong! there is also a ticket about this in the Railo bugtracker ...

I followed some discussions about that topic and know your opinion about it. I agree that this is important for the server stability, but does that mean a request timout must be an unavoidable full stop without any chance to do anything programatically? I know you can use the onError to do something, but this is application wide. For instance, we have on URL for long running xml imports and have demand to programmatically stop the request on timeouts in the Import.cfc. A compromise I could image would be a special exception type (that is not part of any), like

   try {

        doSomethingTimeConsuming();

   }

   catch(any e) {

      //does not catch request timeouts

   }

   catch(RequestTimeout e) {

      //the developer takes the responsibility

   }

I am not sure how the community sees it, but ACF is more convenient here.

[Sean Corfield]

On Feb 11, 2015, at 1:19 AM, Dominic Watson <dominic...@pixl8.co.uk> wrote:
> Great points all round. I hear you Sean, particularly on the compatibility nightmare. I still disagree that having a .lucee will solve that problem though; Future versions of Lucee will want to introduce breaking features and potentially start adding feature switches - you then get feature switches for two dialects (may not happen, but it is a reasonable vision I think).

I think it will depend on the approach taken. What I _hope_ happens for changes in Lucee is what happens in most other languages:

For deprecation / removal:

* feature X deprecated in release A (and generates a warning on use — possibly with option to throw exception instead)
* feature X removed in release A+N, for some N

For change of behavior:

* feature Z flagged in release B as "will change (to do XYZ)"
* feature Z actually changed in release B+N, for some N

In other words, instead of introducing switches — which was required for ACF support in Railo — just simply evolve Lucee on its own (while leaving ACF compatibility in place in .cfm / .cfc files).

> Sean, apologies for the dirt raking. Was a lame move.

Everything is always public on the Internet. There’s always dirt to be found. Someone (in the CFML community) once threatened to blackmail me based on what they’d "discovered" about me online. I pointed out that it was public information, easily accessible by Google, and if they wanted to waste time "publishing" that shocking news, they should go right ahead :)

[Dominic Watson]

@Sean, agreed 100%. And should people really require deprecated features after such warnings (which would be a good time span), extension packs could potentially be developed. Potentially.

[Robert Munn]

Anyone can make an extension, so that is always possible. If we’re talking about legacy CFML features, the roadmap says keep that code in .cfc/.cfm. If we’re talking about future .lucee features being deprecated down the road, it sounds like the expectation should be that features could be deprecated in future versions just like in most languages. Which sounds fine.

The current AngularJS 1.x -> 2.0 feature change should be instructive. I admire them for being bold enough to admit mistakes in v 1.0, it remains to be seen whether 1.0 Angular apps are ported to 2.0, or whether they are essentially sacrificing easy migration from 1 to 2 for what they believe are significant architectural improvements. 

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/QAo0YlwmgEA/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAEYvUx%3DO8nquXyGy04xh7oZkfqiM_LwAzvZN9s0E8wqm1UE-Fg%40mail.gmail.com.

[Dominic Watson]

> If we’re talking about legacy CFML features, the roadmap says keep that code in .cfc/.cfm.

I'd hope that wasn't set in stone. We're already seeing them cut out cfform style tags from the core and moving to extensions which I think is a brilliant move. I would presume that the .lucee extension would disrespect backward compatibility for various aspects from the get go.

[Sean Corfield]

On Feb 11, 2015, at 10:05 AM, Dominic Watson <dominic...@pixl8.co.uk> wrote:
> > If we’re talking about legacy CFML features, the roadmap says keep that code in .cfc/.cfm.
> I'd hope that wasn't set in stone. We're already seeing them cut out cfform style tags from the core and moving to extensions which I think is a brilliant move.

My reading is that there would be a way to start Lucee up with the various (officially supported) CFML modules you needed in order to run "full" CFML code — or you could start it up without some of those if you don’t use them (e.g., cfform and its ilk, the ORM — for which I would be very grateful since I don’t want Hibernate lumbering around in my app’s memory since I never use the ORM!).

> I would presume that the .lucee extension would disrespect backward compatibility for various aspects from the get go.

That is also my reading (and I’m fine with that).

I would expect to be able to run World Singles .cfm / .cfc code on Lucee 5 with several CFML modules omitted to provide a leaner, faster CFML engine, and then we could write new components in .lucee files — and maybe new views too (with the stripped down tag set available there to "encourage" better separation of logic from the views).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

dev.Objective() - Developing Apps, Developing Skills, Developing Community
-- May 12-15, 2015 - Bloomington, MN - http://devobjective.com

[Michael Offner]

again my comments between the lines

Micha

On Wed, Feb 11, 2015 at 5:54 PM, Walter Seethaler <seet...@nbsp.com> wrote:

Please see my comments below.

Am Mittwoch, 11. Februar 2015 15:44:24 UTC+1 schrieb Micha:

please see my comments between the lines

Michi

On Wed, Feb 11, 2015 at 3:15 PM, Walter Seethaler <seet...@nbsp.com> wrote:

Hi Micha, thank you very much for your reply.

we can only fix reported issue and we decide from case to case what is a bug in Railo or ACF, sometime we do "bug compatibility", ...

Yes, I will report everything and provide TestCases. I postponed it to Railo 5 because I hoped to have a better chance to get it fixed then. The new wiki may also be a good place to comprehensively document everything. And I will try to follow Adams example and try to do things instead of point the finger at it. 

We try that very hard believe me, but do not forget this is a open source project with limited resources, so issues that concern more people always come first.
Maybe you should give a example of a not solved sane incompatibility isse (take the best you have) and then i will explain why this one is not solved yet.

This was not meant as a dig at all, I realy appreciate your work. I just meant, you do not need to solve everything. I understand that there always will be some open stuff. I can provide some examples, but please don't see it in a "why this isn't fixed yet" way. You asked about the future and I just wished to concentrate on current issues first (especially when the different behaviour makes not much sense).

• RAILO-3120 completely killed my first approach to Railo. Everyone who rans into this issue and has no clue about it, will not be able to migrate anything from ACF to Lucee
  
• Some issues with package access
• Can not call a package method in a CFC from a .cfm in the same package. This was reported by Gert in ~2009 but refused. I prefer the ACF way here.

what was the ticket, we never simply refuse, so there was for sure a explanation why we refused 

RAILO-108 - I guess you followed the path of the ACF documentation, while ACF didn't. In my opinion the ACF solution is more consistent right now.  

where is ACF consistent here?

They are not even consistent with their own documentation in that case, see the documentation that i pointed out in my comment, that is not from Railo that is from ACF!

"available only to the component that declares the method, components that extend the component, or any other components in the package."

the documentation clearly says that this is available only to components and not templates!

And i completely agree with that!

 

• Call of package function init() from another package doesn't throw an error, but returns an instance without calling the the constructor.

with "constructor" you mean the body of the component?

in the end init is also only a function, that has simply a special meaning for the comonent, does acf act different in this case? 

Please see Jesse's example. ACF behaves different for new Foo() and createObject(). The new operator works correct and ACF throw an exception saying "You cannot access the package init...". Using createObject().init() is the same. But with createObject() you can still get an instance without calling the init method. The right thing for the future would be, that nobody outside of the package can instanciate a cfc with a package init method - thats exactly the reason why I use package init. I ACF you can still extend the class, implement init() and call super.init(). 

• Can not catch(any e){} a request timeout in railo, which creates different behaviour. Only in the onError on Application

i assume you speak about "request timeout", that is in my opinion clearly a bug in ACF take this example:

done=false;

do{

    try {

        doSomethingTimeConsuming();

        done=true;

    }

    catch(any e) {

       continue;

    }

}

while(!done);// try again

it is not a very goood example, but the point is, when you reach a request timeout, the request must end when you can catch the event and go on with the event, then there is something wrong! there is also a ticket about this in the Railo bugtracker ...

I followed some discussions about that topic and know your opinion about it. I agree that this is important for the server stability, but does that mean a request timout must be an unavoidable full stop without any chance to do anything programatically?

yes, we reached a request timeout so the request has to end, you still can clean up in "onError" as you stated!

But the request timeout is "pulling the plug" for that request and that must work in any case.

 

I know you can use the onError to do something, but this is application wide. For instance, we have on URL for long running xml imports and have demand to programmatically stop the request on timeouts in the Import.cfc. A compromise I could image would be a special exception type (that is not part of any), like

Like i said, a request timeout is like pulling the plug, i assume you do not pull the plug on your computer when you are done working, this has the rsik to destroy open file when they are in a transition. You only pull the plug when the computer is frozen.

With running requests it is exactly the same, a request timeout always comes with the risk to destroy something, maybe the request was just writing a file that then is only halfway done or you have open streams that not get closed properly anymore ...

so you should avoid request timeouts at any coast and never ever try to deal with them.

if a request timeout occurs, you need to find out why and solve that problem. 

that is btw exactly the same as caching runtimeexcpetions in java, that smells!

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/234037b8-04b2-45f3-8350-450395fad839%40googlegroups.com.

[Michael Offner]

yes, the idea is that you can define with the startup script what you need and Lucee will make sure you have it.

Every extension defines the bundles necessary to run the extension and the extension can also define if a the bundles should be started right away or not, the jdbc drivers for example to not start the bundles right away, they get started when you use them the first time.

so even you have for example mysql extension installed, as long you not use it, it get not loaded into the memory.

You also have a control panel where you can see all extension and the state they have.

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/D38125B5-E382-4F02-B00E-23C92325C843%40corfield.org.

[Dominic Watson]

Can't wait to try this out. Going to be really great for building full deployments when the end product is that much lighter. Really exciting.

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

For more options, visit https://groups.google.com/d/optout.

[Dan Kraus]

Totally agree here.

I scratch my head when people freak about things being deprecated and/or eventually removed citing "business implications" as to why something shouldn't. Look, I get updating code has a cost. No one is denying that. But no one has a gun to anyone's head making them upgrade. If you want the latest toys, then you need to make sure that the one playing with it is "mature" enough to play with it. You'd don't give a chemistry set to a 2 year old, right?

If the cost to making changes is too high, then continue to run the version you've been and don't upgrade! How many instances of OLD CF versions are out there running right now? Someone is making business decisions that the cost of upgrading is too much compared to the value of the next/latest version. I'm not as familiar with compiled languages, but I'd imagine running old code against new versions would make it pretty clear what's going to break and what won't. So, sure, maybe there's a little blame on tooling that when you upgrade, it's not really clear what you're in for. And not that tests are the be all end all magic bullet, but if you had tests you'd have even a better idea of what's breaking after an upgrade.

[Walter Seethaler]

RAILO-108 - I guess you followed the path of the ACF documentation, while ACF didn't. In my opinion the ACF solution is more consistent right now.  

where is ACF consistent here?

They are not even consistent with their own documentation in that case, see the documentation that i pointed out in my comment, that is not from Railo that is from ACF!

"available only to the component that declares the method, components that extend the component, or any other components in the package."

the documentation clearly says that this is available only to components and not templates!

And i completely agree with that!

Hi Micha,

I would see it as a defect in the ACF documentation, replace component with cfm/cfc and its solved. If there is a good reason to break compatibility I would agree, but I don't see it.

The ACF solution is more consistent because CFC and CFM behave equal, while Lucee simply does not support package access in cfm. 

A typical use case of mine could be: /apidoc/index.cfm which is available via Browser, where I only do a:

<cfoutput>new FrontController().render();</output>

I only use public if a method is designed to be public, which is OO information hiding, eg. the APIDoc only shows public or remote Classes/Methods and hides everything that is not designed to be public and thus package help to reduce information. As Lucee supports cfc and cfm source codes, package should be supported by cfm, in my opinion.

Lg Walter

[Walter Seethaler]

Nonsense: 

<cfoutput>new FrontController().render();</output>

This:

<cfset new FrontController().render()>