Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update loader registration instances to support chain-able setters #50

Open
alexstandiford opened this issue Jan 22, 2022 · 0 comments
Open

Comments

@alexstandiford
Copy link
Collaborator

alexstandiford commented Jan 22, 2022

One problem with the method in-which inline instance creation works, is most IDEs have no way to know how to provide code hints for the arguments passed into the constructor. It would be nice if it were possible to register loader items using method chaining instead. This would make it possible to sanitize these items individually for children classes, and make the IDE provide the hints needed to actually set these up.

I personally find myself looking up the documentation to set up loader items all the dang time, and it would be nice if I didn't have to rely so heavily on the documentation to make sense of how to set these things up. I think a setter pattern would really help with this.

Current signature example:

underpin()->meta()->add( 'meta_name',  [
	'key'           => 'meta_key',
	'description'   => 'Meta description',
	'name'          => 'Meta Name',
	'default_value' => false,
	'type'          => 'post',
] );

Potential signature example:

underpin()->meta()->add( 'meta_name',(new Meta_Record_Type())
    ->set_key( 'meta_key' )
    ->set_description( 'Meta description' )
    ->set_name( 'Meta name' )
    ->set_default_value( false )
    ->set_type( 'post' ) );

This would provide a third way to register something. The array-based method, providing a class directly, and a setter-based method.

Some things to consider:

  1. The behavior of loaders is to make these values largely immutable. Once they're set, it shouldn't be possible to set them again. The setter-based method should work in this way, too, and there would need to be an easy way to ensure that these values, once set, can't be overridden afterward.
  2. This pattern would also make it possible to do something that's not currently possible - to set a loader value after something is registered. Would this be considered an anti-pattern? EG:
// Set most of the values on-registration
underpin()->meta()->add( 'meta_name',  [
	'key'           => 'meta_key',
	'description'   => 'Meta description',
	'name'          => 'Meta Name',
	'default_value' => false
] );

// Later on, after registration, set the type.
underpin()->meta()->get( 'meta_name' )->set_type( 'some_dynamic_type' );
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant