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
--
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.
--
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.
|
|
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 |
We'd prefer not to rewrite it, and so would they, so we're all Chicken Littles, not Real Programmers(tm). Sheesh.
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.
--
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwJsvCJLWViW1puBjQx-SedaTp-UOdN7A4DVm22%3DenLCA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxkwcPxDPCHR9oW7ANCOEo9Bd2fbtZL%2BPsRJrZaVNaibKA%40mail.gmail.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwtyyQyLAf10WD%2BV3p-bn3FmXiO2PS6FtUQ%3D8-LBpVmvg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B54D9975-36E0-4E76-893D-E88C126E267C%40gmail.com.
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 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.
> 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
Having multiple dialects *is* a concern that needs to talked through carefully.
> 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/CAEYvUxnUpnu%2B%3DvCxKwGiYmPruWrFcH0Z41N15qx%2Bx-UT5%2BNASQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/28C83238-4CAE-49D8-B4AD-45B7E2F48106%40gmail.com.
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxkACK_25V547LQFOWfOb2-Vgf1m512wOAxqbs45_extiA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxe0en-_cHsh_yTR8pZK0ceOy1yRWq_dGRq9TbNJ6S-5A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxkEAJAe6Aj%2BvrskBNyB9R0OxRLVhase2%2Bd_fuopFbu11g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxro-FTQFZQZzAB4MHa62A4s_nRxE3WGJw55t2zk5GW_g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUx%3DeiwSHtX2B%3DDF9F7TZHJPUTKgMJJhrZAyAtTOjobUcCw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBw-ZsM5FYkkW8bz9jC2vHMjLz2DW_0X0-cCMNXeGNb0zw%40mail.gmail.com.
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", ...
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/423598ef-9b07-42f8-b489-bf6bbd6c08bc%40googlegroups.com.
- 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?
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;
}
}
component {
public Component function getComponent() {
var comp = new Component(); // blows up - missing required argument.
var comp = new Component(theDependency);
return comp;
}
}
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;
}
}
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 KingdomT: +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.
--
please see my comments between the linesMichiOn 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 againit 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 ...
--
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.
Please see my comments below.
Am Mittwoch, 11. Februar 2015 15:44:24 UTC+1 schrieb Micha:please see my comments between the linesMichiOn 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 refusedRAILO-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 againit 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
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/234037b8-04b2-45f3-8350-450395fad839%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/D38125B5-E382-4F02-B00E-23C92325C843%40corfield.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxj96BPRYi4YtJ9kxweXG8Bc9YAE6oCHja5yTz9D2zQOQ%40mail.gmail.com.
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!
<cfoutput>new FrontController().render();</output>
<cfoutput>new FrontController().render();</output>
<cfset new FrontController().render()>