We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Too many negative votes

This post has too many negative votes. The cause of this could be:

  • Irrelevant or controversial information
  • Confusing question or not a real question
  • Aggressive vocabulary, excessive rudeness, etc
  1. Home
  2. DI/IoC

OBSCURITY DETECTION: Why use auto getters and setters for out of the box functionality?

Hi, I see your statement on DI on the bottom of the page:

"Although you can register services with the names you want, Phalcon has a several naming conventions that allow it to get the the correct (built-in) service when you need it."

And then a rather large list of services that are accessible only through $di->get('...'), but have no dedicated getters and setters.

This makes it really hard to use IDE autocompletion, and obscurifies the options a developer has.

What is the reasoning behind this decision?

I have not looked into many other parts of the code, but I hope this decision does not obscurify many other parts of the framework as well.

15 1


21.8k

No getter and no setter because the DI is a general class that aims to incude any existing service, that means endless number of different service.

If you want to create a DI with getters and setters, the best way is to create your own DI that extends the phalcon DI on which you add some getters and setters with docblock for IDEs.

Phalcon tends to be general and doesnt want to limit to specific usage, the power of OOP will allow you to use your specifics needings.

by the way the default Phalcon controller is documented in the stubs (https://github.com/SneakyBobito/phalcon-stubs) and contains the base service for a base application ( $this->flash $this->view $this->response...)



1.6k

I disagree. Sounds like a typical developer answer, but without developer workflow insights. You provide out of the box functionality that is tied to the DI, and using plain 'get' to access that. Auto getters and setters can coexist next to explicit ones without problems. (I think you are missing the point of decoupling here imho). Now this functionality is made obscure and I have to jump to online documentation. Missed opportunity to make this framework more usable imo.

Nevertheless, great framework, and I always prefer purity over mess, but my point is valid and within proper OO architecture reasoning.

Thanks for being so responsive ;)



1.6k

Also, your reasoning is faulty, as you expect DI setter keys to point to implementations of your documented interfaces.

"No, you can't set the 'request' property to whatever you like on FactoryDefault, because it's reserved and used internally. We expect it to be of type bla."

Hoe consistent is that?

Seems flaky to me, but maybe you have better arguments to throw at it...



1.6k

Shame on your forum btw. I emailed these comments on your response yesterday, by responding to a forum-generated email. But it didn't put them on the site, which I didn't expect at all. I had to cut and paste them out of my email back into this forum :/

Obscurity again?