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

Add NULL as a first class citizen of the Unity Container #102

Closed
ENikS opened this issue Apr 2, 2019 · 2 comments
Closed

Add NULL as a first class citizen of the Unity Container #102

ENikS opened this issue Apr 2, 2019 · 2 comments
Assignees
Labels
Breaking change ❕ This change breaks public API Enhancement 🔨 Improvement of existing features
Milestone

Comments

@ENikS
Copy link
Contributor

ENikS commented Apr 2, 2019

Description

Current implementation does not recognize NULL as valid object.

Problem

A lot of times NULL is a valid value for the dependency created by a Factory or registered as an instance.

Solution

Add NULL as a first class citizen to Unity system.

Impact

Existing code should not be impacted.

@ENikS ENikS added the Enhancement 🔨 Improvement of existing features label Apr 2, 2019
@ENikS ENikS added this to the 4.2.0 milestone Apr 2, 2019
@ENikS ENikS self-assigned this Apr 2, 2019
@ENikS ENikS closed this as completed in c975f66 Apr 2, 2019
@GSPP
Copy link

GSPP commented Apr 9, 2019

When migrating from 3.3 to 4.1.3.0 this did have a compatibility impact. A custom LifetimeManager of mine returned null when no value was stored yet. This caused Unity to create a value and store it. Subsequent gets returned that value. Now the initial return null; causes null to be stored.

The code looked like this:

    public override object GetValue(ILifetimeContainer container = null)
    {
        return someDictionary.TryGetValue(key) ?? LifetimeManager.NoValue;
    }

Without the ?? LifetimeManager.NoValue which is the fix.

I believe types deriving from SynchronizedLifetimeManager are not affected because there is special handling for null and NoValue there. My type derived directly from LifetimeManager.

I have fixed this by using the new NoValue. Notifying you of this because this might break other users. Was it not the standard pattern before to have this dance of 1. return null 2. container creates value 3. value is stored 4. get now returns stored value? This pattern is now broken.

@ENikS
Copy link
Contributor Author

ENikS commented Apr 9, 2019

Yes, it is a breaking change and should be dealt with by lifetime manager designers.

This issue documents the change so you could act accordingly.

@ENikS ENikS added the Breaking change ❕ This change breaks public API label Mar 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking change ❕ This change breaks public API Enhancement 🔨 Improvement of existing features
Projects
None yet
Development

No branches or pull requests

2 participants