But I can add more.
Filtering
Validation
Form declaration
Database mapping
Joinpoint definitions (AOP)
Service Injection (look at FLOW3)
Testing
etc
Basically everything can define constraints or usage of an element,
behavior, process or nature of an element.
Let me give some individual examples:
On 09.01.2013 02:38, Rasmus Schultz wrote:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API,
There is no DocBlock parser in the Reflection API; you can merely
retrieve the T_DOC_COMMENT token.
and
already g
Unfortunately [] is still not usable because it will introduce syntax
ambiguity with short array syntax. The patch we've done for
annotations would require some small change to work on the new master
version but I can take some time to do it if I see some interest in
the proposal. If someone want t
Hi,
At the time Pierrick and I worked on annotations patch, we couldn't use
some of the operators due to many different reasons:
@ = error supressing
[] = short array syntax
{} = scopr creation
: = all sorts of problems you can imagine
& = array referencing
We actually found that <> was allowed,
If we had true annotations, its certainly something the engine could put to
use... See my previous post in this thread.
-Clint
On Jan 8, 2013, at 7:38 PM, Rasmus Schultz wrote:
> To summarize:
>
> A native implementation of PHP-DOC block parser for run-time purposes
> (annotation libraries)
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API, and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
lib
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete possible
Hi internals,
Just like before, people are confusing documentation support with
behavioral support.
No matter what people say, documentation is documentation and code still
behaves the same with and without the comment docblock. When talking about
behavioral marks, removing that piece makes your c
Hi!
> This functionality parses doccomments and doccomments can be obtained
> through various ways. Reflection is only one. Docblocks can just as well
> come from parsing the files. If this would be tightly bound to the
You can also get functions, classes, etc. from parsing the files. But
from in
On Tue, Jan 8, 2013 at 10:06 PM, Nicolai Scheer
wrote:
> Hi again!
>
>
> On 8 January 2013 14:56, Nicolai Scheer wrote:
>>
>>
>> Do you have any advice how I can move lill' pandora to an extension? Of
>> course I might copy the complete simple_file_wrapper, but I'd rather not do
>> it that way...
> If I read this thread correctly then almost everyone agrees that PHPUnit,
> Symfony, ZF, Doctrine, etc, all use annotations in the DocBlock because
> there
> is no available alternative that enables them to use annotations.
>
Yes, I understood that too.
As far as I am concerned I'd separate th
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:
> Hi!
>
>> Everyone I talked to who implemented annotations in docblocks did it
>> as hack because there is no native support. This is not something that
>> belongs to docblocks. It would be nice if you could take a look at the
>> c# doc, there
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:
> Hi!
>
> > Everyone I talked to who implemented annotations in docblocks did it
> > as hack because there is no native support. This is not something that
> > belongs to docblocks. It would be nice if you could take a look at the
> > c# doc, t
Hi!
> Everyone I talked to who implemented annotations in docblocks did it
> as hack because there is no native support. This is not something that
> belongs to docblocks. It would be nice if you could take a look at the
> c# doc, there are really good concepts there.
I know why they did it, and
On 08.01.2013 18:19, Yahav Gindi Bar wrote:
That's true. But I wish to state my opinion now: the current
annotations
that Doctorine etc. use is a hack. They took the original doc-block
style
comments and use them for storing metadata. that's the reason I think
that
in case we'll implement some
Hi again!
On 8 January 2013 14:56, Nicolai Scheer wrote:
>
> Do you have any advice how I can move lill' pandora to an extension? Of
> course I might copy the complete simple_file_wrapper, but I'd rather not do
> it that way... I did not find any "add standard stream context
> option"-stuff in t
I agree with this very much.
In Doctrine we used Docblocks only because its the only means of
implementing something that closely resembles native annotation support. I
would be happy if we would have a Docblock parser in SPL, so that all
libraries can agree on using its syntax, however ultimately
Exactly. Annotations just don't belong there. Short syntax for arrays got
shut a few times but it finally made it to core. I hope native support will
be revisited at some point.
On Tuesday, January 8, 2013, Pierre Joye wrote:
> hi Stas,
>
> On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev
> >
> wro
hi Stas,
On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev wrote:
> Hi!
>
>> I agree, there is a need in this functionality, but all those userland
>> implementations were at the first place made because this
>> functionality was not part of the language. I think docblocks is not
>> the solution, doc
I do use PHP Unit and also Doctrine which uses annotations. And I know
that today because there is no native annotations, the implementation
use docblocks so I can not remove them :) But still if I did not know
anything about PHP and that someone was talking to me about comments,
I would expect my
Hi!
> I agree, there is a need in this functionality, but all those userland
> implementations were at the first place made because this
> functionality was not part of the language. I think docblocks is not
> the solution, doc blocks are just comments, and I would expect any
> code to work the sa
On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay wrote:
> On 1/8/13 2:56 AM, Christian Stoller wrote:
>
>> But the way 'nullable' properties are defined is not very intuitive and
>> unclean, in my opinion. Stas has already mentioned that.
>> `public DateTime $date = NULL;` // this looks like the proper
On 1/8/13 2:56 AM, Christian Stoller wrote:
But the way 'nullable' properties are defined is not very intuitive and
unclean, in my opinion. Stas has already mentioned that.
`public DateTime $date = NULL;` // this looks like the property is initialized
with null, but it does not show that the pr
Hi,
Firstly - many apologizes for not follwoing along, couldn't be near my mail
yesterday (university...). Many apologizes for the long response too ;).
> .
> There is already a similar RFC here :) Maybe it could be good to start
> from this one so that we don't have any duplicated RFC ?
>
> http
https://bugs.php.net/bug.php?id=63941
Per discussion with Nuno Lopes and Christopher Jones, I have created
another patch to simplify guess_timezone() in ext/date/php_date.c
Internals summary: removes the newly patched in int value that caches
whether a timezone was previously checked or not, as w
On Tue, Jan 8, 2013 at 2:27 PM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine wrote:
>
> > Reflection/Annotations are just another way of 'documenting' classes -
> > aren't they?
>
> No.
>
> Annotations are used to affect behaviors, define services, etc. Check
> out the c# im
Heya,
Actually, annotations became a form of configuration, very powerful when
dealing with AOP and metadata. Very useful when your classes are tightly
coupled with config. If you never came to use them or never felt the need
to use them, fine.
But I wouldn't call it "further complexity without a
On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine wrote:
> Reflection/Annotations are just another way of 'documenting' classes -
> aren't they?
No.
Annotations are used to affect behaviors, define services, etc. Check
out the c# implementation for example.
--
Pierre
@pierrejoye | http://blog.thep
Having been using 'docblock' elements to document classes in PHP for many years,
their use by PHPEclipse and PDE to provide type-hinting and via phpdocumentor to
build developer documentation for classes, I simply haven't seen any need for
some of the more recent developments.
Reflection/Annot
Hi!
On 8 January 2013 14:40, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer
> wrote:
>
> > I agree, but what about pandora and the other file functions like
> unlink()
> > etc.? :)
> > They currently do not prevent such long and prefixed paths...
>
> A bug then, should be
On 8 January 2013 03:55, Stas Malyshev wrote:
> On the contrary, plenty of implementations means there's a need in this
> functionality, and it might be a good idea to have one standard
> implementation if it can cover like 80% of use cases.
I agree, there is a need in this functionality, but all
On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer wrote:
> I agree, but what about pandora and the other file functions like unlink()
> etc.? :)
> They currently do not prevent such long and prefixed paths...
A bug then, should be fixed. Yes, you don't want to hear that but... :-)
> And to my mind
On Tue, Jan 8, 2013 at 2:36 PM, Johannes Schlüter
wrote:
> One thing is to change from "single vote" to "approval voting" (one can
> "aaprove" any of those, sum up, done, one of the best voting systems for
> "winner takes it all" things
> http://en.wikipedia.org/wiki/Approval_voting)
Multiple ch
On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev wrote:
> Hi!
>
> > Why does this need to be part of Reflection? Seems a rather odd place for
> > it IMHO, since it basically hard-codes the functionality into part of the
>
> Reflection is an odd place for functionality that describes attributes
> of
Hi!
On 8 January 2013 14:27, Pierre Joye wrote:
> hi,
>
> On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer
> wrote:
>
> > What do you think?
>
> As I stated earlier, doing so is like opening the pandora box. I would
> rather go with mounted directory and the likes to reduce the length of
> the p
On Tue, 2013-01-08 at 14:25 +0100, Pierre Joye wrote:
> > Whereas 50%-1 vote for "Two years, one normal fixes and one security
> > fixes only" and "With the PHP 5.5 final release"
> >
> > Then the winner will be "One year with security fixes only" and "With
> > the PHP 5.5 final release" which prob
hi,
On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer wrote:
> What do you think?
As I stated earlier, doing so is like opening the pandora box. I would
rather go with mounted directory and the likes to reduce the length of
the path, as long as it is possible.
Cheers,
--
Pierre
@pierrejoye | htt
On Tue, Jan 8, 2013 at 2:18 PM, Johannes Schlüter
wrote:
> Separating the two questions is "strange" and can lead to unintended
> results. They should be combined into one. Example assumption: 50%+1
> vote for "One year with security fixes only" but are split between "With
> the next PHP 5.3 rele
Hi!
On 8 January 2013 06:48, Pierre Joye wrote:
> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs wrote:
>
> > is this about allowing the user to shot him/herself in the foot, or
> adding
> > this feature could potentially break some existing functionality (eg. new
> > trick to bypass op
On Tue, 2013-01-08 at 12:39 +0100, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest wrote:
>
> > Would this 1 or 2 year period begin from release date of 5.3 or as of
> > around now/vote?
>
> See "When should start the EOL period and when should it be announced?"
I don't unde
On Tue, Jan 8, 2013 at 2:00 AM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig wrote:
>
> > Would a voting option to tie it to the release of a future PHP version,
> > rather than a fixed time interval, be appropriate?
>
>
> Like in end it when 5.x is released?
Actually, I wa
On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest wrote:
> Would this 1 or 2 year period begin from release date of 5.3 or as of around
> now/vote?
See "When should start the EOL period and when should it be announced?"
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
P
Would this 1 or 2 year period begin from release date of 5.3 or as of around
now/vote?
-Clint
On Jan 8, 2013, at 4:00 AM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig wrote:
>
>> Would a voting option to tie it to the release of a future PHP version,
>> rather than a fixe
Nuked heavenfactory
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nuked demoking8
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans wrote:
>
> > This belongs in an extension, just like last time we've discussed
> > annotations.
>
> Last time we discussed this area, we discussed almost everything about
> docblock and the like
2013/1/8 Lars Schultz
> Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
>
>> The fact is that the existing syntax for nullable type hinting has its own
>> problems. For example, this is not possible:
>> function foo( Bar $bar = null , $mandatory ) { ... }
>>
>
> Sure it's possible;) I did not ge
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans wrote:
> This belongs in an extension, just like last time we've discussed
> annotations.
Last time we discussed this area, we discussed almost everything about
docblock and the likes but actual annotation. However I do not get
your reasoning, anno
On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig wrote:
> Would a voting option to tie it to the release of a future PHP version,
> rather than a fixed time interval, be appropriate?
Like in end it when 5.x is released? Not sure it helps in anyway, but
that's possible already if we choose to begin t
On Sun, 6 Jan 2013, Yahav Gindi Bar wrote:
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I've created an RFC that propose to
Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }
Sure it's possible;) I did not get a syntax error for that...I even use
On Tue, Jan 8, 2013 at 1:36 AM, Pierre Joye wrote:
> hi,
>
> While the 5.3 RM already unilaterally published some announce about
> 5.3 status with the last release, we still have to clearly and openly
> decide what is the best road to take.
>
> Here is the last version of the rfc:
>
> https://wik
hi,
While the 5.3 RM already unilaterally published some announce about
5.3 status with the last release, we still have to clearly and openly
decide what is the best road to take.
Here is the last version of the rfc:
https://wiki.php.net/rfc/php53eol
If anyone has any other additional options t
Hi!
> Looks good to me, just it could be great to add a new cURL option at
> the same time to disable the '@' usage so that someone working with
> the new ext/curl version can disable it and therefore send values
> starting by @
That is a good suggestion, I'll add CURL_SAFE_POSTFIELDS which would
Hi!
> Why does this need to be part of Reflection? Seems a rather odd place for
> it IMHO, since it basically hard-codes the functionality into part of the
Reflection is an odd place for functionality that describes attributes
of classes, methods, properties, etc.? ITYM "natural place" - that's
e
hi,
On Sun, Jan 6, 2013 at 10:58 PM, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I
On 08.01.2013 09:55, Stas Malyshev wrote:
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
On the contrary, plenty of implementations means there's a need in
this
functionality, and it might be a good idea to have one standa
> It takes up the syntax php has been using for method-definitions.
The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }
I would love to have the question mark syntax for both
2013.01.08. 6:48, "Pierre Joye" ezt írta:
>
> hi,
>
> On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs wrote:
>
> > is this about allowing the user to shot him/herself in the foot, or
adding
> > this feature could potentially break some existing functionality (eg.
new
> > trick to bypass open_based
Hi!
> First of all, there are already plenty of established userland
> implementations - so there is really no need for this.
On the contrary, plenty of implementations means there's a need in this
functionality, and it might be a good idea to have one standard
implementation if it can cover like
I agree with Rasmus on this one.
Userland solutions are enough to support a in-docblock solution today, the
performance gains from making it SPL are too little to matter.
However docblocks are a compromise, and not where these should be.
I do suggest we revive Guilherme's RFC and try once more to
Am 08.01.2013 08:56, schrieb Christian Stoller:
But the way 'nullable' properties are defined is not very intuitive and
unclean, in my opinion. Stas has already mentioned that.
`public DateTime $date = NULL;` // this looks like the property is initialized
with null, but it does not show that th
62 matches
Mail list logo
