On Sun, Apr 24, 2016 at 1:55 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 4/24/2016 1:36 PM, Benjamin Eberlei wrote:
> > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder <p...@fleshgrinder.com>
> wrote:
> >
> >> The invariant could also be added as an additional branch to the class
> >> instead of a method, since it would not work like a method.
> >>
> >> class A {} invariant {}
> >>
> >> function f() {} require {} ensure {}
> >>
> >> This would also align nicely with closures and anonymous classes, which
> >> is kind a problematic with annotations.
> >>
> >
> > You are way off topic with this imho.
> >
>
> No, not at all!
>
> The RFC explicitly mentions design by contract (DbC) and that is why I
> am responding to that.
It mentions DbC as one userland use-case for attributes. This proposal is a
generic
feature that allows DbC, but much other stuff like configuration
(Annotation style).
As a generic buidling block like Dimitry proposes them attributes are
amazing and will
allow many more different use-cases in userland, proposing anything less
generic
will not get wide-spread support considering that these kind of changes
need 2/3 votes.
> I do not think that annotations should or could
> be used for DbC and want to raise this issue here. Of course all of the
> above is a completely different story and requires its own RFC as well
> as implementation. However, DbC should not be used to justify the
> addition of annotations to PHP. (If libraries choose to use it for that,
> different story.)
>
> On 4/24/2016 1:36 PM, Benjamin Eberlei wrote:
> > Attributes as proposed by Dimitry are not executing functions, they are
> > only metadata
> > that can be retrieved through reflection API. I think a python style
> > decorator approach
> > that you propose here, executing functions is not what the different
> > pro-annotations,
> > pro-attributes or pro-DesignByContract fractions want/need.
> >
> > You are proposing something along the lines of AOP, which is an entirely
> > different beast
> > in my opinion.
> >
>
> I know and that is why I am writing that the usage of brackets is not a
> good idea because it suggests exactly that. We need to think about a
> possible feature as outlined by myself (reactive annotations or /Python
> style decorator approach/ as you call it) in order to not implement
> annotations in a way that would kill exactly such a feature in a
> possible future.
> Hence, I am not off topic because I am thinking outside of the box in
> the context of the whole ecosystem. Something that I see not happening
> in this RFC nor its discussion.
>
Using attributes as a generic building block, you could implement a PECL
AOP extension doing the following:
- in every call check if that function/method has attributes.
- if it has an attribute "around(fn)", then call fn around the call
- If it has an attribute "before(fn)", then call fn before the call
- ...
This is similar to what Dimitry wants to do, adding DbC as a pecl extension
would be possible
with attributes, by evaluating the AST Attribute nodes before each function
call.
This is why we need attributes in this generic way, because it opens up
tons of possibilities
in a way that a large majority of php contributors thinks this is
worthwhile adding to the language.
AOP in general however, i doubt will ever be in PHP core similar to DbC,
but attributes allows to add
them easily as PECL extensions.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
