> Instead of introducing a declare option or special open tag, how about > another "include" construct, that only allows side-effect free (apart > from class loading) operations? > > e.g. "require_noexec 'foobar.php'" > > Regards, Niklas >
Hi Niklas, That's indeed a very interesting alternative! I've given it some thought in regards in the context of no side-effects and I really like the idea as it sounds easier to implement. With an alternative as such, I see one major roadblock, perhaps it can be solved? These days I personally hardly ever write require/include statements, composer does this for me with autoloading. For composer it would probably mean an "all or nothing" when it comes to picking the keyword to "require" or "require without side-effects". This makes it hard, if not impossible, to trigger deprecations from deprecated interfaces, unless you use something too hook into autoloading and check if there were `@deprecated` annotations on the class, interface, etc. This means that a feature that worked by default, would be broken and risk potential issues when upgrading. Following this strategy, it would put the responsibility of loading the files at the developer that consumes the (public) API, rather than the developer that (public) API. I believe the public API should define whether or not it can, or must be, be loaded without side effects without any worries for the developer consuming that public API. This is why I initially tried to come up with a strategy that allows you to define it in the file (one way or another). Note that my example with composer is tailored around my specific use-case and that a new function, keyword or statement might be more suitable for developers that explicitly load their code without autoloading. Regards, Lynn van der Berg
