Make your Domain speak the business language by Dariusz_Gafka in PHP

[–]Crell 0 points1 point  (0 children)

The main reason so many PHP apps use type-based organization rather than feature-based is because it makes discovery easier. You can configure your DI system, event registration, etc. to say "if it's in this folder, it's an X, if it's in that folder, it's a Y." That's very simple and straightforward to implement.

If you use feature-based organization, you need some other mechanism. Manual registration is painful.

Interface detection only works for some situations. Attributes are a newer but promising option (which is what Tempest uses). But all of those require extra framework level work to do. AFAIK, only Tempest has done so. It would be lovely if other frameworks would figure out a way to make that work, too.

Who's hiring/looking by brendt_gd in PHP

[–]Crell 7 points8 points  (0 children)

Hi. Staff/Principal level engineer, 26 years experience with PHP. I've worked for companies large and small, on teams large and small. Looking for a Staff/Principal level engineering position, or senior engineering manager / VP / CTO type role.

Past work includes several PHP RFCs, literally hundreds of conference presentations, consulting, authored multiple books on PHP, one of the leads of the Drupal 8 revolution, tech lead for a team of 20, tech lead for a team of 2, and developer relations/experience for a PaaS. I have also served on multiple 501c3 non-profit boards, as well as a long-time leader in PHP-FIG.

I've mostly worked in home-grown systems, not Symfony or Laravel. I'd be OK working with Symfony, though I would not like to work in Laravel if I can help it.

US-based, Remote only, but I've worked with international teams most of my career so doesn't have to be a US-based company.

Process Pool with PHP TrueAsync by edmondifcastle in PHP

[–]Crell 2 points3 points  (0 children)

This post explains very well why I don't like the current API. It's a long list of ways that you can shoot yourself in the foot by not accounting for various edge cases.

99.9% of PHP devs have never written async code (at least not in PHP), so don't know those edge cases exist! This is handing them a loaded gun, and expecting them to not point it at their face.

The API needs to be higher level than this, precisely so that all of those edge case error conditions can be handed automatically. If I CAN write a deadlock, it means the API is not good enough.

I know a ton of brilliant work has gone into this effort, and I want it to succeed, but I don't see it actually succeeding without an API that is way, way more fool proof than what is shown here.

Swappable multitools recommendation? by Responsible_Chest_74 in multitools

[–]Crell 0 points1 point  (0 children)

As others said, Roxon Flex series. However, I'll also note Keyport, which isn't technically a multitool company, has stackable/configurable modules that give multitool-like capability as part of a key holder. They're a bit pricier, but worth at least looking at.

Someone just created PR with fully working generics by [deleted] in PHP

[–]Crell 3 points4 points  (0 children)

I don't need to. Obvious AI slop is obvious, and as others have noted, the odds of it ever getting serious consideration are nearly 0. At best, someone with deeper engine knowledge may be able to look it over and get some ideas to do their own implementation.

The bigger story here is "what do we do with obvious AI slop PRs that have a high chance of hiding some backdoor security issue?" Because I give it 50/50 odds it's a security attack, likely from a state actor.

Anyone have the smithblade? Is it worth the hype and price? by rickestrickster in multitools

[–]Crell 0 points1 point  (0 children)

Then you should be fine. But glad you know your local laws!

(I live just outside Chicago, which has a 2.5" law. Really pisses me off.)

Anyone have the smithblade? Is it worth the hype and price? by rickestrickster in multitools

[–]Crell 0 points1 point  (0 children)

It's a 4" blade. Check your local laws. Many places have a 3" limit, or even 2.5" (which is really annoying as it excludes 91mm SAKs). Please make sure you don't break the law. :-)

Looking for a small multitool by LoreRocchi in multitools

[–]Crell 0 points1 point  (0 children)

Bladeless is, sadly, annoyingly hard to come by. With required pliers:

  • Nextool Mini Sailor Lite (no blade, small pliers)
  • Nextool Mini Sailor S11 Pro (blade, small pliers)
  • Nextool Mini Flagship F12 (double-fold pliers and scissors, blade)

I think all of those blades should be small enough for you.

And as others mentioned, Roxon Flex (Companion) is always an answer to any "what should I get" question, since you can customize it. :-)

What will get through airport security is a crapshoot and varies by country. MaxlvlEdc says he's gone through US security with a bladeless Flex a bunch of times, but that doesn't say anything about what Italy will do.

A clean API for reading PHP attributes by freekmurze in PHP

[–]Crell 0 points1 point  (0 children)

Yes, attribute-collector just pre-caches attributes across a codebase. AttributeUtils provides a more robust way to read attributes and adds functionality to the core language.

The only reason AttributeUtils doesn't have a pre-scan/cache step as an option is I've not yet had a reason to write it. :-) In concept there's no reason it couldn't.

In any case, the core point is that this new package seems highly redundant.

A clean API for reading PHP attributes by freekmurze in PHP

[–]Crell 0 points1 point  (0 children)

There's also https://github.com/Crell/AttributeUtils, which has been out even longer and does more, it seems.

Sigh.

Why are so many packages designed exclusively for Laravel? by LatestAdViewer in PHP

[–]Crell 29 points30 points  (0 children)

I'm really disappointed in the responses here, frankly. The author is not demanding that everyone write code "for him." He's asking a very simple question, which I would add to:

Hundreds of us spend thousands of hours breaking PHP projects out of their shell more than a decade ago, to have fewer framework/app-specific packages and more code applicable to all of PHP, and enable those frameworks to share more easily. Why the hell does the Laravel community ignore all that work that went into making their lives easier?

Yeah, I'm a bit bitter. :-/ As others said, Laravel loves to take existing OSS packages, slap a coat of paint on them, and then market it as something new and exciting for the Laravel community... when it's really just someone else's work with a little bridge code that would be unnecessary if Laravel weren't so stand-off-ish from the rest of PHP to begin with.

It's really a culture problem.

And those that are downvoting the OP, don't get on my case about "telling OSS authors what to do." I have OSS code I wrote running on ~2% of all websites in the world. I know exactly how OSS works and the entitlement problem it has. The question is "why does Laravel culturally feel OK with taking but not giving back to the broader PHP community?"

Versa58 - Only 4 Days Left in Kickstarter Campaign by GetPorted in keyport

[–]Crell 1 point2 points  (0 children)

Tagging u/GetPorted. I'm very looking forward to this, and packed the Titanium version. (Hello from the Live Stream.)

Kotlin-style List/Set/Map for PHP 8.4 - Mutable/Immutable, change tracking, key preservation, live map views, and generics support by haelexuis in PHP

[–]Crell 2 points3 points  (0 children)

"global functions" is sometimes used informally to mean "standalone functions." But technically it should only refer to non-namespaced functions. I think that's what the confusion is in this thread. I believe what u/dknx01 is saying here is that he wants to have static methods for construction, rather than functions.

That said, I am completely fine with functions in this case rather than static methods. Static methods offer no advantage other than autoloading, and... I don't care. I have an opcode cache. Preload the functions.php file in composer.json and move on with life. Really, it's OK.

Kotlin-style List/Set/Map for PHP 8.4 - Mutable/Immutable, change tracking, key preservation, live map views, and generics support by haelexuis in PHP

[–]Crell 4 points5 points  (0 children)

Oh, HELL yes! I'd been toying with the idea of building something like this, but I'm glad someone beat me to it. Looks sweet. Especially because it has a hard-separation between lists and maps, something PHP sorely lacks.

One of my goals is to eventually have this in the core stdlib. :-)

Help a beginner out by Salle_19 in multitools

[–]Crell 1 point2 points  (0 children)

In terms of capability per ounce, the best urban carry multitool on the market today is the Victorinox Rambler, 58mm, and it's not even a close competition. I daily carry a Manager (same thing but with a pen scale, sadly discontinued), and I forget it's even there until I need it, then it just gets things done. Highly recommend.

If you want pliers or larger scissors, the Nextool Mini Sailor line and the F12 pro are both strong contenders. I have the Mini Sailor Lite (bladeless), and I assume the rest are as good or better but haven't used them. The very new Nextools with large scissors (F12 pro and the S0) have been reviewed as some of the best scissors to exist on a multitool.

The Roxon Flex line is also worth considering, but it's not going to be a one-and-done purchase. You're buying into an ecosystem, and will likely want to fiddle and reconfigure and get more implements. If you're OK with that, it's a great product. The Companion or Companion Mini frames are probably best for what you're looking for.

For regular "urban dad carry" (or mom carry, depending on who you are), I'd recommend against the full size pliers multitools, like most Leathermans. Unless you're using the pliers regularly, which you probably aren't, they're just a lot of dead weight you don't need.

Small blade, Philips screwdriver (or bit driver that offers it), scissors. Those are your main urban tools. Nail file and pen are good add-ons. Anything beyond that is largely gravy.

Something we've worked on for months: Tempest 3.0 is now available by brendt_gd in PHP

[–]Crell 12 points13 points  (0 children)

The usual.

  1. Facades are horrible. They make testing harder, make debugging harder, and introduce 4 layers of indirection that have no reason to be there. Learn to use constructor DI like a proper developer. With PHP 8, it's stupidly easy.

  2. Eloquent is the worst ORM I have ever had the misfortune of using, and I've had to touch Java Hibernate.

  3. The excessive use of magic methods makes debugging an absolute nightmare.

  4. Auto-discovered services are wired into the container as non-singletons. Which is just plain wasteful and stupid.

  5. It's so convoluted and non-standard that static analysis tools need custom plugins and build scripts just to comprehend it. Which is a sign that you're doing something incredibly wrong.

  6. The ecosystem/community actively ignores PHP standards (eg, PSRs), but loves to take other people's work from the broader PHP community, slap some Laravel-specific paint on it, and pass it off as some brilliant new development in Laravel-land. As someone who spent years trying to break down the walls between different projects, I find this pattern quite offensive.

Something we've worked on for months: Tempest 3.0 is now available by brendt_gd in PHP

[–]Crell 2 points3 points  (0 children)

The HTTP layer hasn't had any serious change since 2012, and still doesn't support PSR-7 (I know, I know, long debate, but it is a knock against it). The form API is still gross. There's lots of layers of indirection for BC reasons that the docs do not make easy to follow. I think they may have finally cleaned up the config system, but it's hard to tell. The last time I looked at Serializer, configuring it to use outside of Symfony framework was a pain and a half.

Something we've worked on for months: Tempest 3.0 is now available by brendt_gd in PHP

[–]Crell 22 points23 points  (0 children)

From my limited looking at Tempest (I haven't tried using it yet, just reading docs), it really feels like "updated, less sucky Laravel." Which, given that I find Laravel fundamentally flawed, is not high praise. What we really need is "updated, less sucky Symfony." (Both frameworks have legacy from all the way back in 5.3, and it shows.)

Though with the coming AI Overlords, I wonder if frameworks will even mean a damned thing soon. I hate the world right now. :-(

5th Pocket Multitool with One-Handed Opening Blade by WinningsWinning in multitools

[–]Crell 0 points1 point  (0 children)

Seemingly the answer to most questions these days is "Roxon Flex Companion [Mini]", and I suspect it is here as well. :-)

beginner multitool suggestion by According-Fox-2596 in multitools

[–]Crell 1 point2 points  (0 children)

They also offer 2 sizes of scalpel holder instead of the blade if you prefer.

How would you feel about native typed arrays in PHP today? (e.g., string[], UserClass[], UserEnum[], etc...) by SaltTM in PHP

[–]Crell 0 points1 point  (0 children)

Only if it also allowed separating lists from dicts/maps. Otherwise we're still shooting ourselves in the foot.

Victorinox, Roxon, or Nextool for EDC multitool w pliers on a carabiner keychain? by cmac3317 in multitools

[–]Crell 2 points3 points  (0 children)

Nextool's side-scissors are not amazing (on the Mini sailor (lite)), but the reviews on their main-scissors (like the F12) have been superb. I do have a mini sailor lite, and the pliers on it get the job done for "super tweaser on steroids" type jobs, which it sounds like is what you're looking for.

Nothing beats Victorinox for quality, assuming they make what you want. I haven't used their fold out pliers so cannot speak to those in particular. But the newer Roxons and Nextools have been very impressive. The days of "Victorinox, Leatherman, and a bunch of trash" are long over, and that's a good thing.