On Fri, May 10, 2019 at 3:40 PM Dustin Wheeler <mdwhe...@ncsu.edu> wrote:
> On Fri, May 10, 2019 at 9:15 AM Lynn <kja...@gmail.com> wrote:
> >
> > 2. Certain features, can be restricted to php-header files only, meaning
> it
> > does not affect
> > "normal" PHP files. This might open up a whole new range of syntax
> > possibilities that
> > are currently blocked, such as `@trigger_error()` vs `@Annotation()`.
> >
>
> Hi Lynn, thank you for opening this discussion!
>
> Could you explain how the range of syntax you suggest (regarding
> annotations) is currently blocked? I'm not challenging your claim; I
> *personally* don't know and am interested. While certainly not
> supported natively, comment-based "annotations" can be implemented in
> user-land and processed via reflection (See doctrine-annotations[1]).
> There has also been previous work and discussion in the annotation
> space [2][3][4][5]. Based on my light reading, I couldn't find any
> objections to annotations with side-effects, but I could see that as
> an argument. However, I'm more curious what your perspective is.
>
Hi Dustin,
Currently with Doctrine Annotations, inspired by that of Java as far as I
know, the syntax
would be ambiguous, at least until the closing semi-colon. I'm no expert on
which syntax is or
isn't possible, I remember this one being a potential issue and introducing
complexity in the
parser due to the silencing operator.
```php
@SomeAnnotation()
class {}
// versus
@SomeFunctionBeingSilenced();
class {}
```
You are correct that annotations are possible via user-land packages. I'm
personally hoping to
see this feature come to native PHP, making it possible to simplify the
usage and possibly
performance. I've been brainstorming around another feature to unify
variable inspections,
which would make annotation reading a whole lot simpler [1], but could also
be done in
Reflection. Annotations are my primary example for header files, as they
share the same
concept, they are declaring code only and they don't have side effects.
> Personally, I really like the idea of being able to declare
> "side-effect free" as a feature. I don't know if I prefer the idea of
> a `phph` file, distinguished by extension (so I'm glad you mention
> alternatives such as `declare`). That said, I think that's mostly from
> shock and not wanting to ever go back to a world that included *.php4,
> *.php5, *.phtml, etc. :)
>
I'm not sure if a `.phph` file extension is required for this feature to
work, though it might
simplify its implementation. While I certainly share your concern about
multiple extensions, my
experience with other languages makes me believe that this would not be
much of an issue. With
header files being an opt-in feature, it hopefully won't make php more
complex for developers
new to PHP.
> Hope all is well,
>
> 1:
> https://www.doctrine-project.org/projects/doctrine-annotations/en/latest/index.html
> 2: https://wiki.php.net/rfc/annotations
> 3: https://externals.io/message/82813
> 4: https://externals.io/message/64895
> 5: https://externals.io/message/64722
>
> --
> Dustin Wheeler | Software Developer
> NC State University
> mdwhe...@ncsu.edu
> "If you don't know where you're going, it's easy to iteratively not get
> there."
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Apologies for my previous message being top posted, I hope this message
arrives in a better format!
Regards,
Lynn van der Berg
1:
https://gist.github.com/linaori/af50c1692e3d360d2e550b05e6121e58#future-possibilities
