---
title: "Ragionando in PHP 7 Lezione 1: Tipizzazione scalare"
description: "Lezione 1 su PHP 7: la tipizzazione scalare. Lezioni di PHP 7 mirate all'apprendimento delle differenze tra PHP 5.6 e la nuova versione di PHP 7.0 rilasciata nel 2015 ed entrata in supporto stabile nel 2017"
canonical: "https://www.mauriziofonte.it/blog/post/php7-lezione-1-tipizzazione-scalare.html"
author: "Maurizio Fonte"
date: "2018-02-27T18:47:56+01:00"
modified: "2018-02-27T18:47:56+01:00"
section: "PHP"
tags: ["PHP"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[PHP](https://www.mauriziofonte.it/blog/cat/php.html)

# [Ragionando in PHP 7 Lezione 1: Tipizzazione scalare](https://www.mauriziofonte.it/blog/post/php7-lezione-1-tipizzazione-scalare.html)

Martedì 27 Febbraio 2018, alle 18:47 ![Ragionando in PHP 7 Lezione 1: Tipizzazione scalare](https://www.mauriziofonte.it/image/000500200-php7-lezione-1-tipizzazione-scalare.jpg)

PHP 5 ha introdotto a suo tempo la possibilità per lo sviluppatore di definire verbosamente i tipi di dato richiesti da una funzione. Questo impedisce l'esecuzione di funzioni o metodi richiamati con tipi di dati errati, come ad esempio passare un timestamp UNIX a un metodo che si aspetta un oggetto DateTime. In più, la tipizzazione rende anche chiaro agli altri sviluppatori come utilizzare la funzione in piena compatibilità. Per esempio, qui sotto, si analizzi la definizione delle due funzioni con e senza tipizzazione:

```
// Senza tipizzazione
function prossimoGiornoSettimana($data) { /*...*/ }
// Con tipizzazione (PHP5)
function prossimoGiornoSettimana(DateTime $data) { /*...*/ }
```

La tipizzazione era inizialmente limitata alle sole classi e interfacce, ma fu poi ampliata per consentire anche i tipi Array e Callable. PHP 7, invece, estende ulteriormente questo limite **consentendo la tipizzazione scalare** come **int**, **float**, **string**e **bool**:

```
// Tipizzazione scalare (PHP7)
// è possibile definire il tipo richiesto per il parametro $data come INT. E' chiaramente comprensibile allo sviluppatore che questa funzione accetta un timestamp.
function prossimoGiornoSettimana(int $data) { /*...*/ }
```

#### Controllo della tipizzazione

Il controllo di tipizzazione per i tipi scalari in PHP 7 funziona in modalità "**Coercive**", ovvero, nella stessa identica maniera con la quale le vecchie versioni di PHP effettuano il controllo di tipizzazione sulle funzioni built-in. Per meglio spiegare questo concetto, basta pensare alla situazione della funzione **floor**, che è così definita:

```
// definizione della funzione float built-in di PHP
float floor ( float $numero )
```

Quando si passa un parametro alla funzione float, PHP effettuerà una conversione "Coercive" del valore passato alla funzione, se questa è convertibile. Esiste una tabella di conversione per capire se un tipo di variabile può essere automaticamente convertito da PHP in modalità "Coercive":

| Tipo di dato | int | float | string | bool | object |
| --- | --- | --- | --- | --- | --- |
| int | si | si* | si** | si | no |
| float | si | si | si* | si | no |
| string | si | si | si | si | si*** |
| int | si | si | si | si | no |

*****: Solo valori che non siano NaN e compresi tra PHP_INT_MIN e PHP_INT_MAX  
******: solo se è una stringa numerica  
*******: solo se l'oggetto ha un metodo magico __toString()

PHP 7 introduce un nuovo metodo per il controllo della tipizzazione, chiamato "**Strict**", che permette allo sviluppatore di definire, all'inizio dello script, una particolare "frase" che, se presente, imporrà al compilatore di effettuare il controllo di tipizzazione in senso stretto, quindi senza interpolazione dei parametri "Coercive" come sopra spiegato. Attenzione: utilizzare il controllo di tipizzazione Strict farà in modo che anche **eventuali funzioni built-in di PHP richiamate all'interno del file saranno sottoposte allo stesso identico trattamento di validazione**.

La modalità Strict essenzialmente richiede che **tutte** le variabili passate alle funzioni tipizzate siano in regola con la definizione della funzione/metodo. In caso contrario, verrà lanciato un **TypeError**. Ad esempio, in modalità Strict, **non è possibile utilizzare stringhe numeriche quando la tipizzazione richiede un float o un int** (come invece in modalità Coercive è ammesso e funzionante):

```
<?php
declare(strict_types=1);
function ciao(string $nome): string {
echo 'Ciao, ' . $name;
}
function somma(float $a, float $b): float {
return $a + $b;
}
ciao('Alberto'); // Stampa: "Ciao, Alberto"
ciao(3); // genera un Fatal error: Uncaught TypeError: Argument 1 passed to ciao() must be of the type string, integer given
somma(2, 1); // ritorna "3" anche se i tipi passati sono int
somma(3.2, true); // genera un Fatal error: Uncaught TypeError: Argument 2 passed to somma() must be of the type float, bool given
```

Poiché la direttiva è impostata per ogni file, e ad inizio di ogni file, **è possibile e ammesso combinare le modalità Strict e Coercive nell'applicazione**. Ad esempio, se alcune parti della propria applicazione ( magari installate tramite Composer ) non richiedono tipizzazione stretta, mentre invece alcuni specifiche classi della propria applicazione la richiedono, tutta l'applicazione continuerà a funzionare, e il controllo di tipizzazione stretto verrà applicato solo ed esclusivamente sui file che ne fanno uso.

#### Compatibilità con versioni di PHP precedenti

Non è più possibile, con PHP 7, **creare classi denominate int, float, string o bool** in quanto queste andrebbero in conflitto con le nuove tipizzazioni di tipo scalare.

Questa era la prima lezione su PHP 7. Naviga nella categoria PHP7 di questo blog per scoprire le altre lezioni e le novità introdotte da PHP7

Dall'articolo al lavoro vero

Se il codice di cui parla questo articolo è il tuo

Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione.

[Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Ultima modifica: Martedì 27 Febbraio 2018, alle 18:47 [« Articolo precedenteModificare al volo il codice HTML calcolato da Wordpress27 Febbraio 2018](https://www.mauriziofonte.it/blog/post/output-buffer-plugin-modifica-html-wordpress.html)[Articolo successivo »Ragionando in PHP 7 lezione 2: operatore di confronto combinato Spaceship2 Marzo 2018](https://www.mauriziofonte.it/blog/post/php7-lezione-2-operatore-spaceship.html)

### Articoli correlati a Ragionando in PHP 7 Lezione 1: Tipizzazione scalare

- [Le prime quarantotto ore di PHP2Shell viste da un sensore](https://www.mauriziofonte.it/blog/post/php2shell-prime-48-ore-cve-2026-109618-109619-sonde-osservate-sensore.html)

  Gli avvisi di sicurezza di PHP sono stati pubblicati alle 13:34 UTC. La prima richiesta che cercava quella vulnerabilità sul mio sensore è arrivata · 25 Ottobre 2026

  ![Le prime quarantotto ore di PHP2Shell viste da un sensore](https://www.mauriziofonte.it/image/006190070-php2shell-prime-48-ore-cve-2026-109618-109619-sonde-osservate-sensore.jpg)
- [Come funziona la use-after-free di PHP2Shell nelle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/blog/post/php2shell-use-after-free-cve-2026-109618-109619-worker-persistenti-stato-residuo.html)

  Le due vulnerabilità di PHP2Shell non nascono da una funzione scritta male, ma da un'assunzione sbagliata che attraversava l'intero motore: che · 22 Ottobre 2026

  ![Come funziona la use-after-free di PHP2Shell nelle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/image/006160070-php2shell-use-after-free-cve-2026-109618-109619-worker-persistenti-stato-residuo.jpg)
- [La scoperta di PHP2Shell e cosa fare sulle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/blog/post/php2shell-scoperta-cve-2026-109618-109619-cosa-fare-backport-eol-riavvio-worker.html)

  Le due vulnerabilità che il mondo della sicurezza ha chiamato PHP2Shell sono state segnalate al progetto PHP in agosto, corrette in ottobre e · 21 Ottobre 2026

  ![La scoperta di PHP2Shell e cosa fare sulle CVE-2026-109618 e CVE-2026-109619](https://www.mauriziofonte.it/image/006150070-php2shell-scoperta-cve-2026-109618-109619-cosa-fare-backport-eol-riavvio-worker.jpg)
- [Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html)

  Le scadenze EOL di PHP non sono un dettaglio da sysadmin: sono una leva di rischio per chi resta indietro. Lo stato reale nel 2026, con le date · 30 Settembre 2026

  ![Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/image/005410070-scadenze-eol-php-2026-piano-migrazione-parte-adesso.jpg)
- [Il pipe operator di PHP 8.5: leggibilità reale o zucchero sintattico?](https://www.mauriziofonte.it/blog/post/php-8-5-pipe-operator-leggibilita-reale-zucchero-sintattico.html)

  PHP 8.5 introduce il pipe operator, e la domanda onesta è se migliori davvero la leggibilità o sia solo zucchero sintattico. Analisi pratica: · 28 Settembre 2026

  ![Il pipe operator di PHP 8.5: leggibilità reale o zucchero sintattico?](https://www.mauriziofonte.it/image/005390070-php-8-5-pipe-operator-leggibilita-reale-zucchero-sintattico.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Ragionando in PHP 7 Lezione 1: Tipizzazione scalare", mauriziofonte.it, 2018. https://www.mauriziofonte.it/blog/post/php7-lezione-1-tipizzazione-scalare.html

Pubblicato: 2018-02-27 · Aggiornato: 2018-02-27.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.
