Yet another post object wrapping 03

Thinking about how I’d like to find posts.

A working but incomplete first iteration

I’ve played around with the first iteration of the post wrapper and was satisfied to a point.
This purpose of this first iteration was to plan the next one and, in this context, version 0.1.0 did succeed.

What’s missing?

Much of course but I will make a concrete example.
A note: this whole class system of post “augmentation” has its reasons fulfilled when used in custom WordPress installations (or plugins or themes) thar are not relying on default WordPress instantiated loops and vars; in the case below I’m using the wp-routes plugin to handle the displaying of a single page.

add_filter('wp-routes/register_routes', function(){
    respond('GET', '/[:slug]', function($request){
        $page = get_page_by_path($request->slug);

        // not found, next route
        if(!$page) {return false;}

        // `tad_PageRepository` extends `tad_PostRepository`
        $page = tad_PageRepository::create($page->ID);

        // do something with the page data
        <h1><?php echo $page->post_title; ?></h1>

        // ...
    });
});

What’s happening is that I’m querying the database for a WP_Post object using the get_page_by_path function, using a single property of that object to identify and create another object, a tad_Post instance, in the $page = tad_PageRepository::create($page->ID) call.
The second query to the database, the one sprung by the tad_PageRepository::create method, will hit the cache but still it’s a computational overhead that should be avoided.
What’s missing is something evolved ORMs like Laravel Eloquent or Doctrine ORM offer: flexible find functions.
Ideally I’d like to have a function like this in my arrow

add_filter('wp-routes/register_routes', function(){
    respond('GET', '/[:slug]', function($request){
        $page = tad_PageRepository::find('first', array(
            'post_name' => $request->slug)
        );

        // not found, next route
        if(!$page) {return false;}

        // do something with the page data
        <h1><?php echo $page->post_title; ?></h1>

        // ...
    });
});

Possibilities

Possible more finding possibilities are to query the posts repository the same way a WP_Query object could be initialized

// take the same query args as a `WP_Query`
$posts = tad_PostRepository::find('all', array('connected_type' => 'related', 'connected_items' => 23));

Allow for the use of meta values and terms in “transparent” ways

// allow for the use of meta properties
// `color` is a meta value, `category` is a taxonomy
$posts = tad_PostRepository::find('all', array('color' => 'red', 'category'=> 'new'));

Allow for the ad-hoc inclusion of other related objects

$posts = tad_PostRepository::find('all', array(
       'color' => 'red',
       'category' => 'new',
       'include' => array('author', 'comments', 'related');
    ));

that should allow for code like this to be written

foreach($posts as $post){
   $title = $post->post_title; // nothing different here 

   // `$post->author` is a `WP_User` object
   $author_name = $post->author->last_name . ', ' . $post->author->first_name;

   // `$post->category` is a term object
   $category_name = $post->category->name;
   $category_description = $post->category->description;
}

I will come up with more desirable use case and scenarios along the way.

Next

Iteration 2 will concentrate on the tad_PostRepository::find metodd and its possibilities. Ample inspiration from the two framework implementations above will be taken.

I appreciate your input