DataTables / Editor-PHP

PHP server-side libraries for Editor
Other
35 stars 22 forks source link

Drop PHP 5.3 support #18

Closed mvorisek closed 11 months ago

mvorisek commented 2 years ago

DataTables\Ext::inst() is kept, but deprecated.

AllanJard commented 1 year ago

Annoyingly PHP 5 support is still required for some. It should be working again with 5.4+ as a result of a change last year. I'll try it when I get into the office, but this one likely won't get merged in.

mvorisek commented 11 months ago

PR reworked, PHP 5.3 is EOL many years, so the support should be possible to drop in favor of better maintenance and php features.

AllanJard commented 11 months ago

Thank you for this. I agree it is past time to drop 5.3 support. I have however removed the @deprecated flags from Ext::inst and Ext::instantiate. I actually prefer the syntax of:

Editor::inst( $db, 'datatables_demo' )
    ->fields(
        Field::inst( 'first_name' )
            ->validator( Validate::notEmpty( ValidateOptions::inst()
                ->message( 'A first name is required' ) 
            ) ),

Than needing to surround the newly constructed class in parenthesis:

(new Editor( $db, 'datatables_demo' ))
    ->fields(
        (new Field( 'first_name' ))
            ->validator( Validate::notEmpty( (new ValidateOptions())
                ->message( 'A first name is required' ) 
            ) ),

Either option is perfectly valid and I don't plan to drop the inst static method any time soon.

mvorisek commented 11 months ago

Thank you for the feedback. In https://github.com/DataTables/Editor-PHP/blob/2.2.2/Editor/Upload.php#L61 the Field::inst was more or lesss already deprecated and present only to support chaining for PHP 5.3.

IMHO Field::inst is useless and implies a slighly worse design pattern, as in the end, the method does new .... So with new, it is easier to read the code. The deprecated PHPDoc does not hurt (it is a comment, users can still use it) and with https://github.com/phpstan/phpstan-deprecation-rules PHPStan was/is able to recommend to use the new ... syntax to maintain consistent code with new ... only.

AllanJard commented 11 months ago

Yeah, I take that point. The problem is I just can't see myself choosing to write code with those extra parenthesis - maybe I'd get used to them, but from other languages I'm used to new taking a higher priority than the chaining methods. And I don't really want to write deprecated code, so Editor::inst( ... ) it is unless there is a better way - can Editor( ... ) do an automatic new for example? I'm not sure how that would be done in PHP.

mvorisek commented 11 months ago

Editor( ... ) will imply strictly a function call, not class instantiation. new is hovewer very commonly used in PHP even /w the parentheses when chained.