0

With a new feature in PHP 5.4, we can access a class member on the same line as instantiating the class.

e.g.

// Instead of
$obj = new myClass();
$obj->myMethod();

// PHP 5.4 allows
$obj = (new myclass())->myMethod();

I have a class which doesn't need the object (variable) from the instantiated class, because the class being instantiated is an exit controller and just "does some things" then halts the entire system.

I'd like to know if accessing a class member at the time of instantiating the class is ok without using the variable.

// With variable (standard practice)
$obj = (new myclass())->myMethod();

// Without using the variable
(new myclass())->myMethod();

Both code options work perfectly fine, but I've not seen this done without using the variable to store the object. And sometimes something can be done incorrectly from a technical or "best practise" standpoint but still work because of some unrelated reason (or luck etc).

So I would like to know if this is acceptable usage?
Or are there any "technical" reasons it shouldn't be done like this?

  • In your 'With Variable' example, the variable $obj will contain the return-value of myMethod() which isn't necessarily the object. – tkausl Jul 18 '15 at 0:05
1

It should be absolutely fine. You simply are not assigning the object to any variable and gets disposed of automatically.

BUT, I would look at larger scope issues here:

If you don't need an object, class(or method I guess in PHP) should be static instead.

// Static invocation
myClass::myMethod();
  • Thanks for the confirmation. Re the static alternative, surely then I'm just swapping my current approach, which is arguably not perfect given the scenario/usage, for an even worse scenario of shoving everything into global? I've worked hard (literally lost sweat and blood) to retain DI options and not pollute global. You are right tho, my current approach is kinda using classes for the sake. I might ask what best to do about that on code review. Cheers – James Jul 17 '15 at 22:32
  • @James A static class is still a class. A static class is the one that has no state variables, just like yours. Globals and Static is not exactly the same. – Alexus Jul 17 '15 at 22:35
  • I didn't mean "globals" I meant "global scope". There are other reasons why I'm avoiding static methods too. Testing, as I mentioned I use OOP and DI elsewhere, so a static class mixed with OOP becomes hard to manage. Also, is there a benefit? You mentioned "should be static instead" but I don't see the benefit really. FYI r.je/static-methods-bad-practice.html – James Jul 17 '15 at 23:25
  • It's rather, if your class is not an object, it's just not an object. Can't do anything about it, this it's static. Static classes have their place. If you just create an object to avoid having it in Global Scope, you are doing it wrong. – Alexus Jul 17 '15 at 23:33
  • My class has a constructor, and I inject dependencies into it, and the application has no static methods or singletons, so using one now isn't worthwhile IMO. I just don't need the object because the class is the system exit/halt controller, so nothing happens after it :) Maybe I do need to change the approach. – James Jul 17 '15 at 23:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.