Overloading and where/why to use it.

[ballhogjoni]

Hey guys, not sure if this is the correct place for this topic, but I was wondering why you would use overloading? I just haven't ever come across a need for it and if I have I haven't recognized it.

[requinix]

Overloading as in multiple methods with the same name but different signatures (argument lists)? Checking because we're mostly PHP here and PHP does not have overloading.

[ballhogjoni]

On 12/4/2020 at 4:43 PM, requinix said:

Overloading as in multiple methods with the same name but different signatures (argument lists)? Checking because we're mostly PHP here and PHP does not have overloading.

Hey @requinix, thanks for the reply. According to the docs you have property and function overloading...see docs. For me I don't see the need to do something like this property overloading:

class A {
	$x = 123;
}

$var = new A();
$var->abc = 456;

 

[requinix]

Okay, yeah, that's not really "overloading" as the rest of the software industry calls it. I didn't even remember PHP called it that.

Creating properties and methods dynamically like that isn't a great practice, even if it is somewhat common in PHP. It can create unusual behaviors that are hard to debug. Try to avoid it.

However, using __get/set/isset* as a means of accessing fake properties is alright. It's mostly a matter of using the -> syntax as shorthand for something else.
Consider a Config class that loads data from a file. The pure OOP method of accessing that a value "foo.bar" would be like $config->get("foo")->get("bar"), but you could repurpose the -> operator for properties to allow $config->foo->bar. Neither "foo" nor "bar" should be defined as properties on the object because they're dynamic, so you implement __get to behave the same way as a get() method. In fact, very often a Config class will have both and __get calls get() - mostly because get() tends to support a default value, which you can't supply through ->.

__call is similar in that you might need to call fake methods, but it's less common and I avoid using it. Methods are basically never the sorts of things that should be done dynamically and should only happen in rare cases, none of which come to mind right now.
__callStatic is even rarer and is pretty much only for static singletons.

* If you implement one of those then you should implement all three of them: __get and __isset are an important pair because getting values often includes checking if it is set first, and __get and __set should be a pair to keep consistency with how someone may use the -> operator (even if that means, for read-only objects, that __set always errors).