Skip to content

Commit fa0587f

Browse files
committed
[docs] Add class properties deprecation guidelines
Documents the process for deprecating class properties, which cannot emit runtime warnings in PHP < 8.4. Key points: - Private properties: remove immediately - Protected properties in non-extensible classes: can be removed - Public/protected properties in extensible classes: use @deprecated tags, attributes, and provide getter/setter methods with warnings - From Moodle 6.0 (PHP 8.4+): use property hooks for proper deprecation
1 parent 6cf5abb commit fa0587f

1 file changed

Lines changed: 102 additions & 0 deletions

File tree

  • general/development/policies/deprecation

general/development/policies/deprecation/index.md

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -205,6 +205,108 @@ A code removal step was added to the deprecation process in Moodle 5.0 and is al
205205
- Functions deprecated in Moodle 4.5 (LTS) will be up for final deprecation in Moodle 6.0 (the first release for Series 6 right after the Moodle 5.3 (LTS) release), and for removal in Moodle 7.0 (the first Series 7 Moodle version).
206206
</ValidExample>
207207

208+
## Class properties deprecation
209+
210+
Deprecating class properties presents unique challenges compared to methods, as PHP versions before 8.4 do not provide a native mechanism to emit warnings when properties are accessed or modified.
211+
212+
### When can a property be deprecated?
213+
214+
The approach to deprecating a property depends on its visibility and usage:
215+
216+
1. **Private properties**: Can be removed immediately as they are not part of the public API.
217+
218+
2. **Protected properties in non-extensible classes**: Can be removed if there is no reasonable expectation that external code extends the class. This applies to classes where:
219+
- The API is not designed to be extended
220+
- It would be extremely difficult for developers to correctly extend and consume the class
221+
- The protected property is not considered part of the 'public' API
222+
223+
3. **Public properties, or protected properties in extensible classes**: Cannot be safely removed using the standard deprecation process, as there is no way to alert developers when the property is accessed in PHP versions before 8.4.
224+
225+
### Deprecation process for properties that cannot be removed
226+
227+
For public properties and protected properties in extensible classes, follow these steps:
228+
229+
1. **Add the `@deprecated` PHPDoc tag** to the property documentation, including:
230+
- The version it was deprecated in.
231+
- The reason for deprecation.
232+
- Alternative approaches or replacement properties.
233+
234+
```php
235+
/**
236+
* @var string
237+
* @deprecated since 4.4 Use get_summary() method instead
238+
*/
239+
public string $summary;
240+
```
241+
242+
2. **Document in upgrade notes**: Ensure the deprecation is clearly documented in the [upgrade notes](../../upgradenotes.md) for the release.
243+
244+
3. **Add the `\core\attribute\deprecated` attribute**:
245+
246+
```php
247+
#[\core\attribute\deprecated(
248+
since: '4.4',
249+
reason: 'Direct property access is deprecated. Use get_summary() and set_summary() methods instead.',
250+
mdl: 'MDL-XXXXX',
251+
)]
252+
public string $summary;
253+
```
254+
255+
4. **Ensure there are no internal uses**: Remove all usage of the property within Moodle core code, replacing it with the recommended alternative (such as getter/setter methods).
256+
257+
5. **Provide getter/setter methods as migration path**: If the property previously had direct access, create getter and setter methods that provide the same functionality and serve as the migration path for developers.
258+
259+
**Important**: In PHP versions before 8.4, there is no way to intercept direct property access for public properties without breaking backward compatibility. The getter/setter methods cannot emit warnings when users access the property directly (e.g., `$obj->property`). They only provide a migration path for developers who follow the deprecation guidance.
260+
261+
```php
262+
/**
263+
* Get the summary text.
264+
*
265+
* @return string
266+
*/
267+
public function get_summary(): string {
268+
return $this->summary;
269+
}
270+
271+
/**
272+
* Set the summary text.
273+
*
274+
* @param string $summary The summary text
275+
*/
276+
public function set_summary(string $summary): void {
277+
$this->summary = $summary;
278+
}
279+
280+
```
281+
282+
Developers must rely on IDE hints from `@deprecated` tags, documentation, and upgrade notes to know they should migrate from direct property access to these methods.
283+
284+
### Property deprecation from Moodle 6.0 onwards
285+
286+
From Moodle 6.0, the minimum supported PHP version will be 8.4. PHP 8.4 introduces [Property Hooks](https://wiki.php.net/rfc/property-hooks), which allow proper deprecation warnings to be emitted when properties are accessed or modified.
287+
288+
**Example using PHP 8.4 property hooks:**
289+
290+
```php
291+
#[\core\attribute\deprecated(
292+
since: '4.4',
293+
reason: 'Direct property access to $summary is deprecated. Use get_summary() and set_summary() methods instead.',
294+
mdl: 'MDL-XXXXX',
295+
)]
296+
public ?string $summary {
297+
get {
298+
\core\deprecation::emit_deprecation([self::class, __PROPERTY__]);
299+
return $this->summary;
300+
}
301+
set {
302+
\core\deprecation::emit_deprecation([self::class, __PROPERTY__]);
303+
$this->summary = $value;
304+
}
305+
}
306+
```
307+
308+
This allows Moodle to emit proper runtime deprecation warnings when properties are read from or written to, providing the feedback mechanism that is currently unavailable in earlier PHP versions.
309+
208310
## Parameters deprecation
209311

210312
Whilst it is possible to deprecate individual method parameters, care must be taken in doing so.

0 commit comments

Comments
 (0)