Zend Weekly Summaries Issue #350

      Comments Off on Zend Weekly Summaries Issue #350

TLK: How to run multiple PHP module versions
REQ: Let blocks
TLK: Namespaces
TLK: Ctype
TLK: POSIX regex… or was that Unicode?
REQ: Type hinted return values in PHP 5
TLK: Unknown options
REQ: private_write/protected_write properties
CVS: Derick does Windows
PAT: __callStatic() in HEAD

TLK: How to run multiple PHP module versions

Arnold Daniels had been away, and had missed the noisy debate last week about
how best to run multiple PHP versions on Apache. He wrote that his own shared
hosting company have solved the problem by running multiple instances of
Apache. Switching between PHP versions is a simple matter of switching the IP
address in DNS; only one Apache httpd install is required, and the users could
simply choose their preferred PHP version in their hosting control panel.

As if that weren’t enough, Arnold also wrote a howto explaining the approach a
few months ago and posted it on his personal blog.

Strangely, there was no response to his message. Hopefully that wasn’t
because everybody missed it…

Short version: No more queries about this on internals@,
please!

REQ: Let blocks

No sooner had namespace support made its way into CVS HEAD than Lars Gunther
was back on internals@ asking whether let blocks ‘as in
JavaScript 1.7+
‘ had ever been considered for PHP? Stas Malyshev and
someone named Daniel Jänecke wondered aloud why anyone might want it.
Lars took this as an admission that the idea had never come up for
discussion, and promptly opened one.

Tony Dovgal asked, rather tersely, whether Lars had a patch to implement let
blocks for review and discussion. Lars admitted that he had not. Tony replied
that the only two ways to get a new feature into PHP were a) to convince the
development team that the feature was critical, or b) to write it yourself,
with or without help from the team members. He added almost as an aside that
it takes between three and five years for new functionality to appear on
shared hosts – the implication being that following the current fashion is
not an option.

Lars thought that having features that already exist in JavaScript ported to
PHP would be helpful for PHP newbies, and this feature in particular struck
him as ‘namespaces light‘. Stas replied that, in his opinion,
JavaScript is a far more complicated language than PHP, and he felt that most
newbies would neither need nor understand the concept behind let blocks with
advanced scoping rules.

Short version: That’ll be a ‘no’, then.

TLK: Namespaces

Arpad Ray believed he’d found a bug in the new namespace implementation, and
posted a bunch of test files for it. He’d found that, when a namespace is
declared in on file and imported in another, classes need to be addressed as
absolute either in the import or when used, and functions must be addressed
absolutely when used, irrespective of imports. Stas Malyshev took a look; the
first ‘bug’ turned out to be expected behaviour, but he was less certain about
the second.

Somehow this degenerated into yet another discussion about namespace
separators, but that part of things was mercifully brief.

Later in the week, Timm Friebe announced that he’d backported the namespace
support in CVS HEAD to apply cleanly against the PHP_5_2 branch. He made his patch
available
and then wisely disappeared.

Guilherme Blanco appeared, chasing after curly braces again (read: more than
one namespace per file). He was also interested to know whether
overwrite would be implemented, as in:


overwrite function strlen( ... ) { ... }


Guilherme also asked how PHP would behave when faced with a naming conflict,
and whether namespaces in PHP would ever support constants. Stas responded to
Guilherme’s questions point by point. There was no perceived need for curly
braces at present, but that might change; it wasn’t clear what Guilherme
expected his overwrite keyword to do; Guilherme’s third question
illustrated a misconception on his part; and future namespace support for
constants is unlikely.

Short version: Enthusiasm abounds.

TLK: Ctype

There had been a long-ish discussion between Alexey Borzov and Lukas Smith on
the PEAR developers’ mailing list about the reliability (or otherwise) of the
ctype extension. Lukas – who believed ext/ctype to be on the list for
deprecation in PHP 6 – forwarded that discussion to internals@ for
clarification after Alexey avowed that the only source for this information
on the entire www was Lukas himself. Lukas had checked, and found that Marcus
Börger was responsible for adding ext/ctype to the list on his PHP
6 TODO wiki. Alexey had also checked, and found no trace of that decision
either in the internals mailing list archives or in the Zend weeklies. In
fact, the most recent reference to it in the weeklies had been in
November 2006
and stated that the ctype extension was
Unicode-ready….?

Johannes Schlüter responded. He explained that, since ext/ctype
isn’t UTF-16 aware, it can’t actually work with PHP 6 Unicode strings. It
will therefore be replaced in the Unicode context with ICU functions. Perhaps
PEAR’s PHP_Compat or similar might use ctype functions wrapping
ICU, but it wouldn’t make good sense to do that in any other context.

Lukas, after a scarily brief gap in time, followed up with the explanation
Stefan Walk had given on the PEAR list. It seems the ICU-based
char_is_*() functions are much cleaner and easier to use than
their ctype_*() equivalents. It therefore makes perfect sense to
deprecate the older functionality, if only to ensure that PHP users are made
aware of better alternatives.

Short version: Old extensions just fade – ctype will be around for
a few years yet.

TLK: POSIX regex… or was that Unicode?

Jani announced that he’d moved the POSIX regex dependant functions into
ext/ereg (did I miss something?) and was considering what to do about
the two places left in the PHP distribution that still use them. Should he
upgrade the code to use PCRE instead, or should he alter the configuration so
that PCRE is POSIX compatible? Jani ended his query with a note that
ext/ereg will end up in PECL either way, just in case anyone was
swayed by that consideration.

Someone was swayed by that consideration. Andi Gutmans, although agreeing
with the silent majority that PCRE would be the better way, thought Jani was
talking about moving ext/ereg to PECL with immediate effect, and
wanted to know where and when this decision had been made. Jani pointed him
to Paris, November
2005
. Many people – including Derick Rethans, who wrote those notes –
mentioned that no solid decision had been made during the PHP 6 planning
meeting about the future of ereg. Andi hoped to postpone making that
decision and research its likely impact, but there was a groundswell of
support for pushing PCRE as the better option. Lukas was concerned that
postponing the decision would lead unerringly to a lack of information among
PHP users; he thought a clear decision should be made, and ext/ereg
deprecated in PHP 5.3 in preparation for removal in PHP 6. Tony, Jani and
Pierre all backed Lukas.

Andi argued that having a large user base means every decision made is a
trade-off; if the devs didn’t want that limitation they should perhaps write
a new language. Lukas pointed out that he’d never suggested breaking BC
just for the hell of it.’ His objection was to delayed decisions,
since these are likely to mean either that users don’t get enough notice of
pending changes, or that the changes themselves are postponed indefinitely to
the detriment of the language. In the same vein, postponing a decision about
the unicode.semantics switch made no sense to him…

When a can of worms opens, this is exactly how it sounds.

Andi wrote patiently that it had been agreed a long time ago to give users
both options in PHP 6, and went on to talk about his plans for application
testing to build up a picture of migration issues. A fair amount of flak
started flying around at this stage, and Zeev Suraski put in a surprise
appearance to support Andi. Zeev wrote that the internals list is not
representative of the user base as a whole, and put in a plea to the core
devs to see things the way an average PHP user might. He added the long-honed
paragraph about the way BC breakage accumulates (see weeklies passim) and
affirmed that moving ext/ereg out of PHP 5 would be a seriously bad
idea. Derick enlightened him, and Jani finally cracked and admitted that he’d
been talking about CVS HEAD all along. Pierre informed Zeev that the Unicode
switch was far more important than ereg anyway, and started talking
about the migration path.

It quickly became apparent that Pierre and Zeev had drawn completely
different conclusions from the same events with PHP 5. Pierre believed that
people will only migrate when they absolutely have to, and anything the dev
team did to preserve BC went against the language more than it helped its
users. Zeev believed that a widespread misconception about the level of
compatibility breakage prevented mass migration to PHP 5, and didn’t see how
fulfilling that misconception in PHP 6 could be helpful in any way. He also
disliked the idea of turning unicode support off in PHP 6, because it would
mean having to provide full support for PHP 5 for the duration of its
lifetime and beyond. PHP 6 offered the choice of Unicode support or not, and
Zeev was sure that most people migrating older software would migrate it to
run under unicode.semantics=off. Taking away that option would,
in his view, bring a strong risk of losing the PHP user base.

Rasmus Lerdorf joined in the fray. He ran through two perspectives, the
internals view and the users’ view. For the core developers, a dual tree, if
the dissidents get their way. PHP 5 never dies and comes to have everything
PHP 6 has with the single exception of Unicode support. A dual class of
developers work on PHP, those who need Unicode and those who do not; merges
become problematic; possibly the Unicode effort would die a death through a
lack of resources. The users fall into two broad groups: those working in
controlled environments, who shouldn’t have a problem over the Unicode switch
unless/until they deal with third party code, and those who strive to build
portable applications, who will be hit hardest by it. The question, wrote
Rasmus, was whether those not planning on writing two sets of code should be
PHP 5 only, or simply non-Unicode. That said, a lot of legacy code would
‘just work’ in Unicode mode; Rasmus would prefer to see everyone putting
their energy into making that happen as much as possible. Or was the real
argument about whether the team should be trying to implement Unicode support
at all?

Lukas wondered whether it would be easier to maintain PHP 6 with the switch
or maintain two trees; he had no way to know. He also wondered if some
members of the team would only work on and test the non-Unicode mode, if the
switch stays. To him, the question was whether to handle all the ‘if’s in a
single tree or have a clean separation. Lukas also had concerns about
documenting a single branch with a Unicode on/off switch, and asked PHP
Manual editor Philip Olsen for his views on the matter.

What Philip had to say was interesting. He asked about PHP 7. “Would we
have 5/7, 7/8, or just 7 with Unicode? In other words, coupled PHP versions
forever?

Everyone else started turning things on their head too. Johannes asked Zeev,
How much harm should we do to users who develop new things in order to
make lives simpler for these who need BC?
” Pierre got busy suggesting
that the BC breakages between PHP 5.0 and PHP 5.2 might have been more of an
issue to users than the BC breakages between PHP 4 and PHP 5. Lukas put in a
swift word of blame for E_STRICT. Meanwhile Jani was suggesting
to Rasmus that calling ‘the beast‘ uPHP might be a smart move.

Drupal developer Larry Garfield spoke up. The Drupal team are looking at
having to make their software run under PHP 5, PHP 6 with Unicode off, and
PHP 6 with Unicode on, thanks to the nature of its usage environment(s):

Somehow the discussion lurched sideways into an exchange about the wisdom or
otherwise of using a u prefix on function calls to make the
switch seamless. The general consensus was that this probably wasn’t such a
neat idea as it might seem – not least because the python team are pulling
away from that self-same approach for their next major release.

Short version: Ereg is not Unicode-friendly.

REQ: Type hinted return values in PHP 5

One David Duong wanted to see support for type-hinted return values in PHP
5.*, rather than waiting for PHP 6. He pointed out that they are conceptually
the second half of the type-hints already supported in PHP 5. Without them,
the interface designer is unable to take responsibility for the return type,
and the onus is shifted onto the caller to handle whatever is returned.

David’s request met with one of those long silences.

Someone named Troels Knak-Nielsen (really?) wondered whether there might be a
technical reason for not implementing type-hinted returns, or whether some
design decision lay behind it.

Johannes explained that it’s more likely that this feature just doesn’t take
priority for any of the currently active core developers. He added that the
change couldn’t be applied in the 5_2 branch anyway, as it would break back
compatibility; perhaps David might have more luck when the upcoming PHP_5_3
branch is opened for development.

Stas didn’t see much need for the feature in the first place, and wrote that
good documenting practices and a decent IDE‘ would achieve the same
goal.

Short version: Nope.

TLK: Unknown options

Rasmus Lerdorf posted a ‘thank you’ note on internals@. He’d just discovered
one of Jani Taskinen’s latest bits of kit – a new configuration check that
reports unknown options in a PHP configure line. An elderly build script
Rasmus had been using forever had triggered no less than four ‘unknown
configure option’ reports; he wouldn’t have known the script was out of date
otherwise.

Tony added his own praise; the new check had helped him locate a hitherto
unsuspected minor error in the ext/oci8 build.

Jani acknowledged his well-earned laurels, but noted that any third-party
extension using the AC_ARG_* macros will currently be reported
as ‘unknown’. (He’s replaced these macros with PHP-specific versions
throughout the core.) Rasmus didn’t see this as a concern, since the check
only exists when extensions are built in the main source tree; the number of
people doing that with non-core extensions ‘can probably be counted on one
hand
‘.

Gwynne Raskind promptly stood up to be counted. A bemused Rasmus asked her
why, but then Arnold Daniels stood up to be counted too. He wrote that, as a
small ISP, it’s sometimes easier to make a build with the existing PHP
version and new PECL packages. Rasmus replied that Yahoo! – and most distros
– create separate packages where possible, so that an update to any single
component has the lowest possible impact. Arnold explained that his company’s
just a tad smaller than Yahoo! and their priorities are not the same. From his
perspective, it would be nice if the new check also worked for added packages.
Jani reported that the check works for everything except phpize‘d
builds, and added that he had every intention of fixing the few PECL
extensions that currently use AC_ARG_* in any case.

Short version: It’s Jani’s week.

REQ: private_write/protected_write properties

Although recognizing that he was likely asking for a lynching just by raising
the topic, Arnold asked again for private and protected property writes in
PHP. He wanted to be able to get a class property publicly, but only be able
to set its value from within the class, and the existing workarounds for
doing so still felt like workarounds to him.

Sara Golemon explained that there are ‘a few caveats‘ here with regard
to objects, resources and arrays, and illustrated some of the problems in
code:


class
foo {
    public
$bar = 'baz';
}

class myclass {
    
protected_write $f;
    
private_write $fp;

    function __construct() {
        
$this->f = new
foo;
        
$this->fp = fopen('somefile.txt', 'r');
    }
}

$m = new myclass;

$F
= $m->f;
$F->bar = 'blong';

$FP = $m->fp;
fclose($FP);


Jani explained further: this translates to a ‘no’.

Short version: Problematic at best.

CVS: Derick does Windows

Changes in CVS that you should probably be aware of include:

  • In the LDAP extension, bug
    #42015
    (ldap_rename() gets server error “DSA is unwilling to
    perform”) was fixed [Jani]
  • In ext/odbc, bug #42019
    (configure option --with-adabas=DIR does not work) was fixed
    [Jani]
  • In ext/sockets, duplicate bugs #36796, #36918 and #41371
    (stream_set_blocking() does not work) were fixed [Jani]
  • Core bug #41989
    (move_uploaded_file() & relative path in ZTS mode) was fixed
    [Tony]
  • In ext/spl, bug #41691
    (ArrayObject::exchangeArray hangs Apache) was fixed [Tony]

In other CVS news, Derick – of all people – did some work on the Windows
build system. A user defined template.rc can now override the default
files. This allows the extension version to show up among the built extension
DLL properties, rather than the PHP version that the extension is built
against.

Short version: Wonders will never cease.

PAT: __callStatic() in HEAD

Given that there had been no response to Ignacio Arenaza’s LDAP patch last
week, Pierre-Alain Joye suggested that he might open a bug report and post
the patch URL there. Ignacio promptly complied in bug #42060.

Sara Golemon had refined her __call_static() patch and fixed the
bugs found in the original implementation. She also renamed her proposed
userspace function to __callStatic(). There was no further
feedback, so Sara committed the changes into CVS HEAD herself at the end of
the week.

Nicolas Bérard-Nault offered a trivial patch to register the
ext/sockets constants MSG_EOR and MSG_EOF.
Jani later committed his changes in CVS HEAD and the PHP_5_2 branch.

One Mattias Bengtsson offered a one-line patch to prevent large negative pad
lengths from bypassing the checks in str_pad(). Again, Jani
later committed Matthias’ change.

Short version: Waiting on an LDAP patch review.