Forums

What's the reason not to simplify some functions in the core?

Permalink
Can someone with more PHP experience explain something for me?

Here's a snippet of code from the core (Concrete\Core\Page)
public static function getCurrentPage()
    {
        $req = Request::getInstance();
        $current = $req->getCurrentPage();
        return $current;
    }

What is the advantage of splitting the code up into separate parts rather than combining it into one line, like this:
public static function getCurrentPage()
    {
        return Request::getInstance()->getCurrentPage();
    }
ob7dev
 
mnakalay replied on at Permalink Reply
mnakalay
Personally, I have a tendency to split up code that way as well. I feel it makes it clearer and if, for some reason, I didn't write comments or they're not clear enough, writing code that way makes it easier (to me) to understand it.

I have been called on that recently so I know it's frowned upon but old habits die hard.

I am also not aware of any "technical" benefit of doing it this way or the other. I think it's just a matter of preference.
ramonleenders replied on at Permalink Reply
ramonleenders
The advantage is readability. The downside is this uses slightly more memory, as you declare 2 variables, where you shouldn't be needing to declare any at all.
mnakalay replied on at Permalink Reply
mnakalay
I keep reading contradictory information about the real performance impact. Is it really that important? Even for a system as big as C5?
ramonleenders replied on at Permalink Reply
ramonleenders
You don't know it until you try it haha. But I guess the bigger the object and the more you call this function, it will take more memory and will mean your system is more easily "overloaded". Of course you can run some tests if you want to for a thing like this haha.
JohntheFish replied on at Permalink Best Answer Reply
JohntheFish
I thinks its just personal preference and perhaps history. I suspect both variants optimise out to a negligible difference in the number of instructions executed.

Both approaches, if taken to an extreme, lead to unnecessary obscurity.

The method chaining approach breaks down when something in the middle of a chain could return null (and hence a test is needed whether to continue). Typical are foreach on null errors.