In PHP, constants can only be of simple data types like strings or floats.

You can't make a database connection a constant because it's not a simple data type.
That makes the only way of accessing complex "constants" within functions using the keyword global... which is not encouraged and forces you to make the database connection global (that may not be convenient in some software patterns).
The last option is passing the database connection as a parameter (either to the function or to the constructor of the instance whose methods will use the connection)... which would be good if I didn't want to go full OO. Because it's a pain to do so.

So all in all, constants are not well supported by PHP.
Come on, constants...

The weirdest quirk is really PHP itself

Very little is well supported in PHP. 😋

@Root They are making progress though.

In most languages constants have to be a value that can be defined at compile time. Instances are not that by most definitions.

@SortOfTested Wow I had never dealt with a language that's like that.

Constants in PHP are also global, so it's the same shit as doing "global $fakeConst;". So your point about global does not stand. If you dont want to use global, pass the connection. (Class consts are not global though.) Also, using "global" is better than using constants in my opinion, as it doesnt hide the dependency of the method, like using constants does (passing also doesnt hide).

Second, how is passing an connection object to a class constructor not OOP? In actuality, it is a foundation of some of the OOP practices.
Maybe you can keep it as a property in one class that handles all the database stuff, and avoid passing it as an argument, and having DB actions in multiple classes.

C/C++ is an example of literal constants, and many other languages... so it is by no means anything strange. It is actually the norm.

@Quirinus you said it.
Almost every OOP project I've worked with has a DB class and queries are built in there respective classes then thrown at the db class to parse and do what it has to do to return the result/resultset.

Keeps the "global" issue out of the equation as the DB class is standalone and maintains its own connections.

I have also seen the session handler be utilised for storing the db connection object and that being passed down to the db wrapper to deal with, but that can lead to its own issues.

@c3r38r170

The constant is suppose to be an immutable compile time value anyway, a db connection can change with the new resource when a reconnect occurs, meaning this is not a compile time event but a runtime event.

PHP is very forgiving, but I'm getting the feeling your trying to abuse the constants to avoid using global variables or dependency injection.

And how can you not use OOP in PHP? This isn't 2003 anymore... granted I have a php5 project around somewhere, but 5.6+, any any new project should be on 7+ anyway, so this gives you namespaces and the likes to go as OOP as you can.

@Root true, but I make it support it anyway 😏

Namespaces are a thing since PHP 5.3, there's dependency injection, there's static variables/functions, there are singletons, and even if you choose to ignore all that, constants can also hold arrays and non primitives are passend by reference,

@Quirinus That's why I make something a constant if it's constant, to facilitate access from places where otherwise I would have to use global.
Also, yeah I forgot the "database connection" is actually a database class, and I don't use many classes but I bet it may be inconvenient for some projects.
Finally (hehe) yeah, I've been since told that that's the expected behaviour of constants, but I had never read it anywhere and no language I know behaves like that except PHP. My bad.

@C0D4 Don't worry, I'm not abusing of them I have just a couple of couples.
However, I may start abusing of namespaces now you say...

To be fair, a lot of languages need global constants to be determined at compile time. That isn't really a PHP quirk.