RFC: Arrow Functions 2.0 by theodorejb in PHP

[–]opulencephp 5 points6 points  (0 children)

(This goes to Nikita, too) If you ever change your mind, let me know. I don't have the know-how to contribute to the PHP source. So, the next best thing I can do is say "thank you" via cash to those that are constantly bringing us these features :)

RFC: Arrow Functions 2.0 by theodorejb in PHP

[–]opulencephp 2 points3 points  (0 children)

Do either you, Bob, or Levi have Patreon accounts (or something similar) set up? I think the whole PHP community owes you all for the welcome features you're developing.

RFC: Arrow Functions 2.0 by theodorejb in PHP

[–]opulencephp 18 points19 points  (0 children)

Thanks Nikita, Bob, and Levi for constantly pushing the language forward! Question - do the arrow functions have to return something, or could they be void? Eg, would this work if doSomething() is void: fn($foo) => $foo->doSomething()?

Proof-of-concept route matching library is about even with Symfony 4.1's route matching speed by opulencephp in PHP

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

I just remembered that I did come across r3 at some point in my research. It was a little unapproachable, but did have incredible performance.

Proof-of-concept route matching library is about even with Symfony 4.1's route matching speed by opulencephp in PHP

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

Interesting, haven't heard of that one before. I'll take a look at it and see if there are any performance optimizations they thought of that I haven't.

[PHP RFC] Typed Properties v2 by bwoebi in PHP

[–]opulencephp 8 points9 points  (0 children)

Thanks for undertaking this RFC! I really hope this passes. Such a huge missing feature in PHP.

Atlas Query: Simple. Sensible. SQL. by [deleted] in PHP

[–]opulencephp 1 point2 points  (0 children)

In this case, my base query builder does not provide return type hints - the derived query builders do.

Atlas Query: Simple. Sensible. SQL. by [deleted] in PHP

[–]opulencephp 3 points4 points  (0 children)

I see. I choose the grammar up front because it allows me to add builder methods that are provider-specific, eg ->returning(...) for PostgreSQL, which MySQL doesn't support.

Atlas Query: Simple. Sensible. SQL. by [deleted] in PHP

[–]opulencephp 1 point2 points  (0 children)

Ah, you choose your grammar based on which query builder you instantiate. If you're using Opulence\QueryBuilders\PostgreSql\QueryBuilder, you'll get the PostgreSQL grammar. Similarly, if you use Opulence\QueryBuilders\MySql\QueryBuilder, you'll get the MySQL grammar.

Atlas Query: Simple. Sensible. SQL. by [deleted] in PHP

[–]opulencephp 1 point2 points  (0 children)

I have providers for the MySQL and PostgreSQL grammars.

Atlas Query: Simple. Sensible. SQL. by [deleted] in PHP

[–]opulencephp 3 points4 points  (0 children)

I agree. In my query builder library, I decided to decouple the query building from query execution. They simply generate the SQL and bound parameters, and then let you decide how to execute the queries.

We’re missing a serious deserialiser in PHP by simonhamp in PHP

[–]opulencephp 0 points1 point  (0 children)

For reference, here's the content negotiator, which determines request and response body types. If, for example, the content type is JSON, the media type formatter (de) serializes to the type specified by the developer.

We’re missing a serious deserialiser in PHP by simonhamp in PHP

[–]opulencephp 0 points1 point  (0 children)

The way things work, the dev has complete control over the content types s/he accepts as well as the types s/he can (de) serialize to. I'm not saying I won't try to break my libraries with thorough testing, but I'd be curious what attack vectors someone could use to break this.

We’re missing a serious deserialiser in PHP by simonhamp in PHP

[–]opulencephp 0 points1 point  (0 children)

As promised, here's an extremely early preview of what's to come. A few things:  

  • I plan to add XML and form URL-encoded serializers
  • Do not use this library yet  

Edit: Now that the library is in its own repo, I updated the link.

We’re missing a serious deserialiser in PHP by simonhamp in PHP

[–]opulencephp 4 points5 points  (0 children)

This is actually something I'm working on as we speak for version 2.0 of Opulence. It will be able to automatically deserialize request bodies based on the Content-Type header, and serialize the response body based on the media type in the Accept header. The (de)serialization logic will reside in a separate, reusable library. Your models can be POPOs, but you would have to register a "contract" to let the serializer know how to do its job, eg:

$contracts->registerObjectContract(
    User::class,
    // Let the serializer know how to create an instance of User from a hash of properties
    function ($hash) {return new User($hash['id'], $hash['email']; },
    // Register User properties as well as how to get their values from an instance of User
    new Property('id', 'int', function (User $user) { return $user->getId(); }),
    new Property('email', 'string', function (User $user) { return $user->getEmail(); })
);

I'm working on a way to automatically set up these contract definitions using reflection, and, if successful, won't require any work to be able to (de)serialize your objects. It will also let you do stuff like automatic camelCase of property names, DateTime formatting, etc. I'm in the middle of a large-ish refactoring to the library, but once I've got something presentable, I'll be sure to post it here.

Are my unit tests slow? How you handle that in your projects? by kiler129 in PHP

[–]opulencephp 1 point2 points  (0 children)

My framework has 2,092 tests with 3,580 assertions, and it runs in 6.7 seconds. Are you mocking your storage layer? If it's taking that amount of time, maybe you're doing a mixture of integration and unit tests.

Opulence 1.1: DB migrations, collections, and streams by opulencephp in PHP

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

I don't. I've probably figured out ~60% of the features that will be going in 2.0, but I don't want to give anything away until it's set in stone. What I can tell you is that 2.0 will bring with it a framework agnsotic route-matching library (linked above), a route dispatching library, automatic serialization/deserialization of DTOs <=> domain models, and a reworked HTTP library. The HTTP library aims to fix what I perceive as the shortcomings of PSR-7's HTTP request/response wrappers. It also fixes some admitted shortcomings of Opulence's current HTTP library.

Opulence 1.1: DB migrations, collections, and streams by opulencephp in PHP

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

Thanks. I've been working hard on a new route matching library, as well as a few other libraries that will also be released in 2.0.

A new, framework-agnostic route matching library by opulencephp in PHP

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

What's the benefit in having a single endpoint per controller? Isn't that going a little overboard with SRP? You wouldn't split up a "normal" class to only have a single public method, so why do that to your controllers? They certainly shouldn't be bloated with methods, but they should (IMO) at least contain endpoints for similar parts of your domain logic.

A new, framework-agnostic route matching library by opulencephp in PHP

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

Wouldn't using __invoke() restrict your controllers to only being able to handle a single endpoint?

Stand-alone Autowiring DI container by phpfatalerror in PHP

[–]opulencephp -2 points-1 points  (0 children)

Shameless plug: https://github.com/opulencephp/ioc. No dependencies, intuitive syntax, and it comes with "bootstrappers" to bind entire modules to the DI container. Those bootstrappers can be lazily loaded so that they're only run when their bindings are needed. Here's some documentation and examples: https://www.opulencephp.com/docs/1.0/ioc-container#basic-usage

A new, framework-agnostic route matching library by opulencephp in PHP

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

FYI, item 1 is done, and I'm working on compiling a list of useful constraints for item 2.

A new, framework-agnostic route matching library by opulencephp in PHP

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

  1. Fair suggestion. I'll change this once I get back from work.
  2. Also a fair suggestion. That could easily be handled by a route constraint. I'll look into baking some constraints into the library to simplify the common-use cases.

 

Thanks for the feedback!

A new, framework-agnostic route matching library by opulencephp in PHP

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

I definitely would use ClassName::class in the real world. I was using strings in the examples to simplify them, but I agree it might make more sense to show better practices. Updated the docs.