PHPIDX Open Blog

I recently came across a dialog at work where two experienced PHP developers analyze class and function naming in PHP 4.3.x. The dialog begins with the question, “Is it acceptable to name a class Null in PHP”? You may ask - why would I care? Or, why is this an issue? It’s not really, in fact the best way to avoid problems with naming is to avoid keywords as class for function names. However, if you really need that flexibility, this dialog should be of use.

So what is empty() ? it is not a function? In a class, it becomes a class method, not a language function. If you typed, just empty, it could also be a defined string. As, I said, it is the language parsing. ahh.. php

From: Griggs Domler

They aren’t quite functions, you can name a class the same as a function (built-ins like “fopen”, some user function) without any issue. The problem is simply the parsing rules.

Anything on this list:
http://us.php.net/tokens

Shouldn’t work as a class/function name (well, the ones present in version 4 anyway.)

From: Gokce Toykuyu

Empty, include (even though it is a construct) are functions. The language expects a parenthesis following those keywords. You could have a class called “false”, and it should work. As you said, it is just related to the language parsing, and well, language interpreter itself. ahh, PHP.

From: Griggs Domler

Interesting, it appears that null, false and such aren’t parsed as separate tokens (as I was thinking). But try making a class named “empty”, “include”, etc…

Also, the include_path argument to fopen has been available since at least PHP 4.3.0 (I can’t find exactly when it was added.) Making it a viable alternative to the userland function that iterates the include path to check for a files existence. (probably faster)

From: Gokce Toykuyu
As I thought, PHP allows this. Well, PHP 4.
<?php
class null {
function hello() {
echo “hello\n”;
}
}
$myNull = new null();
$myNull->hello();
?>

Something to be aware of when using any of the ctype_ functions. Unlike most PHP built-ins the ctype extension does not do an implicit cast to string, instead it has two behaviors:

If you pass in a string type it works as expected, iterates the string and calls the unix function “isdigit” for each character, returning false on the first non-digit.

But pass in an integer and it treats it as an single ASCII character, calling the “isdigit” function once. The ASCII range for numbers is 48-57 So, “ctype_digit(47) == false”, “ctype_digit(48) == true”, “ctype_digit(58) == false”. Further, if the number is between -128 and -1 it will add 256.

Anyway, something to be aware of. For safety sake you should cast any variables that might even potentially be a non-string to string when using the ctype_ functions.

For reference, here’s the C macro source, used in all ctype_ calls. “iswhat” expands to the unix function name. “isdigit” in this case.

/ext/ctype/ctype.c

#define CTYPE(iswhat) \
zval *c, tmp; \
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, “z”, &c) == FAILURE) \
return; \
if (Z_TYPE_P(c) == IS_LONG) { \
if (Z_LVAL_P(c) <= 255 && Z_LVAL_P(c) >= 0) { \
RETURN_BOOL(iswhat(Z_LVAL_P(c))); \
} else if (Z_LVAL_P(c) >= -128 && Z_LVAL_P(c) < 0) { \
RETURN_BOOL(iswhat(Z_LVAL_P(c) + 256)); \
} \
tmp = *c; \
zval_copy_ctor(&tmp); \
convert_to_string(&tmp); \
} else { \
tmp = *c; \
} \
if (Z_TYPE(tmp) == IS_STRING) { \
char *p = Z_STRVAL(tmp), *e = Z_STRVAL(tmp) + Z_STRLEN(tmp); \
if (e == p) { \
if (Z_TYPE_P(c) == IS_LONG) zval_dtor(&tmp); \
RETURN_FALSE; \
} \
while (p < e) { \
if(!iswhat((int)*(unsigned char *)(p++))) { \
if (Z_TYPE_P(c) == IS_LONG) zval_dtor(&tmp); \
RETURN_FALSE; \
} \
} \
if (Z_TYPE_P(c) == IS_LONG) zval_dtor(&tmp); \
RETURN_TRUE; \
} else { \
RETURN_FALSE; \
} \

/* }}} */

/* {{{ proto bool ctype_digit(mixed c)
Checks for numeric character(s) */
static PHP_FUNCTION(ctype_digit)
{
CTYPE(isdigit);
}
/* }}} */

What is JSON?

JSON, an acronym for, javascript object notation is a structured way of defining complex data types. Big deal right? You may be saying in the back of your head, I’m going to stick with XML. And my response to that is - use what is best for the task at hand.

What are the benefits of using JSON?

• Runtime efficiency - Would you really parse xml with javascript and no real legitimate debuggers besides and an alert function?
• Compatibility - the JavaScript eval function enables you to import and execute a JSON object. JSON is imported into an object which allows simple access to the data. The tedious and logical task of parsing is black box which means less development time.
• AJAX flare - with all of the hype surrounding AJAX, JSON is a sexy medium to communicate action. Not to mention it’s size is very slim compared to XML.

Example 1.

{"menu": {
                 "items":  [
                                   {"value": "New", "onclick": "CreateNewDoc()"},
                                   {"value": "Open", "onclick": "OpenDoc()"},
                                    {"value": "Close", "onclick": "CloseDoc()"}
   	                      ]
  }}

Looping:

var Obj = eval(JSON_STRING);

for(i=0;  i < Obj.menu.items.length; i++)

{

	........action here

}

* As you can see a { refers to an associative array reference by a potentially non numeric key.  Usually the key is a descriptive string.