Proposing PSR 18 'Singleton' Pre-Draft

[Richard T. Miles]

Hello to everyone here at PHP-FIG!

I have been working on 'Singleton' in my spare time and think it may have some use in this community. 

I am a Computer Science student at the University of North Texas so development starts and stops pretty

sporadically ( 1 am and coffee ). I think it finally has enough content to be presentable under a 'Pre-draft'

context. 

Singleton Github Repository: 

https://github.com/RichardTMiles/Singleton-Standard

All comments and constructive criticism welcome! 

Thanks for your time,

Richard Miles 

[Korvin Szanto]

Hi Richard,
I took a really fast look at the repo since I'm currently waiting for a plane. I noticed that this seems to be more of an implementation than a set of interfaces to standardize on. Are you wanting to standardize the implementation?

Thanks,
Korvin

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/19954bdc-3c2d-4dc4-a4d8-eee58c9891ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard T. Miles]

I suppose I was thinking 'How should one implement for maximum portability?' A Skeleton system requires the use of methods that can not be defined in a standard interface ( static members ). I do consider myself a bit novice; however, the intention of the singleton isn't to limit the creative process of the developer. I believe storing data in skeleton pattern is a `Cleaner` abstraction model than a container system. I definitely want to hear what the communities thoughts on the matter are. I understand PHP-Fig tries to leave the creative process open to the next innovation, and it may be that this abstraction is to detailed; however, I figured I would try to add some code to this great community :) 

Thanks,
Richard Miles

[Korvin Szanto]

Hi Richard,

Perhaps moving forward we have an opportunity to include more code in our recommendations, and I think that's likely a good thing. With that said, I would think with containerization being a big thing in PHP these days, singletons are going to be a tough sell. 

I think something like this would best benefit the community as an open source project perhaps on composer that people can use if they want. That way if it gains serious traction you'll have had feedback and a solid proof of the idea that people want to not have to think about how they work with singletons.

Some things that would be good to pay attention to as you do this is implementing other PSRs (like PSR-1 and 2 and PSR-11), ensuring your contracts are defined in something that is typehint-able (you can't typehint on traits), and perhaps thinking about how you can invert the responsibility of bootstrapping the singleton that is being used.

Thanks for your interest in the FIG, I hope to hear from you more in the future!

Best wishes,

Korvin

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/255df385-98b9-42a4-b98d-00be86c57e1b%40googlegroups.com.

[Daniel Plainview]

> I suppose I was thinking 'How should one implement for maximum portability?'

The irony here is that singleton makes portability harder by itself.

This "pattern" be avoided as much as possible especially for external API between libraries.

I don't see reason to standardize it.

[Richard T. Miles]

Hey Daniel and Korvin, 

First off thank you for responding, I appreciate all the feedback! I'm looking for good resources to hone my PHP. 

Korvin, I'll have to go back and take another look at those PSR's; hopefully, it will add some clarity to the code. 

Daniel, I understand that singleton 'Patterns' can be considered an anti-pattern as already addressed in the readme. 

However, I still saw significant use in the design with databases and has potential application in multi-level caching, routing, 

requests, etc...  I attempted to look at common PHP frameworks such as Larval and Zend to examine some common practices. 

I figured due to Wikipedias disclaimer, most developers would steer away from it; however, I am not fully aware of why?

I also don't understand why this would affect the surrounding libraries? If you could help clarify that would be awesome :) 

Note: by using a skeleton pattern you keep the objects initiated in the heap and reference them statically when needed. 

With clearly defined routes and a well-thought error reporting, it can be powerful. The trait uses magic methods to work with

data so developers should enjoy only having to define the trait. Using multi-level containment (abstraction or whatever) systems

only increase the total number of jumps the application will need to initiate objects. Jumping send the process to the end of the

processor's queue thus increasing runtime. This may not be a big deal for 90% of web applications, but for large traffic, and 'big data'

problems this must be considered. 

[Richard T. Miles]

Here's an example implementation: 

https://github.com/RichardTMiles/CarbonPHP

Note the route: Index -> Bootstrap -> Controller -> Model-> View

Happy National Margarita Day!