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
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
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
2013.01.08. 6:48, Pierre Joye pierre@gmail.com ezt írta:
hi,
On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs tyr...@gmail.com 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
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
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
hi,
On Sun, Jan 6, 2013 at 10:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com 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
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
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,
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
On Tue, Jan 8, 2013 at 1:36 AM, Pierre Joye pierre@gmail.com 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:
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 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
On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig kris.cr...@gmail.com 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
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans der...@php.net 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
2013/1/8 Lars Schultz lars.schu...@toolpark.com
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
On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans der...@php.net wrote:
This belongs in an extension, just like last time we've discussed
annotations.
Last time we discussed this area, we discussed almost everything
Nuked demoking8
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nuked heavenfactory
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig kris.cr...@gmail.com wrote:
Would a voting option to tie it to the release of a
On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest cpri...@zerocue.com 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 |
On Tue, Jan 8, 2013 at 2:00 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 10:48 AM, Kris Craig kris.cr...@gmail.com 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
On Tue, 2013-01-08 at 12:39 +0100, Pierre Joye wrote:
On Tue, Jan 8, 2013 at 12:25 PM, Clint Priest cpri...@zerocue.com 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
Hi!
On 8 January 2013 06:48, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Jan 7, 2013 at 10:22 PM, Ferenc Kovacs tyr...@gmail.com wrote:
is this about allowing the user to shot him/herself in the foot, or
adding
this feature could potentially break some existing functionality
On Tue, Jan 8, 2013 at 2:18 PM, Johannes Schlüter
johan...@schlueters.de 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
hi,
On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer nicolai.sch...@gmail.com 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,
--
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 probably wasn't
Hi!
On 8 January 2013 14:27, Pierre Joye pierre@gmail.com wrote:
hi,
On Tue, Jan 8, 2013 at 2:24 PM, Nicolai Scheer nicolai.sch...@gmail.com
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
On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Tue, Jan 8, 2013 at 2:36 PM, Johannes Schlüter
johan...@schlueters.de 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)
On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer nicolai.sch...@gmail.com 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...
On 8 January 2013 03:55, Stas Malyshev smalys...@sugarcrm.com 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
Hi!
On 8 January 2013 14:40, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 2:38 PM, Nicolai Scheer nicolai.sch...@gmail.com
wrote:
I agree, but what about pandora and the other file functions like
unlink()
etc.? :)
They currently do not prevent such long and prefixed
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.
On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine les...@lsces.co.uk 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 |
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 2:27 PM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 3:22 PM, Lester Caine les...@lsces.co.uk wrote:
Reflection/Annotations are just another way of 'documenting' classes -
aren't they?
No.
Annotations are used to affect behaviors, define
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
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 ?
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
On Tue, Jan 8, 2013 at 7:03 PM, Steve Clay st...@mrclay.org 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
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 same
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 Stas,
On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
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
Hi again!
On 8 January 2013 14:56, Nicolai Scheer nicolai.sch...@gmail.com 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
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
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 we
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.com 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
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 this
On Tue, Jan 8, 2013 at 10:06 PM, Nicolai Scheer
nicolai.sch...@gmail.com wrote:
Hi again!
On 8 January 2013 14:56, Nicolai Scheer nicolai.sch...@gmail.com 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,
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
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
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
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
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 ras...@mindplay.dk wrote:
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
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, so
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
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
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
62 matches
Mail list logo
