Quote Originally Posted by Gleeok View Post
Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

-DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
-ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
-See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

That's my 2 cents.

[edit]
I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).
No exclusion, certainly, but how would you instruct the parser as to what to store in each buffer? It needs some way to segregate headers, and scripts, to do what DD is suggesting.

I'm not even keen on disabling it by default. I can think of three separate ways to handle adding this feature without in any way impacting the existing operation of the import directive. ( I've separately posted all three in the thread.)

Thus far, a few suers have also asked for simultaneous support, and I don't know of any reason that we couldn't simultaneously support both modes of this. This allows users to adapt to, and shift to the new paradigm, without the fear of any older scripts ever breaking from the change. It also permits the most stubborn users to fall back on the present import method. Deprecating it slowly wouldn't really work, because that's the same outcome as disabling it now, and the user will always find old scripts that they want to use, which may rely on the old operation.

There are still users, right now, downloading, and using scripts from 2007-8. ... You know how fun it is to support that nonsense.

We can't support converting existing scripts from a dev end.

Beyond that, if a user mixes and matches scripts that work with the standard 2.5 import scheme, and new scripts, say, that come out after we did something like this that are designed to use this scheme, those would not get along together if the option is a boolean setting of new/old import method.

OTOH, If you use a parser directive token, or if you used a different directive token than import, then you can shift modes on the fly... That's another compelling reason to simultaneously support both, as otherwise you will create script incompatibility due to users mixing syntax generations, which would be bad. (-Cue Harold Ramis impression).