15

I went through a line somewhat like this "PHP has no native support for Unicode". Also i read that Python has native support for Unicode. Now you can call a function utf8_encode() in PHP to encode a string into Unicode and you can use a function unicode() in Python to convert a string to unicode. So what does it mean to support Unicode natively? Also some languages have native support for concurrency while some dont have a native support. So what is meant by

X language natively supports feature Y

Improve this question
1
  • In point of fact, Python 3 does support unicode natively. As does 2.7.
    – nmichaels
    May 10, 2012 at 16:03

5 Answers 5

Reset to default
16

It means that to support a given feature, the developer doesn't need to use a component which is not embedded in the language itself, like an extension or a third party product.

For example, PHP has no native support for unicode, because every function which deals with strings in PHP itself doesn't support unicode. For example, in order to get a substring, you can't use substr, but need to use mb_substr, which requires to use the Multibyte String extension.

To have a native support of a given feature, it is not enough to just incorporate an extension in the source code trunk. Instead, PHP would have native support for unicode if unicode would be the default encoding, like in C# or Java.

Improve this answer
4
  • 1
    So its just about whether the component is part of the language or not? I mean if they include mb_string's functionality in PHP source it would become native?
    – lovesh
    May 9, 2012 at 21:45
  • 1
    @lovesh: it's not as easy as that. If they incorporate the extension in the PHP trunk, but without making unicode the default encoding, I'm not sure if it would be considered native. If, instead, unicode would become the default encoding, as in C#, then yes, this would be a native support.
    – Arseni Mourzenko
    May 9, 2012 at 23:47
  • Or you could say it's natively supported but not common/not the default. It's just semantics.
    – BlueRaja - Danny Pflughoeft
    May 10, 2012 at 2:58
  • 2
    For a language to natively support some kind of string, I would at least require it to have a syntax for string literals for that kind of string. For example, there would be something like s = "Müsliriegel"mb; instead of something like s = toMb("Müsliriegel"); (this is, of course, trivially fulfilled by all languages that use UTF8 as the default encoding)
    – user281377
    May 10, 2012 at 12:39
11

"X language natively supports feature Y" means you can use feature Y without any extension or any other effort to make it work. It is directly usable from the language itself.

For example you can say that,

"C++ language natively supports operator overloading."

"Java language natively supports automatic garbage collection", because you don't need to use any other libraries or tools that does automatic garbage collection. It comes with the langauge (and platform) itself.

Improve this answer
9

I'd read native in the contexts you've mentioned as built-in. If a language doesn't provide native support for some feature, you'll need to implement it yourself or find some library or module that provides it.

Another context where you'll see native a lot is with respect to applications on some platform or other. In those cases, it means compiled for the platform as opposed to being somehow interpreted or translated. A native iOS app is one that's written in a language like Objective-C and compiled to code that runs directly on the ARM family of processors (which is what you find in iOS devices).

Improve this answer
5

I'd consider that a misuse of the term. For something to be "native" to a language there needs to be built in facilities for it. Native support for something like unicode would have raw types in the language that implement unicode in some way. Usually though this is not part of the language but part of a library.

IMHO calling something that appears in the language's default library or not doesn't make something native or not.

Some examples:

C++ has native support for classes. C does not. There is no language keywords or type facility that enables the writing and use of classes, you must code them by hand.

I would say though that C++ no more has a native string type than C does. There's a basic_string template in the standard library, but this is not a language facility.

C++11 though would seem to actually have added Unicode support as new keywords and raw types were added to the language itself to facilitate working with Unicode values.

Hope that clarifies the difference I see.

Improve this answer
4
  • Your use of the words "raw types" confuses me. Could you clarify?
    – Jeremy
    May 9, 2012 at 23:04
  • In Python 3, all strings are unicode (there's a separate bytes type), so I think it's fair to say Python supports unicode natively.
    – Brendan Long
    May 10, 2012 at 0:47
  • Python 2 does as well in that it has a unicode type, though it is more painful to use than Python 3. C++ is a weird beast in that so much of what is normally part of a language is in the libraries.
    – Gort the Robot
    May 10, 2012 at 1:58
  • @JeremyHeiler: It appears that "raw types" are fundamental, non-composite, non-library types. For instance, C does have a string type (char[]), and even string literals. Not all "raw types" need to have matching literals , pointers in C for instance do not. (NULL can only be converted to int*)
    – MSalters
    Mar 13, 2014 at 22:38
-1

"Native support" at least in interpreted or JIT-compiled languages typically means code that's basically just a link to precompiled functionality that sits below the interpreter.

In JavaScript, for instance, if you alert window.open in Firefox, you'll probably see a function whose innards say something like "[native code]." While all references are fed to the interpreter and steps need to be taken to establish context and scope, the innards are basically cached and ready to go. window.open for instance, probably calls something from a browser's run-time environment.

This is different from the non-native objects and methods you or somebody else wrote, because in those cases all your statements need to be interpreted/evaluated.

If somebody were using the term in reference to a language that pre-compiles, I would assume they just meant all of the core language stuff that the compiler actually tokenizes and converts to machine code vs. the stuff you define yourself which is more about the structures and references used to link it all together.

Improve this answer
2
  • 1
    That's not native support in the language; that's native support in the library.
    – SLaks
    May 10, 2012 at 11:36
  • Which point are you disagreeing with? Either you're misreading me or I'm not understanding some core concept but that's kind of vague.
    – Erik Reppen
    May 10, 2012 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.