Add clarification about expiration of items

[Seldaek]

See symfony/symfony#44995 for details. The spec isn't extremely clear about this but all implementations I checked (very reasonably) do this already. It does not hurt to spell out the "obvious" IMO as it may not be obvious to everyone.

I am not sure if this belongs here or rather in a ML post, but anyway this is a starting point for a discussion.

[Jean85]

Depending on existing text, it could be considered either a clarification or an errata (that requires a vote).

Either way, @Crell is the editor and final authority here.

[Crell]

Hrm. I think the original logic from the spec authors was along the lines of "all cache writes are independent of each other. The existence of a previous record is irrelevant, it gets overwritten entirely." "Entirely" means "including its TTL." So of course load/save like that would result in a new TTL being set. I think that is still the correct behavior; A cache is not a database.

Editing the spec text directly is a no-go. But we can include an Errata that clarifies the above reasoning and specifically recommends that implementations always treat a cache write as a full-overwrite, and not persist a TTL.

[Seldaek]

The thing is all implementations I checked appear to do it correctly. What needs fixing is the user documentation to ensure people don't have the wrong expectations and try reusing / updating a cached item.

So maybe the wording can be improved, but IMO it makes a lot more sense to update the docblock with a clarification for users than an errata virtually no user will ever look at.

[Crell]

I think we can update the docblock in the actual package. We've tweaked those as part of the type updates before. I am not sure if updating the spec proper is kosher. However, I'm open to input from other CC members.

[Seldaek]

Ah yes an errata in spec and then a docblock patch in the spec would be totally fine for me too.

[shadowhand]

an errata in spec and then a docblock patch in the spec would be totally fine for me too.

Agree.

[drupol]

Agree as well.

[Jean85]

Agree. Marking the errata in the meta document is what makes it possible.

[ashnazg]

+1 from me

[vdelau]

Just to make sure that we are all talking about the same thing: The proposal is to add errata and documentation to clarify that TTL might not be set when retrieving a CacheItemInterface object from a CachePool and that when 'updating' a cache item it is the responsibility of the user to set a new TTL?

[Seldaek]

Yes, add errata and update at least the docblocks in the psr/cache repo, if the docblocks in the spec cannot be updated due to red tape. Exact wording is TBD as far as I am concerned, I just thought it'd be good to highlight the fact that yes TTL might not be set (probably SHOULD not be set) on a CacheItemInterface object retrieved from the cache, and that on save() a previously stored item with the same key will be overwritten completely, inclusive TTL.

[jeevanroy1434]

Basic Coding Standard

This section of the standard comprises what should be considered the standard
coding elements that are required to ensure a high level of technical
interoperability between shared PHP code.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.

1. Overview

• Files MUST use only <?php and <?= tags.

• Files MUST use only UTF-8 without BOM for PHP code.

• Files SHOULD either declare symbols (classes, functions, constants, etc.)
  or cause side-effects (e.g. generate output, change .ini settings, etc.)
  but SHOULD NOT do both.

• Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4].

• Class names MUST be declared in StudlyCaps.

• Class constants MUST be declared in all upper case with underscore separators.

• Method names MUST be declared in camelCase.

2. Files

2.1. PHP Tags

PHP code MUST use the long <?php ?> tags or the short-echo <?= ?> tags; it
MUST NOT use the other tag variations.

2.2. Character Encoding

PHP code MUST use only UTF-8 without BOM.

2.3. Side Effects

A file SHOULD declare new symbols (classes, functions, constants,
etc.) and cause no other side effects, or it SHOULD execute logic with side
effects, but SHOULD NOT do both.

The phrase "side effects" means execution of logic not directly related to
declaring classes, functions, constants, etc., merely from including the
file.

"Side effects" include but are not limited to: generating output, explicit
use of require or include, connecting to external services, modifying ini
settings, emitting errors or exceptions, modifying global or static variables,
reading from or writing to a file, and so on.

The following is an example of a file with both declarations and side effects;
i.e, an example of what to avoid:

<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);

// side effect: loads a file
include "file.php";

// side effect: generates output
echo "<html>\n";

// declaration
function foo()
{
    // function body
}

The following example is of a file that contains declarations without side
effects; i.e., an example of what to emulate:

<?php
// declaration
function foo()
{
    // function body
}

// conditional declaration is *not* a side effect
if (! function_exists('bar')) {
    function bar()
    {
        // function body
    }
}

3. Namespace and Class Names

Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4].

This means each class is in a file by itself, and is in a namespace of at
least one level: a top-level vendor name.

Class names MUST be declared in StudlyCaps.

Code written for PHP 5.3 and after MUST use formal namespaces.

For example:

<?php
// PHP 5.3 and later:
namespace Vendor\Model;

class Foo
{
}

Code written for 5.2.x and before SHOULD use the pseudo-namespacing convention
of Vendor_ prefixes on class names.

<?php
// PHP 5.2.x and earlier:
class Vendor_Model_Foo
{
}

4. Class Constants, Properties, and Methods

The term "class" refers to all classes, interfaces, and traits.

4.1. Constants

Class constants MUST be declared in all upper case with underscore separators.
For example:

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';
}

4.2. Properties

This guide intentionally avoids any recommendation regarding the use of
$StudlyCaps, $camelCase, or $under_score property names.

Whatever naming convention is used SHOULD be applied consistently within a
reasonable scope. That scope may be vendor-level, package-level, class-level,
or method-level.

4.3. Methods

Method names MUST be declared in camelCase().