Is this not an artefact of poorly organised applications, where classes aren’t in clear packages, and browseable files aren’t in the www or public dir, and general non-browseable script files in… erm… well we put them in /bin but that’s not right IMO. But you get my drift.
This is a real concern for legacy PHP applications, but would it be for .lucee applications, all of which will intrinsically be new?
FWIW, I rather like MyThing.class.php and someView.html.twig and that sort of thing. I’m pretty sure PSR-4 autoloading doesn’t like the .class.php extension though.
This schema wouldn’t work with .lucee as it stands, no: because classes don’t have names discrete from the file name. Perhaps that is something that needs addressing though? I’ve never liked that level of coupling.
If (and I very much mean “if” here) we were to make a distinsguishment (is that a word?) between classes and general scripts, does .lc and .lucee achieve this? I am not sure it does. Perhaps .lc and .ls would though? I say this because “Lucee” is the name of the whole project (and at the very least the whole language if we forget about the CFML side of things for the purposes of this discussion), so “.lucee” is a bit too all-encompassing to be used for differentiation, maybe?
And could it be said that there are three types of files, at least notionally? Classes, scripts and views? I suppose there are only two syntactical differences though: classes and… free-for-all-code. So I might be over-organising things in my head [grin]
–
Adam