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.