Abstract the underline storage driver about cache HOT 11 CLOSED

I was thinking about that because in future probably I'd like to add PSR-6 as well and having SimpleCache decoupling from transient is a good idea, I also have a library for handling configs (it's an ArrayObject stuff) that I want to adapt to this SimpleCache, so, it's fine for me to go for decoupling things.
Some question before implementing this:
Why you initialize TTL in constructor? TTL is per transient, if you nedd to set more than one transiet it is better to use different TTL for every transient.

The write() method could be used to override transient at runtime (for value or TTL) throwing an exception if key exists could be problematics.

The words read and write, I know that get and set are worst but they follow the initial intreface.

The last, the Wp prefix in WpTransientStorageDriver, for me it is better TransientStorageDriver or something like that, I try to avoid as much as possible the wp prefix in code for more abstraction.

from cache.

Why you initialize TTL in constructor? TTL is per transient, if you nedd to set more than one transiet it is better to use different TTL for every transient.

No reason, I just add some sample code without making it correct, just to give a rough idea.
I haven't read the full specification of the PSR-16 so if the interface define that you have to pass it to set that's perfect.

The write() method could be used to override transient at runtime (for value or TTL) throwing an exception if key exists could be problematics.

That's depends of which kind of implementation you want to have. In same cases you do not want to replace the value in storage because that could make unpredictable results but on the other hand a value in cache it's just a value in cache and can be update you're right, does not make much sense as per implementation.

The words read and write, I know that get and set are worst but they follow the initial intreface.

The differences is that get and set does not specify you're doing something somewhere fisically, them are more abstracted but that's just an opinion.

I mean I know it's a convention but in case of storage I thought could be better to enforce the meaning of read a value from and write it to somewhere than simply get it and set it.

The last, the Wp prefix in WpTransientStorageDriver, for me it is better TransientStorageDriver or something like that, I try to avoid as much as possible the wp prefix in code for more abstraction.

The Wp prefix would specify that your implementation is using the WordPress transient, if you name it TransientStorageDriver you're abstracting. The next question would be, which kind of transient?
What if I would use a different implementation by other Frameworks? I could not use TransientStorageDriver and I would define a more specific name.

I could even have something like ArrayTransientStorageDriver because using an array does not mean the value isn't temporary, may be there's internal logic which define the time to leave.

Sorry if the code it's messy, I was wondering to give just an example to accompain my idea in order to make it more clear.

from cache.

That's depends of which kind of implementation you want to have. In same cases you do not want to replace the value in storage because that could make unpredictable results but on the other hand a value in cache it's just a value in cache and can be update you're right, does not make much sense as per implementation.

I don't know yet, maybe could be a good idea to have different drivers, one for allowing value changing and one for not allowing that depending of the uses case.

The differences is that get and set does not specify you're doing something somewhere fisically, them are more abstracted but that's just an opinion.
I mean I know it's a convention but in case of storage I thought could be better to enforce the meaning of read a value from and write it to somewhere than simply get it and set it.

I like read and write names much more than get and set, I have to think about that.

The Wp prefix would specify that your implementation is using the WordPress transient, if you name it TransientStorageDriver you're abstracting. The next question would be, which kind of transient?
What if I would use a different implementation by other Frameworks? I could not use TransientStorageDriver and I would define a more specific name.

Yes, I know but that prefix make me mad, I prefer to using a suffix instead, like TransientStorageDriverWPAdapter or something like that, I don't care about long class naming if it is undertandable.

Sorry if the code it's messy, I was wondering to give just an example to accompain my idea in order to make it more clear.

You don't have to sorry, your code is not messy, mine is worst :-D

from cache.

Yes, I know but that prefix make me mad, I prefer to using a suffix instead, like TransientStorageDriverWPAdapter or something like that, I don't care about long class naming if it is undertandable.

But keep in mind that this is not an Adapter it's the implementation.
Adapter is a pattern and that could confuse

from cache.

Yes, it is an adapter because convert one interface to another: get_transient() -> Cache::get()
An interface it is not also the interface keyword but it is the front API devs can use even with procedural programming.
But this is not a problem, the real problem is how to naming things https://martinfowler.com/bliki/TwoHardThings.html :-D

from cache.

An interface it is not also the interface keyword but it is the front API devs can use even with procedural programming.

Not sure if I agree or not, the main problem is that Adapter will adapt interfaces which means abstraction, where converting procedural to OOP isn't a form of adaptation because you've to change your code base in order to use it.

from cache.

I would say you could have an adapter in this case if the get_transient is a pluggable function and you override the WordPress *_transient functions as wrapper for OOP for example or something different.

Then the wrapper function act as an adapter.

I may wrong, but just my 2 cent because I like the conversation about this topic. :)

from cache.

The more important thing is the intent of the patterns, for the adapter the intent is to adapt an API (in our case a function name) to be used with others API (in our case a PSR-16), because if we don't do that we can't use transients in PSR-16.

Not sure if I agree or not, the main problem is that Adapter will adapt interfaces which means abstraction

You can also adapt a concrete class to another API not only the interface keyword.

where converting procedural to OOP isn't a form of adaptation because you've to change your code base in order to use it.

This is what the adapter does.

I would say you could have an adapter in this case if the get_transient is a pluggable function and you override the WordPress *_transient functions as wrapper for OOP for example or something different.
Then the wrapper function act as an adapter.

Maybe yes, a pluggable function could be an adapter as well.

Patterns are not rules written in stone, patterns are solutions to problems in contexts, we can use a pattern and we can also modify the pattern to fit in our code if we need so.

from cache.

Intersting for design pattern for procedural code: https://stackoverflow.com/questions/10491175/does-procedural-language-have-design-patterns

from cache.

I hadn't forgotten about this but I'm a bit long on doing private things 😅

from cache.

After months it is done 😁 (I hope)

from cache.