On Sun, 27 Oct 2019 at 23:56, Mike Schinkel <m...@newclarity.net> wrote:
> > So we'd probably need some built-in definition of a "package", which could > be analysed and compiled as one unit, and didn't rely on any run-time > loading. > > > That idea of a "package" came up during a debate on this list at least > once, a few months ago, and I think it makes a lot of sense. And what I > proposed effectively implies that namespaces would be treated like packages > from the perspective of the compiler. > > But then again a new package concept might be needed in addition to > namespaces, I am not certain either way. > > Current tools tend to actually work on a directory level, because you don't actually know what namespaces are involved until after you've loaded it, and a file can include code for two completely separate namespaces. My thinking was that a package would pre-define the full list of files that define it, with no auto-loader, and no conditional definitions evaluated at run-time. As Benjamin points out, this is closely related to preloading. > Unlike P++, Editions, or Strict Mode, this would undeniably define that > the deprecated features were "the wrong way". > > > I am not sure I cam agree that it would define them as the "wrong way." > > > The way I would see it is there would be a "strict way" and an "unstrict > way." If you prefer the simplicity of low strictness and do not need > more/better performance or the benefits of type-safety that are needed for > building large applications, then the "right way" would still be the > "unstrict way." > > And what if you want simplicity *and* performance? Most of the things people want to make strict about the language don't make it faster, so if we limited "pre-compiled mode" to be strict, we'd be making a deliberate choice to group objectively good things (fast vs slow) with subjective preferences (strict vs simple). That pretty clearly marks strict mode as "the better way". > If the engine had to support the feature anyway, > > > I think we are talking two engines; one for compiling and another for > interpreting. They could probably share a lot of code, but I would think > it would still need to be two different engines. > > That sounds like the worst kind of fork: two different engines, running two different dialects of the language. At that point, you might as well just switch to Hack. Note that this was exactly what "P++" was intended to avoid - the two dialects would exist in the same engine, and get the same performance and security enhancements. > I'm not sure what the advantage would be of tying it to "compiled vs > non-compiled", rather than opting in via a declare() statement or package > config. > > The advantage would be two-fold: > > 1. Backward compatibility > > 2. Allowing PHP to continue to meet the needs of new/less-skilled > programmers and/or people who want a more productive language for smaller > projects that do not need or want all the enterprisey type-safe features. > > Both of these are reasons to have some sort of "strict mode", but not for tying it to some other feature. Regards, -- Rowan Tommins [IMSoP]
