magento-lts icon indicating copy to clipboard operation
magento-lts copied to clipboard

Replaced hard coded "new" object creation with Magento friendly way

Open woutersamaey opened this issue 5 years ago • 15 comments

Replaced hard coded "new" object creation with Magento friendly way, allowing other modules to rewrite these objects.

woutersamaey avatar May 20 '20 10:05 woutersamaey

Please use @deprecated only for classes, which are intended to get removed completely, not as a workaround to mark direct instanciation.

Also for reviewers: check usage is only changed, where magento is already loaded, there are probably uses where this will fail now, because magento is not loaded yet.

Flyingmana avatar May 20 '20 12:05 Flyingmana

So I remove the @deprecated word?

woutersamaey avatar May 20 '20 14:05 woutersamaey

yes, please :)

Flyingmana avatar May 20 '20 15:05 Flyingmana

I removed the 3 @deprecated words

woutersamaey avatar May 20 '20 15:05 woutersamaey

Also for reviewers: check usage is only changed, where magento is already loaded, there are probably uses where this will fail now, because magento is not loaded yet.

I dont sse problems with changes inside app/core/Mage, but there schould be no calls to Mage:: inside lib/Varien ...

sreichel avatar May 20 '20 23:05 sreichel

Thanks for the PR!

Can you explain the use case for this in more detail?

Also, did you consider that you can override any class file by dropping classes with the same name into app/code/* directories (due to ordering of include paths)?

My thinking is that the lib/Varien files are utility libraries (akin to the Zend libs) and not really meant to be extended with new user-specific functionality like the models and blocks are, and if there are bugs or lacking features it is best to just submit fixes/improvements to the core code rather than override them. And if you must override them or can't wait for a PR to be merged there is always the copy/modify option with the include path.

colinmollenhour avatar May 21 '20 14:05 colinmollenhour

We have created a module that uses Amazon S3 as primary media storage without using the media dir on the disk. Other modules have S3 or other storage options too, but in our case the media dir is completely empty.

To build this, we had to dig deep in Maganto and found these models to be not easily rewriteable.

You’re right about the include path etc, but I would prefer Magento to load models in the same way, as Magento tells us to do. Why the ‘new’ keyword is used at all seams to break Magento’s own rules without valid reason.

So I can understand your workaround, but my thinking was to have an easy and clean solution that does not need any workarounds.

I’d even endeavor to remove all uses of ‘new’ as much as possible. Let devs rewrite any and all models they like.

I understand Varien is a lib, but Magento always extends lib files and then uses these, while also loading them the Magento way. Some examples here are the Zend_Db classes. These (and others) are all wrapped in ‘Mage_’ classes.

So hope you like this PR. There is always an alternative, but my goal is following best practises even when Magento forgot their own rules.

woutersamaey avatar May 21 '20 15:05 woutersamaey

Thanks for the additional detail. You make a good case and I think I am more convinced than before so no objections.

As an aside, any chance your S3 module will be open-source? :)

colinmollenhour avatar May 21 '20 16:05 colinmollenhour

The S3 module actually needs more core edits, but it's very hard for me to post them here and get everyone to agree on them. So, let's first try to get this one in...

woutersamaey avatar Jun 19 '20 09:06 woutersamaey

This kind of change has a significant risk of introducing some side effects. Maybe we are missing some api or event which would make the whole architecture of your extension clearer and you would not need to override core classes any more?

Can you describe implementation details of your change?

tmotyl avatar Jun 20 '20 06:06 tmotyl

@luigifab I fixed these few nit-picks

woutersamaey avatar Sep 16 '21 07:09 woutersamaey

I love how @luigifab is our syntax police (I really do, that's not sarcastic) :-)

fballiano avatar Sep 16 '21 07:09 fballiano

We should use PHP CS Fixer for these nit-picks. Devs really have better things to do imo.

woutersamaey avatar Sep 16 '21 07:09 woutersamaey

From what I understand this PR comes as a proposal to solve a particular situation encountered in Magento. At first glance, the changes are made correctly, but what are the implications in the wrong sense?

If this PR will be merged I would change the phrase bellow is by removing the comma:

Instead of creating instances using "new", use Mage::getModel('core/varien_file_uploader')

addison74 avatar May 28 '22 19:05 addison74

Are the changes to lib/Varien required if you use your added wrapper classes?

I agree with @sreichel that it's very weird to see Mage:: in "lib/", is it absolutely necessary for some reason?

fballiano avatar May 29 '22 12:05 fballiano

I wouldn't have this in v20 only, it will create too many merging problems.

Also, there are conflicts to be fixed, I'm setting it to draft.

fballiano avatar Dec 19 '22 11:12 fballiano