Talk:String (computing): Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Ed Poor
(Shall I try to flesh this out?)
imported>Tom Morris
Line 7: Line 7:


I don't know whether our article should '''begin''' with this problem. Maybe we should write a bit more about what a string is, and give examples in several languages. I can write about Visual Basic, C, Java, PHP and (shudder) "[[JavaScript]]". --[[User:Ed Poor|Ed Poor]] 19:41, 15 April 2010 (UTC)
I don't know whether our article should '''begin''' with this problem. Maybe we should write a bit more about what a string is, and give examples in several languages. I can write about Visual Basic, C, Java, PHP and (shudder) "[[JavaScript]]". --[[User:Ed Poor|Ed Poor]] 19:41, 15 April 2010 (UTC)
== Why I've removed the section on variable casting ==
I'm removing it because I consider it to be egregious bunkum! (Okay, that might be slightly over the top, but
Here is why.
It talks about variable type declaration by comparing Java to Python with the following examples:
<pre>MyPythonString = "This is a string"</pre>
<pre>String MyJavaString = "abc";</pre>
And uses this argument:
"Python "figures out" if that variable is a string based on its content"
But so does Java. Imagine if you have two methods with the following signatures in Java:
<pre>class Bar - public static void foo(String x)</pre>
<pre>class Bar - public static void foo(int x)</pre>
Now, how would you call this?
Like this: Bar.foo("baz")
Now, how is the Java compiler working out that "baz" is a string rather than an int?
I haven't explicitly annotated the argument. It works it out by "checking it is in quotes"!
"This is a string". But this is an integer: 5.
Don't believe me? Read the section of the Java documentation on language literals.
In the Java example, the reason you declare this:
<pre>String MyJavaString = "abc";</pre>
is because you may not have actually assigned the String! It may be null. (Aside: there is a better way! It is alled parameterized Option[T] classes like Scala has.) It may be that you are just saying <pre>String MyJavaString;</pre> because you are declaring this property for later use in your class. But this is not exclusive to strings. You could be declaring it to be an integer or a banana or a Philadelphia cheese-steak.
With the Java example, you aren't even ''casting'' the variable, you are ''annotating'' it. You can cast without annotation, as in an argument in a method call! If I had something which could be cast as a string, I could use it as an argument in a method call like this:
<pre>Bar.foo((String) x);</pre>
In short: I'm removing it because it is about type annotations, not about the actual data type. –[[User:Tom Morris|Tom Morris]] 20:30, 15 April 2010 (UTC)

Revision as of 14:30, 15 April 2010

This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition In computing and more specifically in various programming languages, a variable type that can hold text [d] [e]
Checklist and Archives
 Workgroup category Computers [Categories OK]
 Talk Archive none  English language variant American English

So far, this article has a bit too much (and yet not enough) about how a language like Python may automatically assign a string or numeric type to a variable.

As a programmer, I'd like to point out that the value "123" as a string is merely a series of three characters, while 123 is an integer. In certain contexts, you'd like them to be considered equal, but in others you might not.

  • When append the character "4" to the string, you'd expect to get "1234", which could be a phone extension or a serial number.
  • When adding the number 4 to the number 123 you need to get 127 as a sum.

I don't know whether our article should begin with this problem. Maybe we should write a bit more about what a string is, and give examples in several languages. I can write about Visual Basic, C, Java, PHP and (shudder) "JavaScript". --Ed Poor 19:41, 15 April 2010 (UTC)

Why I've removed the section on variable casting

I'm removing it because I consider it to be egregious bunkum! (Okay, that might be slightly over the top, but

Here is why.

It talks about variable type declaration by comparing Java to Python with the following examples:

MyPythonString = "This is a string"
String MyJavaString = "abc";

And uses this argument:

"Python "figures out" if that variable is a string based on its content"

But so does Java. Imagine if you have two methods with the following signatures in Java:

class Bar - public static void foo(String x)
class Bar - public static void foo(int x)

Now, how would you call this?

Like this: Bar.foo("baz")

Now, how is the Java compiler working out that "baz" is a string rather than an int?

I haven't explicitly annotated the argument. It works it out by "checking it is in quotes"!

"This is a string". But this is an integer: 5.

Don't believe me? Read the section of the Java documentation on language literals.

In the Java example, the reason you declare this:

String MyJavaString = "abc";

is because you may not have actually assigned the String! It may be null. (Aside: there is a better way! It is alled parameterized Option[T] classes like Scala has.) It may be that you are just saying

String MyJavaString;

because you are declaring this property for later use in your class. But this is not exclusive to strings. You could be declaring it to be an integer or a banana or a Philadelphia cheese-steak.

With the Java example, you aren't even casting the variable, you are annotating it. You can cast without annotation, as in an argument in a method call! If I had something which could be cast as a string, I could use it as an argument in a method call like this:

Bar.foo((String) x);

In short: I'm removing it because it is about type annotations, not about the actual data type. –Tom Morris 20:30, 15 April 2010 (UTC)