In PHP, do associative array indexes need to follow that same rules and variable names (can't start with a number, etc.) I am looking for both working and philosophical answers to this question.
From the manual:
A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.
In their example, using something like $array["08"] is perfectly acceptable and will count as a string, though as you ptobably know, it's highly not recommended. Always name your variables logically.
no, associative arrays can have numerical keys. any valid string can be an index. as far as code styles and clarity, the important thing is that is the keys make sense and are readable.
as far as convention goes, often to differentiate between variable names and indexes I've seen people use lowercase letters and underscores. Although tedious, I find it increases readability because the eye expects a small-case index for an array named usually with one word: array['array_index'] looks good; array['arrayIndex'] is often harder to read in some code.
An array key can be an integer or any valid string, according to the manual.
From a philosophical standpoint, the key should make sense in context and add to the readability of the code.
No, they can be any string, even a binary one.
Related
The in_array function is very slow for large arrays due to doing a linear search.
A faster alternative is to search the key of the array.
Thus
if (isset($array[$val]))
is much faster than
if (in_array($val,$array))
for large arrays. However using unicode as array keys will not work.
Is there an alternative way to do this for unicode without resorting to linear searches such as in_array or array_search or generating hashes like md5?
You can use anything as key which can be converted into a string.
Compare: Characters allowed in php array keys?
But nevertheless apparently some poeple have problems with special characters in their array-keys. I bet this may be the case if you use different encodings at the time you store the key and when you search for it. For example your keys come from a database using UTF-8, but when you search you have the key you search for hardcoded in a Iso-encoded PHP-script. This is just an example, there are dozens of scenarios like this.
To ensure you always use the same encoding I would use rawurlencode.
I'm not sure if this is specific question for Cassandra or this can also belong to PHP so I'm sorry for tagging PHP.
So basically i'm ordering some long row columns by their column names, which goes like this:
2012-01-01_aa_99999 | 2012-01-01_aaa | 2012-01-12_aaaaa
So this is working the way i want it to work, but i don't understand how does it actually order those string.
What is not clear to me is that first string 2012-01-01_aa_99999 seems to be way bigger then the rest two, and i'm concerned that at some point it might ignore first part of the string which is a date and put some string where they shouldn't belong.
In my case those string consist of quite a few parts so i'm really concerned about this, so basically i need some explanation how does this ordering happens internally.
i don't understand how does it actually order those string.
The strings you provided appear to be lexicographically ordered.
I had the same question as I want to construct a composite primary key index with well-understood sorting abilities. It turns out Cassandra appears to compare UTF-8 strings using a byte-by-byte binary comparison... this is indeed a completely broken sort function from a logical perspective. If you had mixed ASCII and Kanji characters in your string, for example, your sort order would be effectively random. However, as long as this sort order is known, one can design your usage patterns around it.
This could be easily fixed, of course, and it would be nearly a single-line change of code to patch in a "real" sort function. This would require a bit extra CPU time, of course.
I need to ask that what is string in PHP. Is it an array in PHP or not. Please give true justifications.
A string in PHP is essentially a byte array (but not in the sense of a PHP's "array"); i.e., it's a buffer with only one piece of meta-data -- the size of the buffer.
An array in PHP is a double-linked hash table map, where the keys can be integers, strings, or a mixture of both.
In terms of PHP's type system, strings and arrays are two of the basic types.
You can read the documentation about php strings at
http://www.php.net/manual/en/language.types.string.php
http://php.net/manual/en/language.types.array.php
In PHP, a string is a primitive type, meaning it's not an array. See here for the other primitive types supported by PHP.
Is there a recommended way of sending an object using json between a server and a client ?
Should I use only lower case for properties, should I use an object or an array ?
Update: this question came to me because by default php is encoding an associative array as an object ( after you decode it)
You should make an array, then use PHP's json_encode method. It doesn't matter if the values are uppercase or lower case.
$a = array(
'Test' => 42,
'example' => 'Testing'
);
echo json_encode($a); // {"Test":42,"example":"Testing"}
When decoding in PHP, pass true as the 2nd parameter to json_decode to convert objects to arrays.
$data = json_decode($json, true);
Both these things are entirely up to you.
The casing of your property names is a coding style matter. It really doesn't matter as long as you are consistent -- your project should have fixed standards on this type of thing. If you haven't picked your standards yet, my advice is to go for readability, which usually means lower case or camel-case. I'd avoid upper case, and I'd also avoid using hyphens or underscores, but it is entirely up to you.
As for the choice between objects or arrays, that comes down to what is best suited to the data in question. If it needs named keys, then use an JSON object (ie with curly braces and key:value pairs {'key':'value','key2':'value2'}); if it doesn't, then use an JSON array (ie with square brackets and just values ['value1','value2']). The choice is entirely down to how the data needs to be structured: both are perfectly valid in JSON and neither is better than the other; just used for different purposes.
(PHP, of course, doesn't differentiate -- both keyed and indexed data are stored in PHP arrays, so from the PHP side it makes absolutely no difference).
Naming conventions aren't standardized, you can use whatever you like. It is a good idea to use names that are also valid javascript identifiers and won't clash with javascript keywords. Object vs. array is not a matter of convention, but rather one of meaning. A JSON object is a key-value collection, while an array is a flat list. Those are different things, and even though the syntax for both is somewhat interchangeable in javascript, and PHP can implement both using the same data type, you should make a clear distinction in your design. If it's a flat list, use []. If it's a key-value thing, use {}. On the PHP side, simply use arrays for both: numerically-indexed arrays for [], associative arrays for {}.
a:3:{i:0;i:4;i:1;i:3;i:2;i:2;}
Am I right to say that this is an array of size 3 where the key value pairs are 0->4, 1->3, and 2->2?
If so, I find this representation awfully confusing. At first, I thought it was a listing of values (or the array contained {0, 4, 1, 3, 2, 2}), but I figured that the a:3: was the size of the array. And if 3 was the size, then both the keys and values appeared in the brackets with no way of clearly identifying a key/value pair without counting off.
To clarify where I'm coming from:
Why did the PHP developers choose to serialize in this manner? What advantage does this have over, let's say the way var_dump and/or var_export displays its data?
Yes that's array(4, 3, 2)
a for array, i for integer as key then value. You would have to count to get to a specific one, but PHP always deserialises the whole lot, so it has a count anyway.
Edit: It's not too confusing when you get used to it, but it can be somewhat long-winded compared to, e.g. JSON
Note: var_export() does not handle
circular references as it would be
close to impossible to generate
parsable PHP code for that. If you
want to do something with the full
representation of an array or object,
use serialize().
$string="a:3:{i:0;i:4;i:1;i:3;i:2;i:2;}";
$array=unserialize($string);
print_r($array);
outpts:
Array
(
[0] => 4
[1] => 3
[2] => 2
)
If think the point is that PHP does not differentiate between integer indexed arrays and string indexed hashtables. The serialization format can be used for hashtables exactly the same way: a:<<size>>:{<<keytype>>:<<key>>;<<valuetype>>:<<value>>;...}
As the format is not intended to be human readable but rather to provide a common format to represent all PHP variable types (with exception of resources), I think it's more simple to use the given format because the underlying variable can be reconstructed by reading the string character by character.
Serialized PHP data is not really intended to be human readable - that is not a goal of the format as far as I know.
I think the biggest reason the format looks the way it does is for brevity, and its form may also have underpinnings tied to the speed at which it can be processed.
Why don't you use the unserialize() function to restore the data to how it was before?