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

Allow to add() only an object #565

Merged
merged 1 commit into from
Jun 1, 2020
Merged

Allow to add() only an object #565

merged 1 commit into from
Jun 1, 2020

Conversation

mvorisek
Copy link
Member

@mvorisek mvorisek commented Apr 22, 2020

Plus fix #566

@mvorisek mvorisek force-pushed the require_obj_in_add branch 2 times, most recently from 2c5d874 to b8a7a4a Compare April 22, 2020 10:45
@mvorisek mvorisek changed the title Allow to add only an object Allow to add() only an object Apr 22, 2020
@codecov
Copy link

codecov bot commented Apr 22, 2020

Codecov Report

Merging #565 into develop will decrease coverage by 0.10%.
The diff coverage is 91.66%.

Impacted file tree graph

@@              Coverage Diff              @@
##             develop     #565      +/-   ##
=============================================
- Coverage      86.31%   86.21%   -0.11%     
+ Complexity      1236     1232       -4     
=============================================
  Files             28       28              
  Lines           2733     2727       -6     
=============================================
- Hits            2359     2351       -8     
- Misses           374      376       +2     
Impacted Files Coverage Δ Complexity Δ
src/Join.php 83.09% <0.00%> (ø) 32.00 <2.00> (ø)
src/Model.php 91.04% <100.00%> (-0.08%) 372.00 <9.00> (-4.00)
src/Persistence.php 78.94% <100.00%> (ø) 86.00 <3.00> (ø)
src/Persistence/Array_.php 91.66% <100.00%> (ø) 65.00 <8.00> (ø)
src/Persistence/SQL.php 75.38% <100.00%> (ø) 193.00 <7.00> (ø)
src/Persistence/CSV.php 76.61% <0.00%> (-1.62%) 50.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1de7593...48bf0db. Read the comment docs.

@mvorisek mvorisek force-pushed the require_obj_in_add branch 5 times, most recently from 6fd8216 to 606b30a Compare April 22, 2020 11:25
@mvorisek mvorisek marked this pull request as ready for review April 22, 2020 11:27
@mvorisek mvorisek mentioned this pull request Apr 22, 2020
Copy link
Member

@DarkSide666 DarkSide666 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Historically we used add('className') A LOT so this will be a big backward compatibility break :(

I would like to get @romaninsh input here.

*/
public function saveAs($class, $options = [])
public function saveAs(string $class, array $options = []): self
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BC break

*/
public function newInstance($class = null, $options = [])
public function newInstance(string $class = null, array $options = [])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will break compatibility. not sure if that's ok.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct, but to put this project in good shape we need it - as far as I remember these functions were used in a very few places.

@@ -65,7 +65,7 @@ public function testSaveAs()

$m = new Male($p);
$m->load(1);
$m->saveAs(new Female());
$m->saveAs(Female::class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that it's more logical to use class name here not object itself, but this change will break a lot of old code everywhere because historically we used add('className') A LOT :(

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So perfect then? :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said - it looks better, but will break existing projects (again) :(
Can you try to track down @romaninsh and ask what he thinks about this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DarkSide666 I reacted to this as you are writing:

because historically we used add('className')

and this method accepts now exactly this "string className" :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I guess I added comment in wrong place. It should be for all this PR.

  • add() will no longer support add(string $className)
  • saveAs() will no longer support saveAs(object $model)
  • newInstance() will no longer support newInstance(object $model)

I'm not saying that these changes are bad, but all and every of these are BC breaks...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and it should be documented like so. This prevents mistakes, allow strong typing and also help the developer to understant what is really does.

Imagine newInstance like new, you never want to allow new (new class())(), it is simply wrong.

@romaninsh
Copy link
Member

This would be one hell of BC break.

$foo->add(Some::class); is also extensively used.

We could depreciate this and target 4.0 :D

@mvorisek
Copy link
Member Author

mvorisek commented May 5, 2020

I may be, but as you have already written in Discord, there is a time to move forward and enforce right semantics. Currently the user base is not that great and I strongly advice to prevent bad usage as soon as possible.

I propose to create central page with changes, so these changes can be fixed according to that. That is an industry common practice.

@romaninsh what will be different in Atk 4.0? My answed: more users, more unwanted usage. Right?

Copy link
Member

@DarkSide666 DarkSide666 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this PR is huge BC break, but on the other hand @mvorisek you're right about

what will be different in Atk 4.0? My answed: more users, more unwanted usage. Right?

@@ -65,7 +65,7 @@ public function testSaveAs()

$m = new Male($p);
$m->load(1);
$m->saveAs(new Female());
$m->saveAs(Female::class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I guess I added comment in wrong place. It should be for all this PR.

  • add() will no longer support add(string $className)
  • saveAs() will no longer support saveAs(object $model)
  • newInstance() will no longer support newInstance(object $model)

I'm not saying that these changes are bad, but all and every of these are BC breaks...

@mvorisek mvorisek merged commit b6ecdc1 into develop Jun 1, 2020
@mvorisek mvorisek deleted the require_obj_in_add branch June 1, 2020 21:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants