I would like to argue two points. First that a new extension should not be created,
and second, if it is created it should not be called ".lucee".
DeprecationNew features
Breaking away from the stigma and baggage of CFML is a valid concern
There are other options available if a new extension is necessary. ".cfs" for cfscript or ".cfn" f
--
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/c5fcc7bf-c7ee-49f0-99c9-8c86855abd2d%40googlegroups.com.
|
|
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 |
What I think may muddy matters here is that there is already code to make this new extension work, it just has not yet been added to the Lucee core. So there is already personal investment in this for those involved. I for one would urge Lucee to be cautious of moving into core too early.
--
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/0fdd8736-a6d8-4141-922e-3a7dac73bce6%40googlegroups.com.
I think the issue for me is less how this sort of thing is handled - it's all doable as you say - but I am hesitant about the divergence from Adobe all within the same language.
Breaking away from the stigma and baggage of CFML is a valid concernI think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.
There are other options available if a new extension is necessary. ".cfs" for cfscript or ".cfn" fWell: neither of those actually are available though:
What I'd like to see is a 5.0.0 release without the dialect, there's plenty in 5 to get excited about already without that. Then some more solid information about what is in the new dialect and how it will work before adding it in 5.1 (or not at all), giving time for community input which seems to have been Lucee's mission statement from the get go.
--
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/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.
This dialect should first be released as an extension to Lucee in my opinion (if that is indeed possible). It can then be safely evaluated without the slightest furore.
Here’s my take on it.
The extension .lucee is questionable, but let’s not forget that the extension cfm contains the name ColdFusion in it as well.
And I don’t agree to adding settings to the Application.cfc, since then everything will then depend on switches which makes the code slower in the end and harder to debug. These settings could come from anywhere. And partly they are compiler settings which CAN NOT be made in an Application.cfc.
Whether the name is ok or not, doesn’t really matter. Adobe will, no matter what, do their own thing – if they follow Lucee in the first place – even if we could call it somewhat different. It has happened several times in the past already.
The only thing I personally have against the name .lucee is that it is too verbose and that it is the name of the product.
Sincerely
Gert Franz
RASIA GmbH
Spittelgasse 7
5103 Moeriken-Wildegg
Email: ge...@rasia.ch
Skype: gert.franz
Phone Switzerland: +41 76 5680 231
--
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/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.
And I hasten to add, that I would prefer it being already in Lucee 5.0.0 as beta or even alpha too… Since then people can get familiar with it and we can improve it if there are lots of downsides etc.
Sincerely
Gert Franz
RASIA GmbH
Spittelgasse 7
5103 Moeriken-Wildegg
Email: ge...@rasia.ch
Skype: gert.franz
Phone Switzerland: +41 76 5680 231
Von: lu...@googlegroups.com [mailto:lu...@googlegroups.com] Im Auftrag von Ryan Guill
Gesendet: Dienstag, 10. März 2015 13:48
An: lu...@googlegroups.com
Betreff: Re: [Lucee] Re: arguments against .lucee extension
What I'd like to see is a 5.0.0 release without the dialect, there's plenty in 5 to get excited about already without that. Then some more solid information about what is in the new dialect and how it will work before adding it in 5.1 (or not at all), giving time for community input which seems to have been Lucee's mission statement from the get go.
I tend to disagree - if we can come to a conclusion about a different way to gate the new features and breaking changes id like to see at least an initial implementation of it if it is ready in the 5.0 betas - that gives us something to level against and start talking about concrete implementations instead of the abstract ".lucee extensions could work this way" that we are doing now. If the features aren't ready for prime time they could be left out of the released version.
I have a few different proposals I'd like to make, but i'm waiting for 5.0 to see what is in there and how this new dialect will be implemented to know how best to proceed.
--
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/e146c5ac-c735-427d-88d3-28edd87a85ab%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/01fc01d05b32%2460efe010%2422cfa030%24%40rasia.ch.
That said, what I *don’t* see us spending any time on discussing is concurrency and async behavior. I’m getting the sense that we’re heading down the same sync-prioritized model of processing, which, IMHO, doesn’t distinguish the capabilities of the language from anything that is out there. Scala is moving in that direction (http://docs.scala-lang.org/sips/pending/async.html ) even more and their Futures and Promises are really interesting implementations, even if I’m not a fan of their syntax.
--
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/dd86c1ff-eb2b-4cfd-a7e4-fd7c57524680%40googlegroups.com.
One item not mentioned yet, which I would consider an argument for creating a separate extension would be the ability for us to intermingle .cfm and .lucee (or whatever) files within an application. Allowing me for example to take advantage of features like full null support or case-sensitive struct keys in my own code, while still utilizing 3rd party code (ColdBox for example).
One item not mentioned yet, which I would consider an argument for creating a separate extension would be the ability for us to intermingle .cfm and .lucee (or whatever) files within an application. Allowing me for example to take advantage of features like full null support or case-sensitive struct keys in my own code, while still utilizing 3rd party code (ColdBox for example).A pragma could be used on a per file, or even a per function basis if that is the way it was implemented. I agree though, we need a way to specify this on at least a per file level, but we have options other than extensions to do so.
And I don’t agree to adding settings to the Application.cfc, since then everything will then depend on switches which makes the code slower in the end and harder to debug. These settings could come from anywhere. And partly they are compiler settings which CAN NOT be made in an Application.cfc.
But, really, wouldn't the file extension approach be a bit cleaner than the pragma approach? This sort of differentiation is kinda what file extensions are for after all? Why reinvent the wheel, and using an octagon as a template?
--
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/f835c7cd-4a23-4bf4-9abb-dc8e6902daf9%40googlegroups.com.
... let’s not forget that the extension cfm contains the name ColdFusion in it as well ...
Well said, Ryan. I am torn on the issue also, mostly for the point you made about the market being too saturated with JVM languages. However, I keep coming back to the thought of how far can you go, really, in defining a new dialect before it becomes a new language? And shouldn't a new language have its own extension?
I started using the word "dialect" when discussing .lucee (as opposed to .cfm / .cfc) stuff because ppl were getting uppity about being "left behind" and CFML being marginalised.But in reality, if whatever this .lucee concept is isn't basically a new language, it'll be a waste of everyone's time. IMO. We don't need CFML-and-a-half. No-one does. But if the Lucee Association wants to deliver both a CFML solution and a [new language of their invention because they think they can make a go of that, good on them]. I'll help & support them. If it's CFML-and-a-half... I'm out.There's no prob with it being inspired by CFML (as you say, Jesse: C -> C++, or C++ -> C# etc), but it actually has to be something in and of itself. Not just a coupla incompatible things bolted onto CFML. That would bite.
I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.
This is why its important to get a roadmap and clear direction from lucee about what we are even talking about here. I don't like how this sounds as an ultimatum - i'm just some guy on the internet, I don't necessarily want lucee to change to fit me, I want lucee to make its intentions clear so I can make decisions - but I have pretty much the exact opposite of your opinion Adam.
If this new dialect is somethings radically new i'm not interested. There are far too many other and better options out there to invest in. And I assert that a new language isn't going to appeal to the one opportunity for growth that exists for lucee today - existing CFML devs.
I feel like i'm missing some nuance to your position though Adam. Earlier in your thread you said:I think Lucee needs to pull its head in on this one. Whilst CFML has some bad press, at least it has some press (*). I don't think Lucee has the resources (or, to be brutally honest, the ability) to market a new language contender in such a way as the new project will me more successful than simply marketing it as a better CFML engine than Mother Ship's. Perhaps with the new dialect they should be marketing it as CFML++ (not actually in those terms literally), rather than starting from scratch.I have plenty of opinions, plenty of which seem to be at odds with the majority here, and thats great - im just part of some groups personally and professionally that are trying to make long term decisions - so whatever the decisions are we would just like to know what to expect.
So they ought to instead focus on delivering a performant, low-footprint CFML engine.
CFML-and-a-half
--
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/097262a4-ec38-4f09-ba3e-cbafb4b21497%40googlegroups.com.
Which is fine. You don't, btw, have to apologise for being "just some person". We all are. All any of us are doing is expressing an opinion. This is why mailing lists exist.
Cool. You seem to be frightened to not agree with people, Ryan. It's fine. I think hyour opinions are well-formed and worth everyone reading and giving consideration to. I can do all this whilst not actually necessarily agreeing with them. So oght everyone else be able to, I reckon (I have no reason to doubt this).
And, in case this somehow got lost in translation... all of this is solely my opinion and I have no expectation for everyone (or even anyone) to agree with me, or to action anything, or to do anything with this info at all other than to note "oh, OK, that's Cameron's opinion". I also reserve the right to adjust my opinion in part or entirely as more information comes to hand. It's bloody stupid I feel I need to say that, btw.
I'm just not personally comfortable with my efforts being perceived as my saying "Do things my way or i'm taking my toys and going home" which is the way I feel like some of this comes across.
And, in case this somehow got lost in translation... all of this is solely my opinion and I have no expectation for everyone (or even anyone) to agree with me, or to action anything, or to do anything with this info at all other than to note "oh, OK, that's Cameron's opinion". I also reserve the right to adjust my opinion in part or entirely as more information comes to hand. It's bloody stupid I feel I need to say that, btw.Would you say that is your 2 cents then? ;)
Adam, what is the difference between:So they ought to instead focus on delivering a performant, low-footprint CFML engine.andCFML-and-a-halfAs you say the Lucee team should do the first but not the second, but to me they sound like one and the same thing!!!
--
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/2ab29c20-929d-42e8-a640-8cef9ae61db8%40googlegroups.com.
I would like to argue two points. First that a new extension should not be created, and second, if it is created it should not be called ".lucee".I have just read through the group and all of the arguments that I could find for a new extension to separate the way code is processed are because of the following needs: deprecation of existing code features and idioms, addition of new features and idioms that would not be backwards compatible, and a way to break away from the stigma of CFML.Deprecation can happen inside of the existing cfml files without the need for a new extension. Deprecation of tags, functions or idioms can be handled at the engine level in many ways - the easiest I can see would be a pragma rule in Application.cfc that sets a language level. Something similiar to "use strict" in javascript. Any CFML engine (such as ACF) that does not implement these pragmas can just ignore it. Any use of deprecated functionality or idioms can start throwing errors if the pragma is used. If necessary, the pragmas could have levels of enforcement, for instance to throw a warning into a log file instead of an exception at a certain level.New features that are not backward compatible could be handled with the same sort of pragma rule. The way var works in a block vs function scoping for instance - at a certain pragma level it can have the new implementation.Again, a pragma is just one way - using "this." settings is another, or a specific file that would sit alongside Application.cfc. I'm sure there are others we could come up with.Breaking away from the stigma and baggage of CFML is a valid concern, but I would like to argue that the likelihood of lucee appealing to a wider audience outside of the current CFML community is low. There are just too many options for other languages on the JVM alone, languages that have been designed from the ground up with a consistent vision and with modern features. Also, unless the intention for "lucee.next" is to start an entirely new language from scratch, you are still going to be taking at least some of CFML's baggage with you regardless. Calling it a new name in hopes to trick some newcomer that lucee isn't the CFML they've heard about isn't going to work for very long. IMO the best way to appeal to a broader demographic is to expand the interoperability with other languages - both using those languages inside of CFML and using CFML inside of other languages. See the work Sean is doing with cfmljure. Using CFML as a templating language from groovy would have a lot of appeal I believe. Being able to use JS via Nashorn in lucee would be amazing. I know there has been some talk about JSR-223 in the past which is a step in the right direction - the ability to use those other languages inside of CFML would be just a nice.That said, if you find that it is necessary to have a new extension, please reconsider using ".lucee" specifically. Firstly it makes compatible forks and language implementations harder if not impossible. Consider if this idea had come up a few years ago and ".railo" had been used. When it was forked and became Lucee we would have been in the same boat that we have been in with the .ra files, only it would be a much worse situation. I'm sure its hard to consider that Lucee might be forked by the same crew again, but surely it cannot be ruled out completely? The same would also apply to anyone else wanting to come along and fork lucee into a compatible engine.It also means that Adobe cannot / will not be able to implement the advances made. No matter what your opinion of Adobe and their handling of the language, they have implemented features initially developed in Railo and there is no reason to believe they wouldn't continue to do so. And even if you think that Lucee should forge its own path away from ACF, that doesn't mean that we should preclude them from being able to take up these features, and make a compatible engine going forward. Using ".lucee" means that at best they will implement the same features with a different extension. This will also make things harder on library authors hoping to support multiple engines, something that is at least possible today. Using ".lucee" will ultimately lead to a lack of choices for developers. We already have a documentation problem in all engines. In the past week alone I have used the ACF documentation for lucee code many times. I have used railo documentation in the past for ACF code because of holes they have. Ultimately if you at least consider that the CFML history is not something that we will be able to shake completely, we are a stronger community together than we are individually. Of course Adobe might not pick up any of the advances made here - but I just don't see any good reason for making it harder for them to do so.There are other options available if a new extension is necessary. ".cfs" for cfscript or ".cfn" for CF-next. I'm certain that if necessary there are other - more inclusive - options available. In an ideal world we could get to a broader language specification and the file extension could reflect the version of that language, but of course I don't believe that to happen anytime soon.
--
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/a35d3439-828a-48cd-bc9f-3581ecc88187%40googlegroups.com.
So the idea of this extension is not to do a new language, it is to have a different way to control this existing settings on template level.so it is all about controlling the runtime and compiler behaviour on template level.
--
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/f27b38e7-fcba-4b2d-9d92-7d1038e37e11%40googlegroups.com.
so it is all about controlling the runtime and compiler behaviour on template level.
I forget to say that this would also include a rethinking of all functions and tags ...
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0cde0e0f-e733-4bf9-a411-64efc3595e9e%40googlegroups.com.
I was never speaking about a new language, I was always speaking about a dialect on top of the engine.The current idea is as follows.We review all possible runtime and compiler settings and we define for every one the default behavior for this dialect, this includes of course also settings new to lucee 5 like "handle unquoted tag attributes as variable|string".We review the core tag and function library, for example we remove the function "dateFormat" and rename "lsDateFormat" to "dateFormat".The libraries also define the prefix of tags (cf) and if not existing tags are ignored or not. So we can also control this behavior.All I was taking about is covered by this...
Is starting a new file extension so as to be able to obsolete/tweak some functionality something you see other languages doing?
Either LAS feels it has the capability to move CFML forward and evolve the language, or it wants to remain an ACF compatible language.Which will it be ?
--
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/77e452b4-3258-4719-835c-11c962c61c31%40googlegroups.com.
I think you need to polish your reading & comprehension skills, Andrew
--
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/f75a03d9-8a8a-43b4-8db6-160e51a68ad6%40googlegroups.com.