PHP Annotations RFC + Patch

Sorry, but I don't see how this is even remotely close to being
appropriate for PHP. Maybe I'm missing something. :-)

I agree, the use cases are just not there

Though maybe some form of "annotations" could be useful in php as a
"pluggable type":
http://bartoszmilewski.wordpress.com/2009/01/18/java-pluggable-types/

But this isn't an annotation as just plain metadata, the parser could do
something with the annotation.

i.e.

class Phone {

@ReadOnly
public $id;

@PhoneNumber
public $number;
}

class PhoneNumber implements TypeAnnotation {

static function getTypeValue($val)
{
return preg_replace('~[^0-9]~', '', $val);
}
}

Instead of ~

class Phone {

protected $_number;

function __get($prop) {
if($prop === 'number')
return $this->_number;
}

function __set($prop, $val) {
if($prop === 'number')
$this->_number = preg_replace('~[^0-9]~', '', $val);
}
}

At 17:51 13/09/2010, Gustavo Lopes wrote:

On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski zeev@zend.com
wrote:

At 16:39 13/09/2010, Pierre Joye wrote:

You are not serioulsy suggesting to use phpdoc for runtime
annotation
support? Are you?

I actually am (either that or get what you want done in some other
way). It's a rare enough use case that I think it's a very
reasonable
compromise. The disadvantages of adding a whole new branch of
syntax,
for this rare use case, far outweigh its advantages - IMHO.

Rare use case? Have you seen any recent Java framework? Or Java EE 6?
Or
design by contract in C#? A declarative programming style can be very
handy.

Framework code (as in code that actually goes into a framework, not
code
that uses a framework) represents a tiny percentage of the PHP codebase
at large. Most of it is application code.

You misunderstood me. When I say the frameworks use annotation I don't
mean they use annotations in their own implementation (that's not
particularly relevant for the reason you present).

What I mean is that the frameworks recognize annotations the application
code has so that the framework user can do stuff like injecting objects,
run methods in transactions or check post-conditions in a declarative
fashion, by adding annotations.

By the way, you ignored the rest of the e-mail.

How do you evaluate the complexity/return of features such as annotations
with that of e.g. LSB? Why are they not adequate for PHP, but may be for
other languages?

I do not understand this.

I see no one other than Symfony / Doctrine people pushing for this
annotations patch.

How can this special-purpose feature (which would add entirely new language
semantics in the form of an embedded micro-language) even be open for
discussion, when other, more generally-useful RFCs like
http://wiki.php.net/rfc/shortsyntaxforarrays were shot down on the basis
that they were hard to read and confusing for new developers?

Sorry, but I don't see how this is even remotely close to being appropriate
for PHP. Maybe I'm missing something. :-)

Thanks,

• Nate

It's the same as Zeev said:

"The fact we have complex components in PHP is no excuse to add more
complexity to the language. It's not a binary state, with PHP "already
being complex", so we can add as much complexity as we want. Complexity
accumulates."
The fact that we rejecteded better features in PHP is no excuse to reject
good ideas from the...

at least without a discussion which is just happening.

Tyrael

No, we can't have python decorators because unlike Python PHP functions
and classes aren't first-class objects. In Python, this:

@dec2
@dec1
def func(arg1, arg2, ...):
pass

means this:

def func(arg1, arg2, ...):
pass
func = dec2(dec1(func))

However, you can't write equivalent code in PHP.

I had the same idea regarding decorators, and I saw the same problem
that you see, functions are not first-class citizens in PHP. I was
wondering, though, whether the possibility to assign expressions to
constants couldn't change that. Let me explain a little what I'm
thinking exactly.

Currently, PHP supports lambda expressions and they're pretty much as
first-class citizens as possible. PHP, also supports variable functions
in an attempt to make global functions look like they'd be first-class
citizens.

So, the following snippet isn't yet working, but AFAIK it will work in
the next PHP release:

function foo() {
echo "foo was called";
}

function bar() {
return 'foo';
}

bar()(); // prints "foo was called";

Now, assume I define this constant:

define('foo', 'foo');

Now I can write:

function bar() {
return foo;
}

And the "foo" function will look more like a first-class citizens.
But, how about being able to write:

const foo = function () use ($globalVar) {

};

which would be the desugaring of:

function foo () {
global $globalVar;
}

Now foo would be an instance of Closure, and would allow us to pass it
around free.

Does that make any sense to any of you? Is it at least possible with the
current Zend Engine implementation? What problems would it pose?

Getting back to decorators...

Having the above syntax, we would be able to write:

const func = dec2(dec1(function () {

}));

which can be further sugared to some decorator specific syntax.

I guess the gist of my whole email is that it would be nice to get rid
of the dollar sign in identifiers that designate lambda expressions.
That would somehow level things up.

--
Ionuț G. Stan | http://igstan.ro

Good reminder, thanks! Implementation would indeed require support
from PHP, say:

// magic-method __decorate implies that __construct would return
$this->__decorate(func_get_args(), $f); and enforce @ as
annotation-syntax
class Dec1 {
function __decorate($args, $f) {
return $f;
}
}
class Dec2 { ... }

@dec2
@dec1
function foo() {}

means this:

$foo = new Dec2(new Dec1(new ReflectionFunction('foo')));
Perhaps ... $foo = @Dec2(@Dec1(new ReflectionFunction('foo')));

Hi!

Could PHP as a language be kept "pure" by first implementing python
decorators*, then implement annotations using a purpose-built
decorator?

No, we can't have python decorators because unlike Python PHP functions and
classes aren't first-class objects. In Python, this:

@dec2
@dec1
def func(arg1, arg2, ...):
   pass

means this:

def func(arg1, arg2, ...):
   pass
func = dec2(dec1(func))

However, you can't write equivalent code in PHP.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227