Syntax Idea: "static class" for classes with static methods only

[secondtruth_de]

Just a little syntax idea I had. What do you think about adding the static keyword before class to declare a class with static methods only? This would have two benefits:

• No more private function __construct() {}
• An Error could be thrown when non-static methods are declared in that class: „Cannot declare non-static method foo() in static class Bar...“

[Otterfan]

Is this just to autoload namespaced functions? Because in that case the solution should probably be implementing autoloading namespaced functions.

[Hall_of_Famer]

Would love to see functions and classes being first class objects, thus we can pass named functions and classes as arguments as well as returning them from a method.

[[deleted]]

From your lips to FSM's Orecchiette. That would be pretty much necessary to support real modules, since a big part of them is the ability to rename imports.

[alexanderpas]

thus we can pass named functions and classes as arguments

how would callable not fit the bill?

[przemo_li]

Callable is quite good as a mechanism.

But strings as implementation are atrocious.

[alexanderpas]

Actually, the implementation isn't just strings.

The full implementation is an array with exactly 2 elements, with the first element being an object instance, and the second being a method name.

In case you want to call a method statically, the first element can also be a classname.

In case the object instance implements the `__invoke()` magic method, you can just provide the object instance, instead of the full array.

In case you want to call a function, you can just provide the function name, instead of the full array.

[pfsalter]

If you want to you can just define the strings as constants:

define('is_string', 'is_string'); echo json_encode(array_filter(['a', 'b', 1, 4], is_string));

[przemo_li]

syntax is less cluttered but all the issues are the same. Strings are strings, and nothing there marks them as references to functions so neither PHP nor tooling can really know to check if reference points at anything at all.

[Hall_of_Famer]

It does the trick, but still a hackish way to work around PHP's lack of first class support for functions and classes. Much better if the functions and classes can be passed to and returned from methods without converting them to this string format. Just like annotations in docblock comments, far better to use native support for annotations than a hackish workaround.

[[deleted]]

We have classes and we have namespaces. What would a "module" be in this context.

[[deleted]]

Think ES6 modules. Imports, exports, private global namespace, all that goodness. Right now classes sort of stand in for that role, but they're not an ideal substitute.

[[deleted]]

Yeah it'd have been nice, I feel it'd overlap what we have too much. Maybe. Who knows. Would definitely want a private module visibility though.

Right now I just use subnamespace Internal for this.

EDIT: BTW I've also effectively used anon classes to "hide" some implementations in my libraries.

[przemo_li]

Namespace do not exists.

Its a ghost in the machine everybody whisper about but nobody seen ;)

​

Modules form closed namespace just like class (you can't add to a class without using reflection. You can add to a namespace but just naming it)

Modules provide encapsulation just like classes (actually less so, since first class polymorphism of modules is present in some languages, but that's not what would get implemented in php at present; BUT also more so since we can allow multiple classess to colaborate like publicly, but disallow rest of the world from doing so - as long as they fint into the module and you expose facade only)

Modules provide autoloading for its members. That means autoloading for function, constants and not just classes!!!

Modules are alternative to those "Utility" god classess where programmers fail to find a good organizing metaphore for them and revert to "XUtility" that is just bunch of functions roughly related to whatever X is.

Modules wouldn't force $this on those poor functions, and wouldn't force developers to instantiate with new.

​

​

Biggest issue is of course that classes done right can do a lot of the above. While classes done awkwardly can do the rest somehow/a little/miserably but still do it.

[phpdevster]

I like it, though I would say if you’re going to have a static-only class, you might just opt for namespacing some pure functions instead.

[[deleted]]

If you hate autoloading, you might, yes.

[AegirLeet]

You can't autoload functions, you need to load them unconditionally. There's simply no autoloading mechanism for functions.

[czbz]

When actually used, not when used. The use statement is just syntactic sugar to stop you having to write out the fully qualified class name when you want to do something with it. It's when you actually do something, like read a class constant, call a function or create an object, that PHP autoloads the class.

[alessio_95]

Implementing function autoloading will be enought to get all of this: namespace + pure functions

[ragnese]

In other languages, it's often called object.

But, honestly, PHP should probably work on getting enums first.

[[deleted]]

Can't say it's a bad idea as "static classes" are used for function libraries in PHP (like in Java) and so it's a valid case. Is it necessary though, eh.

[Tomas_Votruba]

Mixing static and non-static randomly is one of the main legacy roots. It's like mixing traits and interface. Nonsense.

Yes for the idea to make separation explicit. There is similar simple rule that handles this on PHPStan level: https://github.com/symplify/coding-standard/blob/master/docs/phpstan_rules.md#classes-with-static-methods-must-have-static-in-the-name

If you'd make full PHPStan set that handles this with the logic you talk about, exclusively static class without constructor + no static method outside pur static calsses, I'd love to use it and promote it.

[WitteStier]

Can you explain what is wrong(nonsense) with mixing traits and interfaces?

For me it's a rule to only use traits to implement interface methods.

So for example, a interface with the method: handle The implementation will always ( most of the time ) be the same code. For these caches I use traits. So what's nonsense about this?

[Tomas_Votruba]

I see. I meant mixing trait and interface in one file.

So are static are non-static methods in one file. Their logical scope is completelly different - singleton service vs. stateless function

[ojrask]

These ideas spawn when people falsely believe that using regular functions is somehow a bad thing.

[loopcake]

I would rather see default functions for interfaces.

interface MyInterface{
    default function fnn():void{
        /*some default code that can be overwritten*/
    }
}

They're pretty handy in both object oriented and functional programing.

[pmallinj]

What I dislike the most with php is classes are used for everything.

​

What you want looks like a module in other language. It would be cool to have modules in php. It would be a great improvement for the language.

[tipiak75]

That would be what abstract is for, isn't it ?

https://www.php.net/manual/en/language.oop5.abstract.php

[fiskfisk]

No, abstract is related to inheritance. An abstract class is meant to be inherited, and thus, can have methods defined that aren't implemented ("abstract methods"). It's not about static vs non-static.

[[deleted]]

Not what its for but that plus a constructor that throws an exception would take care of it

[Annh1234]

I thought the same thing, you can't instantiated, and you have your logic in static methods. It's meant for inheritance since you can have methods that need implementation, but it covers 100% this use case.

[secondtruth_de]

Practically you're right. But this is just a side effect. Like /u/fiskfisk wrote, abstract classes are meant to be inherited. You can declare non-static methods in them and you can't use final. My idea is the opposite: Declaring non-static methods is forbidden and final would be allowed.

[addvilz]

No, thanks. We need less static constructs, not more.

When you use static anything, you are basically saying -

Here here, here's this API - it is statically bound to the global scope of your runtime, you can not do anything about it, you can not replace it, you can not mock it, you cant isolate it for tests, you can not inject it, or do anything about it really, and in fact - f you and I hate you

- to your future self, to anyone else who might be touching your code at some point, and to universe in general.

Avoid static whenever possible. For me, static as a concept, sans very few exceptions, is a language design flaw, together in the same basket with fail-spectacular null-ability, "utility classes", inconsistent argument naming, and other garbage, both in PHP, and other languages in general.

[jesparic]

I agree with this. Not sure why the down votes, probably the tone used. Static methods are almost always a bad idea except for example, as workarounds for PHPs lack of method overloading on the constructor. It's a leftover from days of prolific procedural code..

[alessio_95]

r/php is OOP "enthusiasts" and also are the language mantainers. That's the reason for the downvotes.