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

Drop PHP 5.3 support #18

Merged
merged 5 commits into from
Dec 21, 2023
Merged

Conversation

mvorisek
Copy link
Contributor

@mvorisek mvorisek commented Mar 14, 2022

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

@mvorisek mvorisek marked this pull request as draft July 11, 2023 06:23
@AllanJard
Copy link
Contributor

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 mvorisek closed this Jul 11, 2023
@mvorisek mvorisek deleted the drop_php5_support branch July 11, 2023 18:47
@mvorisek mvorisek restored the drop_php5_support branch December 9, 2023 01:16
@mvorisek mvorisek changed the title Drop PHP 5.x (already broken) support Drop PHP 5.3 support Dec 9, 2023
@mvorisek mvorisek reopened this Dec 9, 2023
@mvorisek
Copy link
Contributor Author

mvorisek commented Dec 9, 2023

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.

@mvorisek mvorisek marked this pull request as ready for review December 9, 2023 01:21
@AllanJard AllanJard merged commit 6673f4e into DataTables:master Dec 21, 2023
15 checks passed
@mvorisek mvorisek deleted the drop_php5_support branch December 21, 2023 15:23
@AllanJard
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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

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

Successfully merging this pull request may close these issues.

2 participants