Re: [PHP-DEV] [RFC] Attributes v2
> > The RFC is at https://wiki.php.net/rfc/attributes_v2 > > > > A working patch is at https://github.com/beberlei/php-src/pull/2 though > > work around the details is still necessary. > > > > The RFC contains a section with common criticism and objections to > > attributes, and I hope to have collected and responded to a good amount > > already from previous discussions. > > Why do decorator names refer to classes, rather than any callable as in python? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add viable long running execution model to php 8
On Wed, 29 Jan 2020, 7:42 pm Peter Bowyer, wrote: > On Tue, 28 Jan 2020 at 17:12, Rowan Tommins > wrote: > > > I'd just like to point out that those two things are orthogonal: the fact > > that Swoole is distributed as an extension is not the reason it's > > incompatible with your existing code, and building a similar > implementation > > into PHP under a different name wouldn't make the migration any easier. > > > > You're absolutely right. The difference I'm thinking is that if there is > built-in support in the language, frameworks will embrace it. At the moment > I'd need to make my own fork to add compatibility with Swoole et al (or use > one of the experimental but unsupported forks out there), which isn't > attractive. > This was why i raised the issue. If it is covered in the core more people are going to use it. It would be espesially good if it could be supported within the shared hosting settings where php is commonly used. As swoole etc have allready done good work, would it make sense to adopt one of these as official? >
Re: [PHP-DEV] Add viable long running execution model to php 8
> > I'm not sure that would work well for Web Sockets, because it still > relies on the traditional request-response cycle, but I've never really > used them, so don't know what kind of architectural patterns make sense for > them. > > Considering the Swoole PHP extension (https://www.swoole.co.uk) the > long-running process would take the place of its functionality and new apis > to communicate with a long running process could allow communication that > resulted in regular requests being able to send messages via the web socket > server, and read queued messages from the web socket server. > > You won't be able to process notifications to clients via > request-response, but where that is needed it would be done by the > long-running process. So the request-response might "register" a > notification listener to the long-running process, for example. > A web socket is just a way of re-using the tcp connection from a http request and holding it open for bidirectional communication. Due to this you can make assumptions about performance charicteristics from other long running socket server approaches. >From what i understand, the main problem with using fork or a thread pool for handling sockets syncroniously is overhead caused by the switching between userspace and os kernel space, as well as high memory overhead. Using fork would have the same behaviour as something like apache prefork. Handling a long running connection entails a process per connection, which could mean an awful lot of processes. Pretty much everything seems to be switching to async io based on some event loop, as it allows a single process to handle requests from a large number of connections, and long tunning but sparsely used connections don't require holding processes open that are mostly doing nothing. Based on what i see from the direction things are going in other languages, just 'getting with the times' and switching to an event based model probably makes the most sense. Anyway, i think PHP really needs to be able to handle web sockets in core.
Re: [PHP-DEV] Add viable long running execution model to php 8
Hi Rowan
> Could you share some more thoughts on what you are thinking of here? I'm
> guessing you're thinking along the lines of an "event-based" system,
> where each request is a function call, rather than a whole script
> invocation?
Yes that is what I was thinking, for example there is a userspace implementation
'Swoole' that works in the following way, ReactPHP is similar although I won't
include that example as well.
-
on("start", function ($server) {
echo "Swoole http server is started at http://127.0.0.1:9501\n;;
});
$http->on("request", function ($request, $response) {
$response->header("Content-Type", "text/plain");
$response->end("Hello World\n");
});
$http->start();
-
> PHP is sometimes described as having a "shared nothing" architecture -
> everything is wiped out at the end of each requests - so perhaps one way
> to look at this is to propose a "shared something" version.
>
> The first question is _what_ we want to share. We already have sharing
> of compiled code, with OpCache bundled since 5.5, and the pre-loading
> feature in 7.4 could make autoloading redundant for many applications.
> What we can't share natively is any data structures, resources like
> database connections, or other global state like set_error_handler.
The concept of a shared nothing architecture is a great basis for designing
scaleable systems, and it does reduce/eliminate some types of bugs. However it
may be better to approach this at a conceptual level instead of enforcing it
with the design of the language.
In my mind right now, everything should be shareable within a single process,
as one could do in the Swoole example above, nothing stopping you defining a
global in that script that could cache data in-process.
NodeJS, Python (wsgi) and others work fine using this model and allow sharing
of data within the same process. Trying to limit it to only some types of things
would be more complex as each type of thing would end up having a different
programmatic interface.
Changing the execution model would also allow PHP to natively handle
web-sockets natively without 3rd party implementations, which are all based
around long running processes. I got the following from the Swoole docs:
-
on('open', function($server, $req) {
echo "connection open: {$req->fd}\n";
});
$server->on('message', function($server, $frame) {
echo "received message: {$frame->data}\n";
$server->push($frame->fd, json_encode(["hello", "world"]));
});
$server->on('close', function($server, $fd) {
echo "connection close: {$fd}\n";
});
$server->start();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Add viable long running execution model to php 8
PHP is pretty unusual in comparison to most web platforms nowadays as it runs each request in an isolated process. Web development in other languages is instead based around a long lived set of processes, which serve multiple requests. That model has advantages in that it is very easy to cache data in process, and should be simpler in theory to get good performance as all code can be loaded into memory once during startup. Autoloading therefore goes away. There are userland implementations like PHP-PM, but I think it good to have an official way of running code in this way in php 8.
Re: [PHP-DEV] Typed array properties V2
> So essentially we are talking about generics. I think it's the best time to > do so... Maybe our wishes come true soon? ;) > Given that the general trend is towards making PHP more statically typed and very java/C# like, why not just ditch PHP and use one of the aforementioned languages? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
With regards to allowing AST introspection, john blow just posted a video on JAI which slows why it is useful. Around 11 mins into the following video he introduces a few lines into the metaprogram (the thing that interacts with the AST) which essentially 'queries' the code and reports all occurrences of pointer math. I can think of many uses for being able to query a program's source like this. https://www.youtube.com/watch?v=0mQbBayzDPI On Wed, 15 Jan 2020 at 01:57, Mike Schinkel wrote: > > > On Jan 14, 2020, at 7:50 PM, Larry Garfield wrote: > > I think you're still missing my point here. AST manipulation during > > preload would exist to manipulate code that would be run *later*. That's > > the point. Sure, the code in the run_once/preload/whatever block would be > > written to run in that context, but its entire point is, presumably, to > > improve the running of the *rest* of the code later. > > And respectfully, I think I am not missing your point but that possibly you > are misunderstand what I was proposing. > > I was not proposing *any* AST manipulation, at least not for what I was > defining as "Userland Preloading." Unless you define AST manipulation as > using PHP to generate code to insert literals into OpCode, but if so I think > that would be disingenuous.) > > If you remember I said this thread had gotten to the point I am seeing these > separate issues that should probably be three separate threads, which I will > repeat here: > > 1. Userland preloading > 2. Userland loadable extensions > 3. Projection API and related > > None of the above manipulate the AST directly, although #3 would do so > indirectly. (There is an argument to be made that we could split #3 into > higher level APIs and lower level AST manipulation which, IMO, should be two > different debates, for a total of at least 4 different debates here.) > > So again, when I am proposing userland preloading I am *not* as part of that > proposal proposing AST manipulation, although I believe Robert Hickman may > have been and maybe I should start a different thread? > > That is why I find it hard to believe that PHP would generate code that would > fail when PHP runs that code. > > > That... is a completely different thing, yes, that has nothing to do with > > the PHP 7.4 feature called preloading. Which would mean we've been talking > > about two different things this whole damned time. *sigh* > > Yes. And I will take the blame for that. It did not occur to me until > Robert mentioned to me that it was confusing. > > > No, the whole point of the FFI extension is that a user-land developer can > > load a .so file into PHP directly; basically doing the lib->PHP glue code > > in PHP rather than in C. It does require the FFI extension itself to be > > enabled, and to do safely requires using the preloader, which does mean > > setting an ini setting. > > Interesting. So then maybe what I an asking for is to bundle FFI into core > so that it is available everywhere. > > > Not all hosts support that. The one I work for does, which is why I've > > been playing with it lately to document it all for our customers. :-) But > > the fact that such advanced features are not universally available is... > > exactly why I am extremely cautious about having functionality that results > > in subtle behavioral differences between those environments where it's > > available and those where it's not. > > Another interesting option would be to enable loading and running of > WebAssembly in core. Do you have a position on that? > > > The existing preload logic has no impact on behavior other than skipping > > the autoloader. Any behavioral change is limited to those oddball > > libraries that do black magic during the autoloader, which are already well > > off the beaten path. That makes it a "safe" optimization. > > So basically, I think this is what I have been asking for, but userland > accessible. > > I would envision that if it modified any environment, such as setting a > preloaded or error levels etc. then all that environment would reset during > normal execution. > > > My underlying point, and then I will bow out of this thread as I am tired > > of repeating myself, is that I am all for enabling more "safe" > > optimizations, even letting userland developers build them, but we need to > > be extremely careful about them being "safe" and not "a time bomb that will > > introduce subtle behavioral differences between different run modes that a > > developer is not expecting,thus slowly creating libraries that
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
> > Hi folks, i think that we are getting a little confused here due to using the term 'preloading' for different things. As i have noted previously, my initial proposal of compile time execution would not depend on php's preloading feature, but could work, with opcache in the usual sense, or even without opcache, with a probably notable performance impact. The proposal is really to split the execution flow into two stages, one that happens once during compilation, and one that happens n times during subsiquent requests. This actually has no dependency on preloading and is orthoganal to it. I don't see any real issue with allowing ast manipulation and compile time metaprogramming myself, as it would just be making it easier to do things that people are already doing with preprosessors of various kinds. I tend towards the attitude john blow has with JAI: giving tools to experianced developers, and not creating ristrictions for novices, who will always be able to find ways of breaking something. Metaprogramming could be a foot gun, yet it could also be really useful if someone knows what they are doing. I have been talking about ideas with Mike off-list, and we both think that if a low-level API were exposed to allow this, most of the functionality could be implemented in PHP code. By making a low level api, it would probably put off biginners from using it directly, and they could use higher level API's providing more restricted functionality. Python has the ability to modify its own ast in python code, and i have never personally seen any horror stories of biginners getting into trouble with it. The API is low level and requires a lot of internal knowlage to use. With regards to not being able to use custom php extensions without being able to edit the server configuration. In my opinion the best approach is to get away from running the language in a 'traditional' virtual hosting setup. I have no desire to write code that would need to run in such a limiting environment. I appoligise for any spelling errors as I am dsylexic, don't have access to my desktop right now, and the spell checker on android is awful.
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
I would say that my proposal is more about compile-time meta programming, and thus would not actually depend on preloading. It could also be ran during page requests and would be cached by opcache in the same way. However running it in that way could make the initial request before the opcodes are cached much slower. Hence why combining it with preloading would be advantageous. On Mon, 13 Jan 2020 at 00:45, Mike Schinkel wrote: > > > On Jan 12, 2020, at 1:57 PM, Larry Garfield wrote: > > > > Most notably, *not all code will be run in a preload context*. > > Can you give some concrete examples here? > > > Language features that only sometimes work scare me greatly. > > Do you have some examples of language features, from PHP or another > language, that only work sometimes and that are known to be problematic. and > why they are problematic? > > > Doing one-time optimizations in preload that make the code faster, that's > > great. > > Though I think this proposal may need to be fine-tuned, I can envision many > frameworks and CMSes written in PHP could improve both performance, > robustness and user-experience using preloading. > > One of the ways most useful would be to run code that ensures the > framework/CMS APIs are being used correctly. If this code is included today > in frameworks and CMSes, it must run for every page load (on the web) when it > could be run once when OpCode is generated. This could potentially improve > performance significantly, depending on how much checking it implemented. > > It could also improve performance of building data-driven structures at > runtime. I know that in the past I have had data driven structures that were > definitely very time-consuming on each page load. The WordPress admin does > tons of it. > > > Preload optimizations that make the code behave differently, that's > > extremely dangerous. > > Can you give some concrete examples where you fear this could happen? > > > "I changed one character and now I have to restart my webserver to see if > > it did anything" is a bad place for PHP to be. > > As I envision it preloaded code of this nature would not be handled on server > reboot, but when the files have had their time stamps updated. If I am not > mistaken, PHP already does this (but I could be mistaken as I don't have > expertise in PHP OpCodes.) > > Whatever the case I think this could easily be handled with a simple API call > to flush preloaded code which for debugging could be one of the first things > a developer would call in their codebase. > > > I am highly skeptical about allowing arbitrary preload/compile time > > behavior as it makes development harder and bifurcates the ecosystem. > > Given the copious performance and robustness benefits that preloading could > provide, I would think we should try and identify specific concrete concerns > rather than allow unidentified concerns from blocking a potentially great > improvement to the language. > > So what specific concrete concerns can we identify? > > > To your specific examples, many are already possible today. Code > > generation in a pre-execute build step is increasingly common; the Symfony > > ecosystem does a ton of it, I've implemented a compiled version of a PSR-14 > > Event Dispatcher, etc. > > Am I understanding correctly that requires a _build_ process, and not > something that a PHP developer can depend upon having available on any hosted > PHP server? > > > Code generation at that point is then impossible. Moving that code gen to > > a preloader wouldn't help with that. > > As Robert stated, he is not proposing any code generation. > > His preloading concept would modify classes by manipulating the AST, which, > IMO would require an additional API. And I do think it is probably orthogonal > to the idea of preloading code although I do think it would also have great > benefit too, but that preloading is probably a prerequisite. > > > I appreciate the intent here, but in practice I'd much rather we limit > > preload optimization to things the engine can do for us, and reliably know > > that it can do so without changing behavior. > > Limiting in that manner would effectively eliminate the possibility of > serendipity that can occur when userland developers are empowered vs only > those who can sufficient agreement to add features to PHP. IOW, tiny subset > of problems could be solved if we limit vs. the number of problems developers > could solve for themselves and offer to the open-source to the community if > userland developers are given more control over preloading. > > > For example, there's a ton of optimizations that can be done that rely on > > working with pure functions only, but the engine today cannot know if a > > function is pure. (Or I don't think it's able to figure it out for itself, > > anyway.) I'd be fully in favor of ways that we could indicate to the > > engine "this is safe to do more computer-science-y
Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
> Once you are in a live environment you want a read-only file system, for > security and auditability. Code generation at that point is then impossible. > Moving that code gen to a preloader wouldn't help with that. My proposal has no impact on the file system. It would modify the AST, and thus would be entirely in RAM as opcache is also in ram. No source files involved at all. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Introducing compile time code execution to PHP preloading
With PHP having recently introduced preloading, i have been thinking
about the possibility of adding a system whereby arbitrary php code
can run during this step. Essentially, this would serve the same
function as 'compile time execution' in many programming languages. It
should be noted that my thoughts below are mostly inspired by the
in-development language JAI, demos of which are included at the end of
this email.
While PHP is an interpreted language, code is first parsed which
generates an AST, and this AST is then used to generate bytecode that
is stored in opcache. With preloading, the generation of this bytecode
is done only once on server startup. Compile time code would run
during this stage as a 'shim' between parsing and bytecode generation,
allowing arbitrary modifications to the AST.
I can think of numerous examples of ways this could be advantageous.
For one, frameworks often want to store configuration data in a
database or some other external source, and accessing it every request
is needless overhead, given that data tends to never change in
production. So you could do something like the following which runs
once during preload, and caches the constant in opcache.
static_run {
$link = mysqli_connect("127.0.0.1", "my_user", "my_password", "my_db");
$res = mysqli_query ($link, 'select * from sometable');
$array = [];
while($row = mysqli_fetch_assoc($res)) {
$array[]= $row;
}
define('CONST_ARRAY' = $array);
}
static_run being a new keyword that allows an expression to be
evaluated at compile time.
I foresee this being able to do far more than simply define constants
though. In my opinion, it should be able to allow arbitrary
modifications to the AST, and arbitrary programmatic code generation.
For example, static code could register a callback which receives the
AST of a file during import:
static_run {
on_file_load(function($file_ast){
// Do something with the ast of the file
return $file_ast;
});
}
As noted above, I can think of numerous things that this could do, and
as a flexible and far reaching facility, I am sure many more things
are possible that I have not considered. To give a few examples:
* Choose a database interface once instead of during every request.
* Check the types defined in an orm actually match the database.
* Inverting the above, programmatically generate types from a database table.
* Compile templating languages like twig into PHP statically,
eliminating runtime overhead
* Convert syntactically pretty code into a more optimised form.
* Statically generate efficient code for mapping URLs to handler functions
* Validate the usage of callback systems such as wordpress 'shortcodes'.
* Arbitrary code validation, such as to implement corporate
programming standards.
Why not a preprocessor?
While things like this can be implemented as a preprocessor, I can see
considerable advantages of implementation as a native feature of the
language itself. A big one is that it would be aware of the semantics
of the language like namespaces, and scope, which is a big downside of
rudimentary preprocessors like the one in C/C++. Implementing it into
the language runtime also eliminates the need for a build step, and
means that everyone using the language has access to the same tools.
I also think that given that these data structures already exist
during compilation to bytecode, why not just give programmers access
to them?
This concept is not that unusual and python for example, allows python
code to modify the AST of files as they are being loaded. However
directly modifying the AST won't be very user friendly. Due to this,
syntax could be created which allows the more common operations to be
done more easily. Rust has a macro system that is based on this kind
of idea, and JAI has recently introduced something comparable. While
it should be obvious from the above, i am not talking about macros in
the C sense. These should be 'hygienic macros'.
How it runs
On the web, compile time code is ran during preloading. When running
php code at the CLI, compile time code could just be run every time,
before run time code. Cacheing the opcodes in a file and automatically
detecting changes and recompiling this as python does, could be a
worthwhile optimisation.
Inspirations
The general idea with this was inspired by the in development
programming language JAI, which has full compile time execution.
Literally, the entire programming language can be run at compile time
with very few restrictions. See the following to videos for a
demonstration of what it can do:
https://www.youtube.com/watch?v=UTqZNujQOlA
https://www.youtube.com/watch?v=59lKAlb6cRg=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO=20=0s
There is also a programming language called 'zig' that is based on
similar ideas to JAI, and also has compile time execution. Unlike JAI
it has been released
Re: [PHP-DEV] Initializing constants once, with code?
> > I stand by my comment that this has *some* of the same problems as a > > separate "build" script, such as the need to be configured correctly, > > I find repeating of this as overstating the concern simply because any > programming language feature would need to be used correctly. So this also > feels like a distinction without a difference. > > > the difficulty of debugging errors in this special code, > > Depends? If this where to use XDEBUG just like regular PHP there would be > zero difference. > > > and the need to invoke the extra processing manually for things like > > command-line scripts. > > Since PHP is different from a pre-compiled language like C or Go, it compiles > "on-demand." So I would see zero need for a build step. > > I would also see PHP could first run the compile-time code once, and then run > the runtime code for every execution. On-demand. And XDEBUG could be used for > both. > > For CLI, it might always run the runtime code and then the compile time code. > Unless there is a standard location set of compiled opcode in .ini file, > and/or unless PHP provided ways to generate OpCode artifacts to be loaded at > runtime. > > -Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > There would be no definite build step in the sense of needing to run a compiler, as this 'compile time code' would run once during preloading on web code, and as sugested above, could be ran every time for command line scripts, but cacheing the opcodes in a file and automatically detecting changes and recompiling this as python does, could be a worthwhile optimisation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Initializing constants once, with code?
> After posting my objection to pre-processing I remembered there was another > reason I object to pre-processors that is even more significant than lack of > composibility. And my objection extends to all the transpiring being done > with Javascript and CSS too, although I put up with those because the > community has mitigated some of the worst problems and because so many > developers have embraced them. > My suggestion was not a preprocessor, but what others have said already, a 'shim' that goes between the parser/lexer and bytecode generation which allows user code to inspect and modify the AST. This idea is not unusual and Python for example can do this. The idea is the basis of macro systems in Lisps, and Rust has a very nice implementation of it from what I've seen in passing. The system should be fully aware of the syntax, scoping, namespaces etc, the lack of which is the problem with C preprocessor for example. With regards to how JAI does this: https://www.youtube.com/watch?v=UTqZNujQOlA https://www.youtube.com/watch?v=59lKAlb6cRg=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO=20=0s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Initializing constants once, with code?
Would it be worth expanding the ideas of programmatic constant definition into a more general compile-time code execution approach? It would work well with preloading introduced in 7.4, and could allow some of the things frameworks are currently doing at runtime to be done once at compile time (opcode generation time). The work-in-progress language JAI has a very interesting compile time execution system which could possibly be a source of inspiration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for Async / Await
Does this actually fit in with php's execution model of each request being a separate thread / process? As far as I understand this kind of async programming is only useful within an event-loop architecture as used by nodejs for example. There are things that do this for php like ReactPHP, but it is not how the language usually gets used, at least now. Making this really useful would probably entail changing the execution model to one where requests are handled by long running processes. On Sun, 22 Dec 2019 at 20:59, Aran Reeks wrote: > > Hi Internals, > > Since the start of PHP 7, we've seen some amazing performance improvement > version by version as a result of core updates. > > Now some of the biggest wins have been implemented (with JIT due for PHP > 8), I'd personally love to see support for Async / Await introduced in > PHP's as a core language feature too. > > Being able to perform tasks in parallel such as reading or writing to DB, > cache, queues... Would be a massive advantage and the performance gains > from it could be really exciting! > > Looking at how Hack has implemented support, this seems like it could be a > great start for a RFC, what does everyone else think? > > Here's a link to Hack's implementation for reference: > https://docs.hhvm.com/hack/asynchronous-operations/some-basics > > Thoughts welcome from everyone. > > Cheers, > Aran -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Opt-in "use function *;" for skipping check for function/const in alternate namespace
>
> What are your thoughts about syntax such as the following, similar to the
> syntax for Java (only for use of functions/constants from the root scope)
>
> namespace My\NS;
> use function *;
> use const *;
> // can use functions/constants from namespaces that aren't the global
> namespace to override '*'
> // "use *" is not valid.
> printf("PHP Version is: %s\n", PHP_VERSION);
>
I am in support of this, and my personal code still doesn't use
namespaces at all due to things like this, relating to the handling of
functions in the language. I personally think that the whole
'autoloading' concept is a bad idea, and ahead of time import and
compilation to bytecode, as offered by preloading is a far better
idea.
On Thu, 28 Nov 2019 at 00:02, tyson andre wrote:
>
>
> What are your thoughts about syntax such as the following, similar to the
> syntax for Java (only for use of functions/constants from the root scope)
>
> namespace My\NS;
> use function *;
> use const *;
> // can use functions/constants from namespaces that aren't the global
> namespace to override '*'
> // "use *" is not valid.
> printf("PHP Version is: %s\n", PHP_VERSION);
>
> A similar opt-in directive syntax "use function root;" was mentioned as an
> alternative to the "Deprecation of fallback to root scope" RFC
> https://marc.info/?l=php-internals=151788196501507=2 . (I couldn't find
> any other mentions after a quick search)
>
> Benefits of "use function *":
> - Visually cleaner and less prone to merge conflicts than "use" for dozens of
> functions/constants all from the root scope. (or writing \printf("PHP Version
> is: %s\n", \PHP_VERSION), or mixes of the above)
> - Due to the absence of function autoloading (not supported in php to
> performance overhead), functions outside the global scope are rare in
> practice.
> - This would make it easier to make edits to a project (if the project's code
> style involves the unambiguous use of functions/global constants)
> - This makes using unambiguous functions/global constants easier. (for a
> small performance boost due to the php interpreter not needing to check both
> namespaces, opcache knowing exactly which function/constant it is, etc)
> - Does not break third-party code
>
> The other RFC https://wiki.php.net/rfc/fallback-to-root-scope-deprecation had
> the following notable objections, and I'm not sure of the current status of
> it:
>
> - Deprecating the behavior of existing code would break (possibly
> unmaintained) third-party libraries and require a lot of code changes,
> discouraging updates
>
>"use function *;" wouldn't.
> - Some mocking libraries will declare functions in namespaces being tested,
> with the same name as the global function.
> My proposal has similar drawbacks - third party code that started using
> "use function *" would break those libraries (but so would manually adding
> the same namespace uses).
>
> But there are alternatives to those libraries, such as uopz, runkit7, and
> SoftMocks (SoftMocks changes the class autoloader to replace code with
> instrumented code).
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline switch as alternative to nested inline conditional
> > > $say = switch (date("w")) {
> > case 0 => "weekend!";
> > case 1, 2, 3, 4, 5 => "weekday :(";
> > case 6 => "weekend!";
> > };
> > echo "Today is {$say}";
If you had a really long expression, it may be easier to read if the
assignment was moved to the end, perhaps like this:
switch (date("w")) {
case 0 => "weekend!";
case 1, 2, 3, 4, 5 => "weekday :(";
case 6 => "weekend!";
// lots more cases ...
} => $say;
echo "Today is {$say}";
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP header files, restrict to declaring code only
>
> That said... most polyfill files, of which there are a decent number, do some
> variation on:
>
>
> if (!function_exists('coolness')) {
> function coolness(int $coolLevel) { ... }
> }
> ?>
>
I can see quite a lot that could be done with preloading by executing
code once, essentially compile time code execution. For example,
choose which database interface is being used once, instead of every
time the script runs. Or compile 'fluent call chains' into a more
efficient form. If the AST were accessible, there is quite a lot more
that could be done.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@M. W. Moe If you don't like the java-isms you can ignore them to a large extent, which I do. However in doing so you're going against the grain and will end up writing a lot of stuff yourself. I do find it weird how PHP has morphed so drastically from it's origins and also wander why. If people wanted a Java-esque language, why not use Java in the first place? This discussion is off topic. On Thu, 11 Apr 2019 at 17:15, Benjamin Morel wrote: > > > why? if voicing reasonable criticisms is bothering you; then you should > do something else in life; > > because engineering is built on this `very` concept; > > You're very welcome to challenge the "java impurities" that have been a > foundation of the language for 15 years—although you may better invest your > own time by switching to another language that's already closer to what you > expect. > > But calling people pigs when they disagree with you is not what I'd call > reasonable criticism. > > > I am not in the apex or any emotional trend; it does not interest me. > > Oh that's exactly the impression you've left so far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On Thu, 11 Apr 2019 at 00:43, Rowan Collins wrote: > > On 10 April 2019 21:56:41 BST, "Björn Larsson" > wrote: > >Could then the \($x) syntax be a good compromise between > >readability & implementation? > This syntax does make sense to me, although only as I've seen it before in Haskell, which does something similar: https://wiki.haskell.org/Anonymous_function I think that people will get used to whatever becomes common. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
> On the balance of things, I would most certainly like to see leading and > trailing whitespace render a string ineligible to be implicitly > converted, but I'd be satisfied with (int)" 123 " converting without error. > Given that PHP seems to be gradually moving towards more type strictness, would it make more sense to move this functionality to a 'parse_numeric_string()' function? Js has parseInt() and parseFloat() with similar functionality. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
> I'd just like to amplify this mention of 3rd party tooling: if we go with > something which requires complex lexer/parser rules, then every editor, > IDE, and static analysis tool will need to also work with that syntax. > Is this actually a problem? Don't these tools make use of existing parsers like 'php parser', thus the cost is lower than initially apparent? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
> - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url)); > - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url)); > - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url)); > > I would say that when lambda functions occurs in function calls I find the > \ or ==> syntax more readable. > To me, in that context, '==>' is the most readable as it does not have parentheses on the argument. It's a bit visually noisy with them. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings
> Why? Wouldn't it be nice to align the behaviour of implicit and explicit > casting, so that (int) "abc" throws a TypeError? > I agree with this. It would be odd if they behaved differently. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parameter skipping
Why not just wrap the function in another function? On Sat, 6 Apr 2019 at 23:46, Morgan Breden wrote: > > The problem I see with this approach is that a keyword for skipping > parameters > would really just be a stopgap solution until something like Named > Parameters > can be added. > > Is it really appropriate to add a feature that only serves a temporary > purpose? > > On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan wrote: > > > Hi all, > > > > After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP > > 7.3 I've encountered the annoying issue of having to pass the $depth > > parameter as 512 every time I want json_decode() to throw. > > > > After doing this a few times I remembered the parameter skipping RFC that > > Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams > > > > I've re-read the previous discussion and it seems to me there were two > > common arguments against: > > * Just design better APIs > > * Named parameters would be better > > > > Nobody has been able to crack named parameters (and it doesn't seem likely > > anytime soon), and as we've seen from the JSON example above it's not > > always as simple as having better APIs, so I wanted to see whether people > > would be willing to support the *default* keyword for optional parameters > > now. > > > > Thanks, > > Craig > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
> > If the static analyser was programmable, it would be possible to > > provide it such information, within the scope of a single code base. > > In the case of data returned from a database, the metadata for the > database is another source of information relating to that data, and it > would be useful if PHP had a means to access that data, but in reality > this is still currently an area for developing 'a single code base' > within the IDE level rather than PHP itself? > I already do this to a small extent with my code using Psalm, and intend to explore it more deeply in the future. I was just making the point that having this ability is useful, in case the PHP project were to develop a 'core' static analysis system. Specifying this information directly in the code, vs specifying it at the level of an API is, in my opinion, just an application of separation of concerns. Having an API for it allows type checking to be applied to existing dynamic code bases which make use of dynamic functionality in a statically knowable way, which cannot be expressed within the type system. And yes, I do believe that having a result set be a simple associative array is perfectly fine. I defer why to the lecture 'simple made easy', available on youtube and else ware. . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 13:15, Rowan Collins wrote:
>
> On Fri, 5 Apr 2019 at 12:42, Robert Hickman wrote:
>>
>> In the first case:
>>
>> function foo(callable $bar): int { return $bar(); }
>>
>> I think the value of $bar would have to fall into a set of values
>> known to the programmer, or at least known at some level.
>
>
>
> I think you're misunderstanding the problem: it's not that the *programmer*
> doesn't know the types, it's that the *analysis tool* doesn't know them,
> because the programmer hasn't told it, and currently has no way to tell it.
>
If the static analyser was programmable, it would be possible to
provide it such information, within the scope of a single code base.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
In the first case:
function foo(callable $bar): int { return $bar(); }
I think the value of $bar would have to fall into a set of values
known to the programmer, or at least known at some level. The only way
I can currently think of where this would be truly unknown is if it
comes from unfiltered user data, which would be a security issue, due
to allowing arbitrary function calls.
Wordpress does something like this in it's shortcode and
'action/filter' system, The set of valid function calls in that case
would be mostly defined by all calls to 'add_action' and 'do_action'
(and related functions for shortcodes) in the core and installed
plug-ins. It may be unknown in some cases if that is controlled by
user input. As above I doubt that is truly unknown as allowing
untrusted input would be a security issue.
In the second case the iterable has to come from somewhere, so it's
content would be defined by whatever that 'somewhere' is.
Getting back to the original topic, how would 'throws' interact with
exceptions raised by the php interpreter itself?
On Fri, 5 Apr 2019 at 12:12, Rowan Collins wrote:
>
> On Fri, 5 Apr 2019 at 11:30, Robert Hickman wrote:
>
> > If a static
> > analyser were programmable, it could parse the SQL query and query the
> > database to find out what keys exist in some_table. Thus it could
> > check for references to non-existing keys.
> >
>
>
> That's an interesting example, but I don't think it generalises as far as
> you think: what would a "programmable analyser" do with an array of HTTP
> headers, or query-string parameters?
>
> However, I wasn't referring to dynamic *data* like this, but rather dynamic
> behaviour in the language itself. A couple of simple examples:
>
> function foo(callable $bar): int { return $bar(); }
> function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
> } }
>
> In order to analyse those, you need a) the language to offer a richer type
> system (generics, derived types, etc); and b) the programmer to make full
> use of that type system, everywhere.
>
> As soon as you have code that's missing rich type information, or use a
> truly dynamic feature, that whole section of code becomes essentially
> unchecked. That's why Hack is not only adding features for richer
> (statically analysed) type annotations, but also *removing* PHP features
> which don't work nicely with them.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
> > The tricky part is that PHP is a highly dynamic language, so there's a lot > of cases where the analysis can only return "maybe". My understanding is > that this is what a lot of the work on Hack is doing: creating a language > which looks a lot like PHP, but doesn't have as many ambiguous cases which > can't be analysed statically. > Quite a lot of code that apparently cannot be statically analysed could be if the static analyser was programmable. To give a simple example: $result = mysqli_query ($conn, 'select * from some_table'); $arr = mysqli_fetch_assoc ($result); The contents of '$arr' cannot be known using only the data provided in this code, however it's contents is statically knowable. If a static analyser were programmable, it could parse the SQL query and query the database to find out what keys exist in some_table. Thus it could check for references to non-existing keys. I suspect this is the case for a lot of 'non analysable code', it can only function within a known set of states, but the type system is unaware of those states. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
>
> For instance:
>
> function foo(): type nothrow {
> throw new SomethingException;
> }
Would it be possible to analyse the call graph at compile time
(bytecode generation) and then trigger a fatal error? It wouldn't be
possible for variable functions/methods though. A separate static
analyser could do the same thing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Retiring PHP's Mirror Program
Is there any reason not to use 'php.net' raw without the 'www'? On Mon, 1 Apr 2019 at 12:49, Derick Rethans wrote: > > Hi, > > I've just pushed the changes to the PHP website live, and fixed the > apache config on php-web3, as it still had "php.net" as ServerName and > "www.php.net" as ServerAlias — I did commit that to the local GIT > repo. > > Things seem to look fine, so are you OK with my switching away DNS from > the mirrors in the mid-afternoon (15:00 BST)? > > cheers, > Derick > > On Thu, 28 Mar 2019, Sascha Schumann wrote: > > > > So I guess we (I) need to modify that script to not CNAME these to the > > > respective mirrors, but instead to star-php-net.ax4z.com. instead? I can > > > work on that (tomorrow). > > > > Sounds good. > > > > Sascha > > > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > Like Xdebug? Consider a donation: https://xdebug.org/donate.php, > or become my Patron: https://www.patreon.com/derickr > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
As long as it dosn't remove ' wrote: > > Hello, > > On Mon, 25 Mar 2019 at 14:02, G. P. B. wrote: > > > > Hello internals, > > > > I would like to start the discussion about the deprecation of PHP's short > > open tags: > > https://wiki.php.net/rfc/deprecate_php_short_tags > > > > As this is my first RFC all feedback is welcome. > > However, due to the nature of the RFC and it being self-contained, the > > planned date to > > beginning voting this RFC is after the mandatory two weeks discussion > > period and would > > start on Monday the 8th of April (2019-04-08) and be open for two weeks > > until Monday the > > 22nd of April (2019-04-22). > > > > Best regards > > > > George P. Banyard > > Short opening tags are by default disabled in the php.ini settings on > the majority of PHP installations. This means that writing modern PHP > code shouldn't use these anymore because the code isn't properly > portable or let's say it is less portable. On top of all removing > these would also simplify things a bit - one opening tag for the same > thing less. > > Also, a quick opinion based poll has been done in the PHP.earth > Facebook group [1] with ~96% in favour of the removal. > > So, +1 for removing these and simplify things more. There are only two > tags really needed in PHP templating engines > [1]: https://fb.com/groups/2204685680/permalink/10157687999015681/ > > Best regards. > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New syntax proposal (type hinting)
On Sat, 23 Mar 2019 at 20:17, dj.drezyna wrote:
>
> I wish have opportunity to set types not only like: function a(): string {}
> or function b(): ?string {}
> but also as: function c(): string | int {} or function d(): ?string |
> ?array {}// all of them should mark
> that null is accepted.
Looks like you're asking for union types. There was an RFC about this
before but it didn't pass, I don't know why.
https://wiki.php.net/rfc/union_types
I would also like to see union types added, as I can't type hint most
of my code in absence of them.
Regarding the type coalescing problem noted in that RFC, my solution
to that would be to do noting. If a function accepts float or int, it
should just pass either through unchanged. Passing any other type
should be an error without an explicit cast IMO.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
On Thu, 21 Mar 2019 at 16:15, Rowan Collins wrote:
>
> On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote:
>>
>> In this case nextIf() would have to be implemented something like:
>>
>> function nextif($someCondition) {
>> foreach($this->iteratorValue as $x) {
>> if(> yield $x;
>> }
>> }
>> }
>>
>> iterator_to_array would need an internal loop to pull the values from
>> the generator.
>
>
>
> I think it would be more like this:
>
> function nextif($someCondition) {
> do {
> $this->currentIndex++;
> $x = $this->items[ $this->currentIndex ];
> } while ( ! some comparison of $x and $$someCondition);
> return $x;
> }
>
Thanks, that makes sense.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
> But $filteredArrayIterator->next() is actually $arrayIterator->next() with
> a built-in if check, so you could also picture it as doing this:
>
> while ( $element = $arrayIterator->nextIf ( someCondition ) ) {
> $newArray[] = $element;
> }
>
In this case nextIf() would have to be implemented something like:
function nextif($someCondition) {
foreach($this->iteratorValue as $x) {
if(http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
I was only making a point for where a non-generator version of comprehensions could be useful, under the premise "Therefore, a lazy-evaluating syntax is more powerful, in that it can do everything an eager-evaluating one can do *and more*.". This implies that it dosn't have any downsides, whereas performance may be a downside. On Thu, 21 Mar 2019 at 07:54, Rowan Collins wrote: > > On 21 March 2019 00:39:20 GMT+00:00, Robert Hickman > wrote: > >For my use case of PHP, get some content from a DB and dump it into a > >template, I don't see much benefit to generators. > > With respect, so what? I never said that every use case benefits from > generators, nor are we discussing whether generators should be added to the > language. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
> > Hi! > > > >> It's not that you can't make an array into a generator, but you can't make > >> an eagerly-evaluated expression into a lazily-evaluated one. > > Not sure what you mean here. > > > I mean that, given a syntax that lazily-evaluates something, you can > "fast-forward" the result to make it eagerly-evaluated; given a syntax > that eagerly-evaluates something, you cannot do the opposite. Therefore, > a lazy-evaluating syntax is more powerful, in that it can do everything > an eager-evaluating one can do *and more*. > For my use case of PHP, get some content from a DB and dump it into a template, I don't see much benefit to generators. Such content is textual and is small relative to available ram. Memory locality also matters for performance and it is generally faster to do a whole bunch of stuff at once, thus I'd expect an eager version to be faster than a generator. I'm almost sure it would be faster if stepping the generator entailed IPC, reaching out to a database for instance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
>> Honestly, I cannot think of any case where I'd use a comprehension >> where I would definitely want an array and not a generator. In the >> majority case both work equally well, cool, but I don't know when I >> would even use an array-dependent version. >> And converting from a generator to an array is trivial; the other >> way, very not so much. > I don't think I ever used > the generator one in python (I use list one all the time), and I maybe > used analogous construct in PHP once or twice (and again I use array_map > and more complex syntax for array transformations all the time). > I use generator expressions rarely in python, usually as a conditional 'if any data in x match condition': if not next((True for flter in config['pull_ignore_filters'] if fnmatch.fnmatch(fle['path'], flter)), False): filtered_pull_files.append(fle) I use the list form for filtering, and the dict form mostly for creating an index of a sub-value as noted before. I don't use generators at all in PHP right now, but do make extensive use of loops doing filters and building indexes. An 'array comprehension' syntax would be welcome from me. One needs to be contentions that people use tools differently, so 'I don't use something' isn't the same as 'nobody uses something'. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
> > In python comprehensions on [] makes a list and comprehensions in {}
> > make a dictionary (list and dict comprehensions). As PHP only has one
> > 'array' type using [] makes sense. Along that train of thought, should
> > comprehensions also be possible in the old array() syntax?
>
> Honestly, I cannot think of any case where I'd use a comprehension where I
> would definitely want an array and not a generator. In the majority case
> both work equally well, cool, but I don't know when I would even use an
> array-dependent version. And converting from a generator to an array is
> trivial; the other way, very not so much.
>
Would there be any notable performance difference? I'd expect the case
where one actually wanted the whole array to be slower if it was going
through a generator, vs a tight loop, due to the additional level of
indirection.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
> > Why not apply the same approach to PHP? There is iterator_to_array() to
> > convert a generator to an array, so we may not need both syntaxes.
> > However, I think using [] for something that is *not an array* is
> > counter-intuitive.
>
> No, I would definitely be for []-syntax producing an array. As I said,
> that's in my experience what people usually want.
>
In python comprehensions on [] makes a list and comprehensions in {}
make a dictionary (list and dict comprehensions). As PHP only has one
'array' type using [] makes sense. Along that train of thought, should
comprehensions also be possible in the old array() syntax?
Does the proposal include comprehensions which build associative
arrays? In python you can do {a['key'] : a for a in lst}, where lst is
a list of dicts. I often use this to create a dictionary whose keys
index a sub-element of a nested dictionary, as my example shows.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unload/reload classes?
On Tue, 19 Mar 2019 at 00:55, Ben Ramsey wrote: > > > On Mar 18, 2019, at 18:45, Robert Hickman wrote: > > > 1: I have seen an extension which allows functions/classes to be > redefined, although I can't remember what it is called. > > > > Maybe you’re thinking of the runkit extension? > https://secure.php.net/manual/en/book.runkit.php > > Cheers, > Ben Yes that's what I was thinking of. Looking at it there is 'runkit_function_redefine' but no 'runkit_class_redefine', only facility to redefine individual methods of an existing class. Thus not matching Rasmus Schultz request. The sandboxing facility of runkit may make dynamic reload possible, if a new sandbox were created when reload was desired. That's just me reading the API docs though, I haven't tried it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unload/reload classes?
(I'm not a internals developer, but here are some ideas:) 1: I have seen an extension which allows functions/classes to be redefined, although I can't remember what it is called. 2: It is possible to dynamically reload code if defined as anonymous classes or functions using return include: $class = include "file_1.php"; $class->some_function(1,2); This would entail creating a custom namespace system, and a facility to watch and re-include files. I don't know if the old bytecode of 'orphaned' objects would be garbage collected. 3: Another option would be to create a watcher on the files and just kill and reload the php process on file changes. This would be easier if the application state is all stored externally. 4: Use Ruby/JS/Python instead? On Mon, 18 Mar 2019 at 20:16, Rasmus Schultz wrote: > > Hello internals, > > How hard would be to add an unload (or reload) feature for > classes/interfaces? > > I'm wondering with regards to running PHP as a deamon (with Swoole or > ReactPHP, etc.) could it be made possible to hot-reload e.g. for > controllers and view-models? > > Of course, the other option is to launch worker sub-processes under some > sort of host process, and then restart the workers after a change - this > adds communication overhead between the host/worker processes though, and a > layer of complexity. > > Another option is if a reverse proxy (NGINX maybe) could restart the actual > application daemon, but that means you have a dependency on a specific > reverse proxy. > > So I know there are other options, but I'm looking for the simplest and > cleanest way to do this, and I'd prefer to stay within the language. > > Other dynamic languages (where daemonizing is "normal", like Ruby, JS and > Python) have this feature and it is often used to hot-reload > controllers/views in web-apps. > > Any thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] JIT and data locality?
I saw in a previous discussion on the addition of JIT that performance in web applications wasn't improved due to data locality issues. I was just wandering weather it would be possible to/worthwhile to add more facility to control data layout, for those who may wish to do so, while leaving the existing data structures alone. I'm thinking along the lines of what numpy does for python? As far as I'm aware, the FFI which has been accepted does allow this lower level control of memory layout. However it is noted that it has much worse performance than the native php structures. Is this due to runtime type conversions? Do note that my understanding of PHP's internals is limited to the articles I've read on the subject, so this thought is from an outsiders perspective. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
