Qu'entend-on par «prise en charge native d'une fonctionnalité» dans un langage de programmation?

J'ai parcouru une ligne un peu comme ceci "PHP n'a pas de support natif pour Unicode". J'ai également lu que Python a un support natif pour Unicode. Vous pouvez maintenant appeler une fonction utf8_encode()en PHP pour coder une chaîne en Unicode et vous pouvez utiliser une fonction unicode()en Python pour convertir une chaîne en Unicode. Alors, que signifie supporter nativement Unicode? De plus, certaines langues ont un support natif pour la simultanéité tandis que d'autres n'en ont pas. Alors qu'est-ce qu'on entend par

Le langage X prend en charge nativement la fonction Y

Cela signifie que pour prendre en charge une fonctionnalité donnée, le développeur n'a pas besoin d'utiliser un composant qui n'est pas intégré dans le langage lui-même, comme une extension ou un produit tiers.

Par exemple, PHP n'a pas de support natif pour unicode, car chaque fonction qui traite des chaînes en PHP lui-même ne prend pas en charge unicode. Par exemple, pour obtenir une sous-chaîne, vous ne pouvez pas utiliser substr, mais devez utiliser mb_substr, ce qui nécessite d'utiliser l'extension de chaîne multi-octets.

Pour avoir un support natif d'une fonctionnalité donnée, il ne suffit pas d'incorporer simplement une extension dans le tronc du code source. Au lieu de cela, PHP aurait un support natif pour unicode si unicode était le codage par défaut, comme en C # ou Java.

«Le langage X prend en charge nativement la fonctionnalité Y» signifie que vous pouvez utiliser la fonctionnalité Y sans aucune extension ni aucun autre effort pour la faire fonctionner. Il est directement utilisable à partir de la langue elle-même.

Par exemple, vous pouvez dire que,

"Le langage C ++ supporte nativement la surcharge d'opérateur."

"Le langage Java prend en charge nativement le ramasse-miettes automatique", car vous n'avez pas besoin d'utiliser d'autres bibliothèques ou outils effectuant le ramasse-miettes automatique. Il est livré avec la langauge (et la plate-forme) elle-même.

Je lirais natif dans les contextes que vous avez mentionnés comme intégrés . Si une langue ne fournit pas de support natif pour une fonctionnalité, vous devrez l'implémenter vous-même ou trouver une bibliothèque ou un module qui la fournit.

Un autre contexte où vous verrez beaucoup de natif concerne les applications sur une plate-forme ou une autre. Dans ces cas, cela signifie compilé pour la plateforme plutôt que d'être interprété ou traduit d'une manière ou d'une autre. Une application iOS native est une application écrite dans un langage comme Objective-C et compilée en code qui s'exécute directement sur la famille de processeurs ARM (ce que vous trouverez sur les appareils iOS).

Je considérerais cela comme une mauvaise utilisation du terme. Pour que quelque chose soit «natif» d'une langue, il doit y avoir des installations pour cela. La prise en charge native de quelque chose comme unicode aurait des types bruts dans le langage qui implémentent l'unicode d'une manière ou d'une autre. Habituellement, cela ne fait pas partie de la langue mais fait partie d'une bibliothèque.

IMHO appeler quelque chose qui apparaît dans la bibliothèque par défaut de la langue ou non ne fait pas quelque chose de natif ou non.

Quelques exemples:

C ++ a un support natif pour les classes. C non. Il n'y a pas de mots-clés de langue ou de facilité de type qui permet l'écriture et l'utilisation de classes, vous devez les coder à la main.

Je dirais cependant que C ++ n'a pas plus de type de chaîne natif que C. Il y a un modèle basic_string dans la bibliothèque standard, mais ce n'est pas une fonction linguistique.

C ++ 11 semble cependant avoir ajouté la prise en charge Unicode, car de nouveaux mots clés et types bruts ont été ajoutés au langage lui-même pour faciliter le travail avec les valeurs Unicode.

J'espère que cela clarifie la différence que je vois.

«Prise en charge native» au moins dans les langages interprétés ou compilés en JIT signifie généralement du code qui est fondamentalement juste un lien vers une fonctionnalité précompilée qui se trouve sous l'interpréteur.

En JavaScript, par exemple, si vous alertez window.open dans Firefox, vous verrez probablement une fonction dont les entrailles disent quelque chose comme "[code natif]". Alors que toutes les références sont transmises à l'interpréteur et que des mesures doivent être prises pour établir le contexte et la portée, les entrailles sont fondamentalement mises en cache et prêtes à fonctionner. window.open par exemple, appelle probablement quelque chose à partir de l'environnement d'exécution d'un navigateur.

Ceci est différent des objets et méthodes non natifs que vous ou quelqu'un d'autre avez écrits, car dans ces cas, toutes vos déclarations doivent être interprétées / évaluées.

Si quelqu'un utilisait le terme en référence à un langage qui précompile, je suppose qu'ils signifient simplement tous les trucs du langage de base que le compilateur tokenise et convertit réellement en code machine par rapport aux trucs que vous définissez vous-même, qui sont plus structures et références utilisées pour relier le tout.