Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIX Singleton creation #5151

Closed
wants to merge 1 commit into from
Closed

Conversation

jonom
Copy link
Contributor

@jonom jonom commented Mar 7, 2016

Ensure DataObject instances are aware they are singletons so functions like populateDefaults() can be skipped. (fixes #4878)

Ensure DataObject instances are aware they are singletons so functions like populateDefaults() can be skipped. (fixes silverstripe#4878)
@jonom
Copy link
Contributor Author

jonom commented Mar 7, 2016

@tractorcow one of the builds failed during setup, I'm guessing re-running test won't help here?

@tractorcow
Copy link
Contributor

Hm, the logic looks sound... but maybe @chillu should look over this too.

Perhaps in 4.x we should override Object::singleton() in DataObject, in order to inject the new parameter, using the 3rd argument to Injector::get(). That way all of the DataObject specific stuff stays in DataObject.php.

@chillu is this specific fix ok for 3.x?

@tractorcow
Copy link
Contributor

Don't worry about that; It's the fault of imagick no longer supporting php 5.3

@jonom
Copy link
Contributor Author

jonom commented Mar 7, 2016

Perhaps in 4.x we should override Object::singleton() in DataObject, in order to inject the new parameter, using the 3rd argument to Injector::get()

That might work but some refactoring would be required first. Object::singleton() isn't called at all during build currently, instead the global singleton($className) function as defined in Core.php is used. I'm guessing there's a good reason for this but outside my expertise :)

BTW the manipulation I'm doing of constructor args could probably be done in get() instead of instantiate(), not sure if either one is better?

@tractorcow
Copy link
Contributor

Yeah, that's why I hate global functions. Itcan use $class::singleton() fine though.;)

@jonom jonom mentioned this pull request Mar 7, 2016
@jonom
Copy link
Contributor Author

jonom commented Mar 7, 2016

So the question is then, is there a reason we need a global singleton method?

Unless we can remove it (or effectively remove it by passing through calls to $className::singleton()) we're going to get inconsistent results between singleton($className) and $className::singleton() if we take the DataObject::singleton() path, which I don't think would be acceptable would it?

Let's give it a try... #5154 (I've really got to get tests working locally)

@tractorcow
Copy link
Contributor

So the question is then, is there a reason we need a global singleton method?

Not anymore, really, at least not in 4.0. Injector::inst()->get() should be used for non-object subclasses, and anything that extends Object (or trait Injectable in master) should just use ::singleton().

@jonom
Copy link
Contributor Author

jonom commented Mar 7, 2016

Closing this for now pending outcome of #5154

@jonom jonom closed this Mar 7, 2016
@jonom
Copy link
Contributor Author

jonom commented Feb 8, 2018

New version at #7850

@jonom jonom deleted the singleton-fix-3.2 branch February 14, 2018 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants