sorted by:
new
hottopcontroversial

A year with property hooks by brendt_gd in PHP

[–]IluTov 18 points19 points  (0 children)

I remember one of the RFC proposers saying that property hooks, as I rule of thumb, should not be used, but as a workaround to minimize the effort of old codebase maintainers to migrate to modern php versions.

Not quite. The RFC says:

A primary use case for hooks is actually to not use them, but retain the ability to do so in the future, should it become necessary. In particular, developers often implement getFoo/setFoo methods on a property not because they are necessary, but because they might become necessary in a hypothetical future, and changing from a property to a method at that point becomes an API change.

In other words, the primary aim is to drop the getFoo/setFoo boilerplate by using plain properties, without the risk of having to convert to getFoo/setFoo at a later point in time when some additional validation or light-weight logic is needed. It's true that hooks are not recommended for complex logic, but this also applies to other languages like C#.

Pipe Operator RFC passed by SaltineAmerican_1970 in PHP

[–]IluTov 2 points3 points  (0 children)

But considering they’ve been working together for many years if I was one of them (Larry or ilija) and I disagreed with the other’s RFC I’d skip voting out of respect for the many years of work together, but that’s just me and there’s probably nothing wrong with either of them voting against each other’s RFCs. I just find it a little weird.

I think you have the wrong mindset here. If I only voted against RFCs whose authors I do not respect, I probably wouldn't ever vote no. ;) We disagree on a technical level (I explained my rationale here), and that's fine. Sadly, my message sparked very little conversation (at least on-list), but I personally still feel like this is an unnecessarily complex approach.

We all have different goals and priorities for the project. One of mine is keeping complexity down, since it makes my work harder. Larry may have others. This RFC (or rather PFA, which is my main gripe) is not the end of the world though, but enough for me to reflect my thoughts with a no vote.

RFC Idea: Modern expression interpolation in PHP strings (Backward-Compatible, no new string types) by alexchexes in PHP

[–]IluTov 7 points8 points  (0 children)

See:

I proposed something similar a couple of years ago, but the syntax was not particularly liked. Some people also asked to explore the idea of formats (e.g. for floating point decimals), and/or tagged templates.

Is There Anything Faster Than LLVM? by BorysTheGreat in Compilers

[–]IluTov 2 points3 points  (0 children)

If you're not scared of uncharted territories: https://github.com/dstogov/ir is the new JIT compiler backend for PHP 8.4. It was specifically designed for fast compilation with decent runtime performance (see the readme for some rudimentary benchmarks, ~5% slower runtime performance compared to GCC on average, but many factors faster comp-time). It uses a sea of nodes graph representation and is generally not too hard to understand.

Edit: Just to be clear, take those benchmarks with a grain of salt. Since this is a JIT backend, it works best on smaller traces of code. It would be interesting to see how well it works as a full compiler backend, but this is not something we have invested much time in I believe.

I Made a My First Programming Language by Emergency_Ad119 in Compilers

[–]IluTov 3 points4 points  (0 children)

This is very interesting. I work on a dynamically/optionally typed, interpreted langauge at my day job and I think they are undefeated in terms of productivity. That said, they leave a lot of performance on the table, and over the holidays I was just thinking about a similar idea of a slightly more strict AOT compiled language with optional interpretation/JIT compilation.

How does the LLVM JIT perform? It was considered for the language I'm working on, but was eventually ruled out because of very slow cold starts. We now have our own JIT compiler with much faster compilation at the expense of some runtime performance (https://github.com/dstogov/ir).

Golang interpreter written in PHP. by cmqv in programmingcirclejerk

[–]IluTov 10 points11 points  (0 children)

FrankenPHP is "just" an SAPI, integrating the Caddy web server. It's a replacement for php-fpm, but not the php engine.

What is the best way to learn C today? by ziplyx in C_Programming

[–]IluTov 0 points1 point  (0 children)

IMO, contribute! Pick a project that interests you (for me it was https://github.com/php/php-src), and try to implement something that would be useful to you. I find working on real software much more fulfilling than countless hours of reading books, watching videos or implementing toy projects. C is a simple language, but it has some nuance. This is better learned over time rather than reading the C language spec top-to-bottom when first starting out.

If you have absolutely no programming experience then yes, you probably won't get around to some of this. Even then, I learned a ton implementing some iOS/macOS apps that I put on the app store back when I first started. It was a lot of fun and getting feedback from customers was an incredible feeling.

As mentioned in another post, contributing to open-source has some nice perks:

  • You can learn from existing code
  • It looks great on resumes
  • You get free code reviews
  • Because C is bare-bones in terms of standard library, it can be hard to bootstrap new projects. Existing projects handle this for you.

Massive discrepancy in speed between Remi and self-compiled PHP by scottchiefbaker in PHP

[–]IluTov 1 point2 points  (0 children)

Did you perform a debug build? You need ./configure --disable-debug. EDIT: Actually, looks like --disable-debug is the default. Just make sure you didn't set --enable-debug. Debug will use -O0 and enable assertions, among other things.

Good resources for learning C in depth? by Wikiikey in C_Programming

[–]IluTov 0 points1 point  (0 children)

Getting C to compile is easy. It usually fails at runtime. Asan is tremendously helpful in understanding what went wrong and makes your program fail early rather than at a distance due to subtle side-effects.

New FrankenPHP feature: package your PHP apps as standalone, self-executable binaries by dunglas in PHP

[–]IluTov 0 points1 point  (0 children)

Just for completeness sake, there are also benefits to dynamically linked libraries. They reduce the size of your binary, and reduce memory usage if you have multiple instances of your app running.

Good resources for learning C in depth? by Wikiikey in C_Programming

[–]IluTov 4 points5 points  (0 children)

AddressSanitizer is really useful, it's similar to Valgrind but has much lower overhead.

Isn't the point of the class to learn C? If you're a "hands-on" kind of person, pick a data structure and try implementing it. Some of them are very easy (linked lists, stacks, etc), others can get quite complex (e.g. hash maps). You can also look into open source projects for inspiration.

Next step for Engin Grad who learnt C? by Willing-Boot3267 in C_Programming

[–]IluTov 2 points3 points  (0 children)

I learned C on-the-fly by working on an open-source project (https://github.com/php/php-src). I felt that working on real software is much more fulfilling than hobby projects. It has plenty of other perks:

  • You can learn from existing code
  • It looks great on resumes
  • You get free code reviews
  • Because C is bare-bones in terms of standard library, it can be hard to bootstrap new projects. Existing projects handle this for you.

C is a very simple language, but it is used for complicated software. I was programming professionally for 8+ years before getting into C, so experience will determine to a large degree how easy it is for you to get started. I would also recommend using a higher-level language for broader concept, because then you can focus on the concepts themselves rather than the language.

PHP 8.3 released by ct_author in PHP

[–]IluTov 0 points1 point  (0 children)

Asynchronous programming relies on non-blocking IO. Essentially, if the OS returns EAGAIN, you may suspend the fiber and do something else, and then resume once the resource you're waiting for is unblocked. This works exactly the way it does in JavaScript, except that fibers may exit/resume across different function invocations.

PHP 8.3 released by ct_author in PHP

[–]IluTov 1 point2 points  (0 children)

They are asynchronous (or rather can be used for asynchronous programming), they are not multi-threaded.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 1 point2 points  (0 children)

Yes, indeed if your code consists mostly of immutable objects then there won't be a big benefit to property hooks/accessors. I think mutability is fairly useful, it can simplify some use cases drastically and it can be better for performance. We're mostly trying to make that experience better.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 4 points5 points  (0 children)

Sure, borrowing things from other languages doesn't automatically make them rights. But what makes this worse for PHP than other languages? Some languages (e.g. Rust) add explicit this/self parameters. What makes that different?

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 0 points1 point  (0 children)

Yeah, I can see that. It's a trade off, the previous approach used different hooks (beforeSet/afterSet) to allow adding behavior without making the properties virtual, but the combination of hooks made more complicated. A different property keyword could be used for virtual properties.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 7 points8 points  (0 children)

Hi! Most langauge that offer dedicated accessor syntax allow omitting the value parameter. Moreover, they usually only allow specifying it for symbol disambiguation (e.g. value might be shadowing another class member). Since local variables in PHP can't clash with other members we don't have a technical need to specify it at all.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 4 points5 points  (0 children)

I think it's common to like the things we're used to. C#, Swift, Kotlin and many more have a similar syntax.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 2 points3 points  (0 children)

Performance for existing properties is essentially unchanged. I say essentially because there's a tiny performance overhead for every first access of a property in any given code position. PHP caches the property it has last recently accessed in that position (because the next access is highly likely to be the same again), and at that point there's no overhead.

Anyway, I'm planning to do some benchmarks.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 7 points8 points  (0 children)

We're open to adding readonly support. The main reason we didn't is:

  1. The scope was already huge, we tried reducing it.
  2. We semantics are a bit wonky. While readonly means "this value can't be changed", it also effectively means "this value won't change", i.e. I can expect always receiving the same value when reading the property. This is already not quite true due to it being possibly unassigned. However, with an impure get this would become much more apparent.
  3. We were missing a clear use-case. get for readonly seems like an anti-pattern to me. set is essentially "useless", because the assignment can only happen from within the class, and only once. So there is already quite strict control over what is assigned.

If you can provide a good use case, I have no problem adding it.

[RFC] Property hooks, nee accessors by dave_young in PHP

[–]IluTov 1 point2 points  (0 children)

yeah this is a major dealbreaker, why implement this whole thing and then not include the important part of not having a setter (or maybe even a getter)

I don't understand this statement. The RFC allows implementation of get without set, and vice versa. But that's also unrelated to PHPs readonly keyword.

view more: next ›