Il wrapping delle funzioni integrate con le funzioni utente è ok?

Dipende .

Quando progetti programmi, la ragione più importante per creare le funzioni è IMHO per creare utili astrazioni. Ad esempio, a volte un progettista del programma desidera astrarre da un'API specifica o da un determinato framework e crea un livello intermedio, quindi un utente di tale API dipende solo da quel livello, ma non dall'API sottostante. Oppure, si desidera creare un tipo di dati specifico basato su un tipo di tipo di dati incorporato dell'API sottostante e fornire un set completo di funzioni per l'accesso a questo tipo di dati astratto.

Per questi casi, può essere perfettamente perfetto racchiudere le singole funzioni integrate, per creare un insieme completo e coerente di proprie funzioni che incapsulino qualcosa.

Tuttavia, ci sono anche ragioni sbagliate per farlo. Ad esempio, quando le funzioni appena create non forniscono alcuna astrazione reale dal framework sottostante, o quando l'astrazione non è realmente necessaria e non fornisce alcun vantaggio (che si verifica spesso quando qualcuno lo ha creato "just in case").

Ad esempio, nel caso mostrato nella tua domanda, è discutibile se le nuove funzioni forniscano nomi più chiari per qualcuno che abbia familiarità con il framework o il linguaggio di programmazione sottostante. Se queste funzioni ora portano al codice che usa direttamente le funzioni integrate, mescolate con queste funzioni "appena inventate", allora probabilmente non rende il codice più chiaro, al contrario.

Se hai una convenzione di denominazione accettata nella tua squadra come nominare certe funzioni, e l'intera squadra segue rigidamente questa convenzione, allora può davvero avere senso incapsulare le funzioni incorporate nel modo mostrato perché i nomi si adattano meglio alle convenzioni di denominazione del team. Tuttavia, immagino che la tua squadra non abbia una tale convenzione, altrimenti non avresti mai fatto la domanda qui in primo luogo.

No questo non è un comportamento regolare. Ciò potrebbe portare a confusione quando gli sviluppatori che non avevano familiarità con il framework originale vanno a lavorare su un nuovo progetto che utilizza lo stesso framework ma non ha i wrapper. Gli sviluppatori che conoscono il framework lo chiameranno direttamente, e questo porterà alla biforcazione del codice in cui alcuni sviluppatori chiamano i wrapper e altri no. Inoltre, è probabile che riduca le prestazioni in quanto una chiamata a una singola funzione ora diventa 2 chiamate di funzione: la prima per il wrapper e la seconda per il wrapper alla funzione originale.

Per queste operazioni specifiche non è una buona idea. empty e isset non sono funzioni, ma costrutti di linguaggio.

Il passaggio a cose non definite non produrrà un errore e non creerà quegli elementi. Tuttavia, chiameremo le funzioni di avvolgimento.

L'unico motivo per avvolgere empty sarebbe quello di poterlo chiamare indirettamente in questo modo:

<?php
function is_empty($var) {
    return empty($var);
}
$is_empty = "is_empty";
$is_empty($foo[42]); // will produce error and create $foo in scope

array_filter($array, "is_empty"); // might be more useful than example above

array_filter($array, function ($e) { return empty $e; }); // might be the nicer, more explicit, form in modern PHP, though
?>

È assolutamente ok, a seconda delle circostanze. Ad esempio, molto tempo fa, stavo lavorando a un progetto VAX / VMS / C che sapevo sarebbe stato portato su Unix diversi anni prima. VMS aveva un sacco di cose insolite, ma utili come servizi di nome logico. Ho avvolto tutti quei tipi di funzioni built-in (quelle che chiamano servizi di sistema) come funzioni utente, sapendo che potrebbero essere riscritte al momento opportuno. In particolare, ho avuto un modulo in cui sono state confezionate un intero pasticcio di tali funzioni e in cui sono comparsi tutti gli # include specifici di VMS. Quindi solo quel modulo era interessato dalla porta finale.

Altrimenti, ci sarebbero state cose specifiche del VMS dappertutto. Ad esempio, molte di queste chiamate VMS prendono come "argomenti descrittori di stringa" gli argomenti, piuttosto che le solite stringhe con terminazione null C. I miei involucri prendevano le solite stringhe come argomenti, e facevano tutte le pulizie per ri-castarli come descrittori in quell'unico luogo. Senza questo, ogni modulo dovrebbe includere # include la descrizione (un VMS-ism per #include < descrip.h >) e dovrebbe dichiarare alcuni "descrittori" dall'aspetto strano. Quindi la porta avrebbe richiesto un editing completo, non un bel po 'di riflessione, ma tonnellate di modifiche.

Puoi dare un'occhiata a un modulo contenente molte di quelle funzioni wrapper al link (il VMS i servizi di nome logico sono stati raccolti in un modulo separato)

Dipende, ma IMO, Preferisco la funzione di wrap-and-add-more ed evito il .

Anche per coerenza e DRY .

Esempio:

<?php
// wrap date() to display my-country-common-date-format
function fn_date_format($custom_date = null) {
  $format = 'd F Y';
  if(empty($custom_date)) return date($format);
  return date($format, strtotime($custom_date));
}

// result:
echo fn_date_format(); // 28 September 2017 (today)
echo fn_date_format('2000-05-22'); // 22 May 2000

(sory per il mio inglese)