On 04/23/2016 06:29 PM, Fleshgrinder wrote:
+1 for the basic idea, however, I have various remarks.
The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?
I would need a co-author :)
I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.
Different languages names this differently.
I may add an additional voting question - "annotation vs attributes?".
I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.
completely disagree.
Each value in multi-value attribute may have its own meaning. e.g.
<<if(Condition,OnTrue,OnFalse)>>
I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:
ANNOTATION = "@" NAME [ " " VALUE ]
NAME = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION = PHP-CODE ";"
A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.
<?php
$name = "Richard Fussenegger";
$email = "p...@fleshgrinder.com";
@author "{$name} <{$email}>"
class A {}
<<author("{$name} <{$email}>")>>
class B {}
?>
Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:
EXPRESSION = "(" PHP-CODE ")"
Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.
Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:
<?php
@author 'Richard Fussenegger <p...@fleshgrinder.com>'
@copyright '2016 Richard Fussenegger'
@license 'MIT'
declare(strict_types=1);
namespace Fleshgrinder\PhpInternals;
@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {
private const int MIN_BALANCE = 0;
private int $balance;
private Person $owner;
@require $sum >= 0;
@ensure $this->balance === (old::$balance + $sum);
public function deposit(int $sum): void {
$this->balance += $sum;
}
@require $sum >= 0;
@require $sum <= $this->balance - self::MIN_BALANCE;
@ensure $this->balance === (old::$balance - $sum);
public function withdraw(int $sum): void {
$this->balance -= $sum;
}
@deprecated 'for various reasons'
public function setOwner(Person $wner): void {
$this->owner = $owner;
}
}
@inheritDoc
class OverdraftAccount extends Account {
private const int MIN_BALANCE = -1000;
}
?>
You should try to implement this syntax to understand the problem.
It leads to parse conflicts.
We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.
This RFC is not going to propose coding standards.
We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.
<?php
use Doctrine\ORM;
@ORM::entity
@ORM::table [
'name' => 'user',
'unique_constraints' => [
'name' => 'user_unique',
'columns' => [ 'username' ],
],
'indexes' => [
'name' => 'user_idx',
'clumns' => [ 'email' ],
],
'schema' => 'schema_name',
];
class User {}
?>
Agree. Namespaces looks better than "__" prefixes.
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
