On 06/28/2016 04:24 PM, Rasmus Schultz wrote:
This was just an example of a value object - for example:
class HttpMethod {
private $method;
protected function __construct($method) {
$this->method = $method;
}
public function getMethod() {
return $this->met
This was just an example of a value object - for example:
class HttpMethod {
private $method;
protected function __construct($method) {
$this->method = $method;
}
public function getMethod() {
return $this->method;
}
public static function get() {
On 28 June 2016 20:10:15 GMT+01:00, Pedro Cordeiro
wrote:
>> << HttpMethod::post() >> // equivalent to static method-call
>> HttpMethod::post()
>>
>
>What would this, specifically, do? Would it call HttpMethod::post()
>when
>the class gets instantiated and return its return on a
>ReflectionClass:
> << HttpMethod::post() >> // equivalent to static method-call
> HttpMethod::post()
>
What would this, specifically, do? Would it call HttpMethod::post() when
the class gets instantiated and return its return on a
ReflectionClass::getAnnotations()? Why is it necessary to be able to
evaluate expres
Thanks, Richard and Rowan - this gives me more to work with!
I will work on a new proposal and ask for more input when I have a
draft ready :-)
On Tue, Jun 28, 2016 at 7:56 PM, Rowan Collins wrote:
> On 28/06/2016 17:31, Rasmus Schultz wrote:
>>
>> For another, eager construction means we can f
On 28/06/2016 17:31, Rasmus Schultz wrote:
For another, eager construction means we can filter annotations with
instanceof rather than by class-name, which is much powerful, enabling
you to leverage inheritance - for example, you'd be able to ask
directly for all instances of ValidationAnnotation
On 6/28/2016 6:31 PM, Rasmus Schultz wrote:
> Since the discussion isn't completely dead yet (thank you Pedro and
> Marco), I will just briefly explain what I had in mind for another
> RFC.
>
I want to see this feature happen too but the right way, so let us just
spend some more time wrapping our
Hi Rasmus,
I think you may be onto something here... :)
On 28/06/2016 17:31, Rasmus Schultz wrote:
The UnknownAnnotation object has three properties: class-name,
method-name ("__construct" if constructor was used) and the list of
arguments.
I'm not sure we need an extra UnknownAnnotation cla
Note that I only make comparisons with doc-blocks to point out the
fact that, functionally, they would not be very different from an
annotation feature that solely permits you to annotate with values. A
doc-block is a string, which is a value - an
array/int/float/string/bool is a value. It's only v
I completely agree with Marco. Throwing class-loading errors for
value-object classes is alright. For logic-parsing inside annotations, I
don't feel any need for it. Metadata should be static, IMO, but it could
very well be (and should be) value-objects.
>At the end of the day, what we end up with
Hi Rasmus,
On 27 June 2016 at 20:37, Rasmus Schultz wrote:
> Tonight I started trying to write a proposal for even more simplified
> annotations, e.g. something simple enough that it cannot result in
> fatal errors. I eventually gave up, and here's why.
>
> Essentially, if you have to restrict y
Tonight I started trying to write a proposal for even more simplified
annotations, e.g. something simple enough that it cannot result in
fatal errors. I eventually gave up, and here's why.
Essentially, if you have to restrict yourself to things that cannot
under any circumstances error out, the on
So this thread kind of died, apparently mostly due to some concerns about
possible side-effects.
I would just like to point out one thing: when it comes to
metadata/annotations, whatever you come up with, even if it's something
that allows only constant expressions and simple data-structures, as
o
On 17/05/2016 18:47, Rasmus Schultz wrote:
I don't really understand what closures have to do with annotations, or how
that relates to capturing context.
The point is that, rather than trying to capture context, you can just
as well ask for what you need.
I'm going to use a very contrived exa
On 5/17/2016 7:47 PM, Rasmus Schultz wrote:
> You're not annotating the function - this is just a round-about way of
> annotating the argument.
>
> You would do that directly, like this:
>
> function foo(
> << ValidateRange(0, 100) >>
> int $percentage
> ) { ... }
>
What is this good fo
> I don't really understand what closures have to do with annotations, or how
> that relates to capturing context.
The point is that, rather than trying to capture context, you can just
as well ask for what you need.
I'm going to use a very contrived example, because I really can't
think of any
On 5/17/2016 11:06 AM, Rasmus Schultz wrote:
> I believe I have already stated my position on all of these concerns
> in my last email.
>
Sorry if I cannot keep everything in my mind.
On 5/17/2016 11:06 AM, Rasmus Schultz wrote:
> There's no such thing as optional dependencies - if you depend on
On 17/05/2016 17:21, guilhermebla...@gmail.com wrote:
It all sounds reasonable on #2 what everyone is heavily
forcing/suggesting because of DbC, but it *only* makes sense in the
context of a function call (or a bound object in case of OO members). In
any other case its outcome is unpredictable.
@Rasmus: This approach is too broad, allowing situations like Marco pointed
out. I'd have to vote -1 on it too if you move forward, specially if you
consider things like << "How do I grab this?" >> and other weirdness.
@Rowan: Annotations should be immutable by nature. Still, I would love if
you
On 05/17/2016 04:22 PM, Rasmus Schultz wrote:
I'd like to finish this RFC, but I have two remaining issues.
The syntax is a minor issue - since any valid PHP expression can be
used, the bit-shift ambiguity is technically an issue, however
marginal.
A lot of people commented on the syntax when I
On 17/05/2016 15:22, Rasmus Schultz wrote:
The other issue is the dependency (context) injection example - no one
seems to be able to cite an actual use-case, and if that's the case, I
should probably just remove it from the RFC entirely?
@Larry can you think of a case example in the myriad anno
I'd like to finish this RFC, but I have two remaining issues.
The syntax is a minor issue - since any valid PHP expression can be
used, the bit-shift ambiguity is technically an issue, however
marginal.
A lot of people commented on the syntax when I posted the RFC on
reddit - they don't like it.
Richard,
I believe I have already stated my position on all of these concerns
in my last email.
Short recap:
There's no such thing as optional dependencies - if you depend on a
Doctrine ORM annotation, you depend on that package.
The code should (must) error the moment you try to instantiate th
On 5/16/2016 3:05 PM, Rasmus Schultz wrote:
> I'm sorry, but I think that the idea of meta-data that can't error
> somehow, somewhere, at some point, is completely unrealistic.
>
> And I'd much rather have a simple facility that enables those errors
> to surface quickly.
>
It should error and it
On 16/05/2016 14:05, Rasmus Schultz wrote:
> I'm afraid I don't follow. Why is it a problem to simply add a
> function or class to the global namespace?
>
> << new Memoize() >>
>
> or maybe a class with factory functions for built-in annotations:
>
> << Meta::memoize() >>
Well, those particular na
Rowan,
I'm afraid I don't follow. Why is it a problem to simply add a
function or class to the global namespace?
<< new Memoize() >>
or maybe a class with factory functions for built-in annotations:
<< Meta::memoize() >>
I tend to agree with Richard though, that system directives really
ought
On 5/13/2016 2:57 PM, Davey Shafik wrote:
> 2) I like the idea of Hacks memoize for example, how do you see those being
> implemented? Or don't you?
>
I wrote it in the /attribute grammar/ thread and I write it here again.
Stuff like memoize should be implemented as keywords as part of the
langua
On 5/13/2016 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
-1 again, I am sorry.
The problem is that an annotation by definition is just meta-data. Your
proposal however might result in fa
On 14/05/2016 20:49, Rasmus Schultz wrote:
Dan,
I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.
This doesn't really explain how such a feature would fit it into the
proposal. For instance, how can we avoid the syntax
Dan,
I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.
Benjamin,
I don't think you mean "out of scope" of what 80% want, I think you
mean "beyond the scope"?
I think this will definitely cover what 80% want to achieve, an
On Sat, May 14, 2016 at 1:48 PM, Rasmus Schultz wrote:
> Thank you for your comments!
>
> Benjamin,
>
> I have removed the comment about annotation expressions executing in
> an empty closure, since this example was clearly confusing, and I have
> tried to clarify the fact that annotation express
On 14 May 2016 at 12:48, Rasmus Schultz wrote:
>
> Hack's memoize is an annotation for the language interpreter itself -
> that's beyond the scope of this RFC, but could be implemented in the
> future.
Please can you add something to the RFC that reserves the possibility
to do this, so that it ca
Thank you for your comments!
Benjamin,
I have removed the comment about annotation expressions executing in
an empty closure, since this example was clearly confusing, and I have
tried to clarify the fact that annotation expressions execute in an
empty scope. To be clear, annotation expressions a
On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
> It's an alternative to the proposed Attributes RFC and the (2010)
> Annotations RFC.
>
> I'm attempting with this to de
Love the simplicity of the RFC, but I can already see people doing terrible
things with it:
<< new DateTimeImmutable() >>
<< log(get_instance('logger')) >>
And other global-state related stuff.
TBH, I'd rather just allow a constant array (with constant expressions
only), and that would be good
On 05/13/2016 02:57 PM, Davey Shafik wrote:
> On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
>
>> Dear Internals,
>>
>> I'm announcing a simplified RFC for annotations:
>>
>> https://wiki.php.net/rfc/simple-annotations
>>
>> It's an alternative to the proposed Attributes RFC and the (201
On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
> It's an alternative to the proposed Attributes RFC and the (2010)
> Annotations RFC.
>
> I'm attempting with this to de
37 matches
Mail list logo
