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]
That’s my sense too. For all my code, files in the controllers or model trees are all classes, and files in the views, layouts, or includes trees are all templates.
I think the CFML approach – of separate extensions for components and templates – is just a poor workaround for lack of organization by programmers.
Given the discussions around being able to declare classes inline – thus opening up the possibility of multiple classes in a file, as well as declaring classes locally in templates – I think that whole separation based on file extension just makes no sense at all. [I’m not much in favor of multiple classes per file but I’m seeing that creep into other modern programming languages and the sky hasn’t fallen yet so…]
That’s my point - you should be able to determine what it is based on surroundings, or even naming conventions, but you cannot absolutely guarantee what is in a file, if the extensions are the same.
That discussion indicates that inline class definitions are not available outside the template.
Lots of other languages seem to manage just fine with a single extension, despite some files containing classes and some containing “just code” (and some containing a mix of both).
Indeed, but that’s not relevant to my point: the ability to have inline classes means that any file could contain both classes and “just code”, so a separate extension for code that contains classes doesn’t really make sense in that context.