Refactor: introduce state object

[betaboon]

continuation of #261 and #263

This PR does two things:

• move the enable- and disable-logic into a dedicated file
• introduce a state-object to replace the singleton-class

This is done to prevent cyclic-imports.

[coveralls]

coverage: 99.324% (-0.2%) from 99.545%
when pulling 6291c31 on betaboon:refactor-introduce-state-object
into 2beb8f1 on mindflayer:main.

[mindflayer]

As I was previously commenting, I don't particularly like this Mocket -> MocketState change. It's not a MocketState we are dealing with, it's Mocket we enable/disable.
I believe it makes things more difficult to write, and expose internals that IMHO should not be exposed.

[mindflayer]

OK, now I see there is more. Let me think about that. Thanks!

[mindflayer]

While I like the idea of moving the two monkey-patch functions to a different module, I don't think that this mocket.state.state is more readable or understandable than the previous Singleton.

[betaboon]

just so i understand, before coming up with another approach:

are you mostly concerned about about the callsites (ie the mocket.socket.socket vs Mocket. ?

if so, how about this pattern instead:

from mocket.state import Mocket

def some_function() -> None:
     Mocket.register()

by just doing the following in mocket/state.py:

Mocket = MocketState()

?

[mindflayer]

Let's split into two different aspects:

• First: what you calling MocketState to me is simply Mocket, it's not its state (this is philosophy, I understand you may have a different point of view);
• Second: what is the reason to convert the Singleton in class/instance when Mocket API is designed to work as a Singleton? If something works like a Singleton, for the sake of readability, isn't it better if it's also implemented as a Singleton?

[mindflayer]

• First: what you calling MocketState to me is simply Mocket, it's not its state (this is philosophy, I understand you may have a different point of view);

Let me rephrase it: finding a class called MocketState is simply confusing, and I don't think it'd be beneficial to the users that already know Mocket. So, this concerns is mostly about "naming", and I guess we both know that naming is really an important - and delicate - part of software development.

[betaboon]

i think I just stepped into the age-old trap of singleton patterns in python.

https://discuss.python.org/t/any-extra-reason-to-not-use-classes-for-singletons/19243/5

where there are two options:

1. have a class bug create a single instance of it
2. have a class that exposes everything through classmethods, that never get's instantiated

you seem to prefer option2, for understandable reasons, while i prefer option 1.
i guess both are valid (aside from you good point against calling it state).

I'll try to apply option2 :)

[mindflayer]

Honestly: I am not sure I would write it this way today. We did it in 2013 and I don't see any strong reason to change it today.
I can tell you more, I don't normally write Singletons in Python, there is a better way to write something similar called "Borg". I see it's also mentioned in the thread you shared.

[betaboon]

yeah. i also rarely use singletons.
but 🤷 the world is full of learning and preferences :)

[mindflayer]

The thing here is: we don't need to instantiate Mocket more than once, expecting we always get back the same instance. So, it's not even used as a Singleton, it's just a class implementing some methods, it's pure syntactic sugar.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[betaboon]

ok it's back to a singleton-class, with the injection-logic extracted.

i had to change one import mocket.mocket.MocketSocket which would lead to cyclic imports.

[mindflayer]

ok it's back to a singleton-class, with the injection-logic extracted.

I really appreciate your patience. :)

[betaboon]

of course. you're the maintainer, I'm just a guy.

opensource lives from open, friendly and respectful collaboration :)