Deprecated about di HOT 6 CLOSED

We only have the trigger_error() calls on the 2.0 branches across the Framework repos, and that's where the message you're seeing comes from.

Also, what exactly is your proposal for "clarified to include framework or similar"? Unless we're going to start putting product identifiers in all @since and @deprecated tags as well as the inline deprecation messages (for all products, not just the Framework packages, since everything is on a different version trajectory at this point) I'm not quite sure how you'd best clarify this without creating more confusion (just look at https://api.joomla.org/cms-3/namespaces/Joomla.html where there is a mix of CMS and Framework classes with CMS, Platform, and Framework versioning in place).

from di.

Deprecated in version X of Package Y ??

from di.

Or the CMS logger needs to log where the message is coming from

from di.

We shouldn't need the package identifiers. Even though all of the packages are on their own release schedules, this only applies to minor/patch releases. Majors are still going out together (and at least for now tied to the CMS schedule).

With the upgraded debug bar in the CMS, in theory that should be able to have an error handler similar to this one that can get extended context like backtraces. Or, we change that handler to try to include some data about calling context, so the log statement is something like <deprecation message> called by <foo> (I don't think we need to arbitrarily include the full stack trace in those log messages personally).

from di.

Called by too works for me

from di.

Since this was opened, Symfony has a new deprecation contracts package that offers a function that gives runtime errors closer to the format you're looking for.

So with that package this block changes to:

trigger_deprecation(
    'joomla/di',
    '1.5.0',
    '%1$s() is deprecated and will be removed in 3.0, use %2$s::has() instead.',
    __METHOD__,
    ContainerInterface::class
);

And the resulting runtime message (which is what lands in the CMS logger) is something like this:

Since joomla/di 1.5.0: Joomla\DI\Container::exists() is deprecated and will be removed in 3.0, use Psr\Container\ContainerInterface::has() instead.

Using that package and its helper function is a worthwhile change IMO (and I've done it on other open source packages already) since it does give a little more context as to where the deprecation originates from when you have your PHP runtime collecting E_USER_DEPRECATED messages.

Doesn't really help with doc blocks though unless you end up rewriting them all to something similar to Symfony's standard but with package identifiers in them, so something like this:

/**
 * @deprecated in joomla/di 1.5 to be removed in 3.0, use `Container::has()` instead
 */

But, the con with doing that is it's going to break quite a bit about how the phpDocumentor build transforms those tags into output (inside the various class pages or the deprecation report).

from di.