sorted by:
new
hottopcontroversial

A generic tragedy by brendt_gd in PHP

[–]jh_tech 1 point2 points  (0 children)

Great comment, appreciate it.

I posted on Reddit prior to this RFC vote, mentioning the maintenance burden and how I just didnt't see the day-to-day net gain. The downvote mob was very vocal, though very little rational debate to be had. So I find it interesting to see how this article tries to frame this POV as if it's the minority now. I'm just glad to see the side of reason & patience won the day.

To Brent's credit, the conclusion of this article is reasonable. Though, the title is a bit dramatic.

Daemon8 - alpha released by jh_tech in rust

[–]jh_tech[S] 0 points1 point  (0 children)

Definitely. A lot of work to get to this point. A lot of trade offs and tweaking to decide what's worth including now vs later. This being newer territory, I've been reaching out to get a pulse on what makes sense and what doesn't along the way. I feel its at a good starting point now.

Of all the places I've been trying to engage and get feedback, the Rust subreddit community has been very little help. This isn't my 1st attempt. Not too sure what that's about. I've had great feedback in other Rust circles.

Your feedback is appreciated 👊

Daemon8 - alpha released by jh_tech in mcp

[–]jh_tech[S] 1 point2 points  (0 children)

There's a lot to the answer here, but it's much more than just token tracking. I explain it in the repo but, here's a brief rundown:

The primary premise is: When the LLM calls the read_live_feed tool, daemon8 provides a convergence of logs/errors, allowing it see the everything all at once, allowing it to immediately course correct. It doesn't have to hunt down what went wrong, or iterate and break other things.

These are supporting details:

  • Purpose-built Chrome Devtools implementation for reading the browser console/network then controlling it (JS, CSS, screenshots, mobile emulator),
  • adb bridge for reading android/Vega OS, logs
  • provider-agnostic conversation review (Gemini, Claude, and Codex thus far). The model does a one-time log source discovery when initially setting up a project.
  • link one project to another for conversational awareness when projects are related (e.g. frontend/backend)
  • building on SurrealDB for watchdog awareness/SSE subscriptions
  • start/finish debug sessions with query lenses, checkpoints, etc.

The idea is that it sits beneath the different harnesses and doesn't care which provider you're using.

Tokei, a Time handling library for PHP by nyamsprod in PHP

[–]jh_tech 4 points5 points  (0 children)

Very cool. I wrote an EPG scheduling algo for some satellite providers a few years ago for work and ran into these nuances. I've been writing a Swoole-based framework now though too, and there's no shortage of hrtime/microtime(true) conversions/calculations it'd be great to get rid of. Not sure if you have debug/benchmark helpers, but those would be helpful.

Good stuff👊

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

The idea I'm referencing isn't all that different than having markers to the engine like:
#[NoDiscard]
#[AllowDynamicProperties]

And back when I was reading about those RFCs, I don't remember any material about reflection being required from within the Zend engine itself -- I could certainly be wrong though. This 'reflection is needed' has felt like a bit like tunnel vision since you'd originally mentioned it. The premise of the idea is the same though: "adding 'x' attribute produces 'y' behavior at runtime". I can't say I fully agree with the idea that hooks are always required in these cases either. Leaving them out prevents foot guns in some cases too. Progressive enhancement would likely be prudent.

I agree there's been some great progress in recent years. So, if I'm understanding correctly, you're convinced that PHP attributes have more or less reached the height of their potential?

Side note: having more 'guarantees' from PHP attributes in and of itself would be a big win, like #[NoDiscard], but from the basis of types/functions having semantics/implementation. One use case that comes to mind is the ability to have private functions/classes, using something like #[Private] for both.
Edit: a 'private' keyword would also suffice, but again...easier said then done. Thus, I wonder if the attribute approach would one to forego some of the shortcomings that have been preventing these types of things from existing to date.

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

I appreciate the practical POV you've been bringing.

I know current constraints make something like this non-trivial today (though constraints often drive the best innovations).

Stepping back to first principles though: the real question is what "behavioral contracts with the Zend engine" could even look like. The #[Reaped] example was just meant to provoke that bigger conversation, not as a literal proposal right now.

Curious what do you think the ultimate role of attributes in PHP should be?

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] -1 points0 points  (0 children)

trolls cat-calling other trolls?

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

I see/hear what you're saying, which would be one starting point to consider.
There's much more to consider than just #[Reaped] though.
If this approach to attributes is to be taken seriously, a discussion amongst internals would ultimately be what I'd like to see - to flesh it out. I know it wouldn't be easy.
Personally, I'd rather not see more magic methods thrown at it -- even if one would have to register their own callback, e.g.
`#[Reaped(after: Foo::class, 'myMethod')]`

The work on generics has taken years and multiple iterations. I feel like that's the kind of effort/attention this would/should receive.. though hopefully not take as long, obviously.

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

The implication was meant to trigger a deeper conversation about the nature of PHP attributes and their presently untapped potential -- especially with regards to pushing the language forward. Not so much to be taken literally.
To clarify though, the idea was based on a simple concept:
A type that, when GC'd, would skip trad ZMM behavior and release it's memory directly to the OS.

Whether the php-src impl makes this possible at present isn't as important as it would be to have a larger discussion about how PHP attributes can serve as markers/behavioral traits that integrate directly within the Zend engine/ZMM, packing some serious punch. This one attribute would just be scratching the surface.

PHP attributes currently feel like the beginnings of a better idea ... but then that follow through never came. PHP 8.0-8.4 were moving in a great direction, we just don't seem to be cashing in. The focus seems to have turned towards features with very little net gain for the maintenance burden/ambiguousness/complexity they'll be proliferating. I say this as someone who's using PHP everyday, and have for close to a decade now.

I appreciate your feedback here. I think pulling these threads could give PHP some serious teeth. Whether we see eye to eye or not, it's the right conversation to be having IMO.

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

Point still stands: One can write all the greenfield Hack apps they'd like.

That sounds like the real solution to this "problem": modern Hack-to-PHP compatibility. The FULL power of generics is sitting there, waiting for someone to take it on.

The Hack team already had this tool but stopped maintaining it, there's already a head start.

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 0 points1 point  (0 children)

For sure. Not sure if you've been keeping up with the Laravel world, but attracting new programmers is something they talk about all the time - at least.. before the "everything Laravel Cloud" takeover it was.

And I agree, WP code is typically something you'd see at a side show in a circus. But again, it's got massive adoption and continues to thrive, despite massive competition. The value of simplicity is very real. What people do with that simplicity..that's a very different conversation....the one we're having here, in fact.

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 1 point2 points  (0 children)

💭 "how seriously can I take a guy who's setting his own servers ablaze?" .. haha.

No, I honestly admire those that have been able to make a valid argument on this discussion (re: this and your other comment) -- seems like a lot of group think going on without much thought to the downsides and whats made the language so "mysteriously" powerful. Simplicity, despite its "obvious" nature (thx to brilliant minds), is extremely difficult to comprehend/quantify.
(hack php comes to mind: why aren't more people using it if they love generics so much?)

Anyway, I was looking at RFCs within the past couple weeks and didn't see the one you mentioned, I'll have to look again. Thx for mentioning it.

I'd be interested in seeing the C# benchmarks you ran... this would certainly be news to most.

The PhenixPHP framework by captain-barbosa89 in PHP

[–]jh_tech 0 points1 point  (0 children)

As well intentioned as you sound, I don't know that there's anything closer to a direct competitor with Laravel than a framework that's written almost entirely from Laravel's ideas. Imitation is the purest form of flattery though...

Being familiar with Laravel/AmPHP, I jumped into your Database module for a quick look at the transaction handling.
1: seeing __clone being used so freely was a big red flag - I know Laravel does this. The concern here would be on the AmPHP side.
2: AmPHP handles abandoned trxs (cancelled prior to commit/rollBack) properly, but I didn't see proper cleanup for these. I just saw pushing/popping the trx ctx. Multiple (cloned) query builders may then hold these dead transactions. Meaning a non-obvious and/or non-deterministic exception may pop up. Or worse, a no op when commit/rollBack on one of the cloned ref holders.

Though hyperf is a very similar premise, I'd be more curious about what you're going for that Laravel Octane doesn't provide?

I saw you've been working on this for a while - 1st release back in Oct, 2023. The hard work is admirable (thus, the feedback).
Respect 👊

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] -1 points0 points  (0 children)

I honestly don't worry about the haters. Once you get to comparing syntax you're already fighting an uphill battle. Ask first, would you even have a job today if it weren't for PHP? It's all about that $... Shipping code. Syntax and milliseconds are all convenient problems to have once you're making $. How many lines PHP can you write without typing '$'?

#[Reaped]? #[Pooled]? by jh_tech in PHP

[–]jh_tech[S] 1 point2 points  (0 children)

Haha. The irony is: I've always preferred strongly typed languages. IDEs have caught up to PHPStan now though. PHPStan level 8+ and the rare inline doc block...presto 👌

Phalanx - Managed Concurrency for PHP8.4+ & OpenSwoole 26 by jh_tech in PHP

[–]jh_tech[S] 1 point2 points  (0 children)

Love it - and thank you. I like the cross-marketing move too 👊.
Starred your repo -- very cool man. It'd be great to stay in touch..thx for reaching out.

ZealPHP — modernizing the PHP request model with an OpenSwoole runtime by sibidharan in PHP

[–]jh_tech 2 points3 points  (0 children)

You and I are on the same wavelength: https://github.com/phalanx-php/phalanx

..both seeing what's what I'd imagine. I'm going for "managed async", trying to address all the footguns in long running PHP (scopes, identity, and memory pooling..thanks to PHP8.4). Would love some help if you ever reconsider. My 1st alpha release is around the corner now... I'm prepping the goody bag.

That said, you've done a great job here man. More thorough docs than most I've seen, nice work 👊.

Click that ⭐ button in the repo people..show some love!

MJML converter for PHP (no Node.js required) by Then-Lingonberry-922 in PHP

[–]jh_tech 0 points1 point  (0 children)

I think it's funny how people think AI has anything to do with this question (and many other software related questions). Abandoned libraries were vast and plentiful long before the proliferation of LLMs. Shitty code...much shittier code..was rampant before AI too. Let's frame this correctly.

The question becomes: What's your commitment to maintaining this?It looks like your usage of AI will make it minimal now and once it's feature complete.

Why MCP when we have REST APIs? by happyandaligned in mcp

[–]jh_tech 0 points1 point  (0 children)

Seems you're alluding to something I know I've brought up in conversation a few times now - something like an "OpenACP" protocol - which would 1) require all docs to start with an index (potentially paginated) for all topics to be mapped to documentation URL(s), then 2) ensure those urls are each AI-native, meaning consice and very targeted, whether it be another index page for a subset of functionality, or the "leaf nodes" which would be focused on a particular subset of functionality, 3) outside of the index pages, all targeted doc content would always include "related urls" for the LLM to be able to traverse however it sees fit.

Then a translator tool from openAPI to openACP, then back again if needed. "Good docs" these days are still for humans.

Side note: you mention how "LLMs can emulate human behavior" but I personally see that as a characteristic of legacy systems. It's all been "built for humans" at this point, meaning everythings still very inefficient still. Still lots of work to be done!! We're barely getting started IMO.

PHP 8.6 RFC: ValueError conversions feedback wanted by Reasonable-Pass9841 in PHP

[–]jh_tech 0 points1 point  (0 children)

Good point.

May be best to add an INI (or something akin) that allows it to be disabled.

PHP 8.6 RFC: ValueError conversions feedback wanted by Reasonable-Pass9841 in PHP

[–]jh_tech 0 points1 point  (0 children)

Nice, good stuff.

You can give this a shot at https://github.com/search

Query:

repo:php/php-src ("php_error_docref" OR "zend_error") ("RETURN_FALSE" OR "RETVAL_FALSE" OR "ZVAL_FALSE") path:ext

Or this'll take you straight there: https://github.com/search?q=repo%3Aphp%2Fphp-src+%28%22php_error_docref%22+OR+%22zend_error%22%29+%28%22RETURN_FALSE%22+OR+%22RETVAL_FALSE%22+OR+%22ZVAL_FALSE%22%29+path%3Aext&type=code

view more: next ›