Lucee6 challenges, cont'ed Getting another error on a static property with 6, over and above the one we were getting on 5.3.10 Conclusion: hard pass. (And, sorry, replicating these static issues take ages to extract a repro case, and I just... can't be arsed, sorry) This time it's not finding a static variable that is unconditionally set in a CFC. It's there. It's always there. Just... Lucee is losing the plot somehow. I have this sort of thing:

<cfcomponent extends="Parent">

	<cfscript>
		static {
			final static.MY_CONST = 3
		}
	</cfscript>
	<!--- ... etc, rest of file --->
</cfcomponent>

And Lucee is going:

Error executing bundle - test.path.to.MyTest message: The static member [MY_CONST] does not exist in the Component [<http://path.to.My|path.to.My>]

It's simply not true. It's there. It's always there. I recommend you guys add a lot of test cases around static support.

it's a community open source project, how about contributing some tests?

Indeed re tests, the problem is I'm sure you have superficial tests (I don't use that term in a negative way), and whilst I could identify like usage test cases - from my own CFML - static is such a low level concept that I think the testing needs to be done at a lower architectural level than is be capable of understanding. The sort of tests that should really be written in parallel with development. Is there anyone from Lucee @ Into the Box? Happy to discuss with them, and would be easier than typing stuff in a chat on a phone.

most of these static problems you've found come from inheritance or wierdo shit like the includes, we don't need low level tests, just more extended tests a lot of what @pothys-mitrahsoft and I do for the Lucee project/team is triage and then knocking out ( i initially wrote knocking up) test cases for the various issues prior to @micha diving in and solving them. some of those takes hours to figure out

Sure yeah once a case is identified and a repro created (which took me the best part of a day, for that report one), it's probably easy to knock together a test case that's "it should return x". I was rather more meaning that done of this stuff is probably more predictable if one is looking at the "seams" in the underlying code (eg maybe some coffee needed to be written to deal with statics in included files or something. I'm guessing). Also - and this horse had likely bolted now - it's always easier to identify test cases when writing the code. Not afterwards.

we use often use _internalRequest with lucee to run tests as mini apps to test stuff which otherwise break, syntax etc

Struggling to repro this in an isolated way. One thing I did note is that if I touch the file (eg: adding a semi-colon or something), then re-run our tests, it gets past this code, and craps out on the next case of same syntax usage. Then if I touch that file, rerun: back to the first one crapping out. This means nothing to me ("... Oh Vienna"), but maybe it might give the Lucee devs something to look at... what happens differently when a file is touched? Also if I just run the one test with the affected code in it: it then passes. All the time, Go back to running all the tests: breaks. Is it maybe some confusion cropping up when loading static stuff from multiple different CFCs in different package paths? I have not tried this yet...