Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of DocBlocks.
This also forms the basis of many of the IDE in-line help material. Producing
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I would ask you to take a look at that and use it
as
basis for the parsing of DocBlocks.
This
hi,
On Thu, Jan 3, 2013 at 4:59 PM, Steve Hanselman ste...@brendata.co.uk wrote:
Before I look into this further, can someone confirm that fopen on a zip
stream should return something other than a null?
Can you open a bug please and add a link to the zip file you use?
--
Pierre
@pierrejoye
Hey everybody,
I've been following this list for a while (1-2 years) and this is the
first message I'm sending.
In my oppinion, annotations in docblocks are a bit(a lot) hacky and
making it even worse by adding them to core is not the best idea.
This is how I think annotations have to look like
Yahav and all,
On Sun, Jan 6, 2013 at 4: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
This is what I was going for. Your idea looks better.
On Mon, Jan 7, 2013 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Yahav and all,
On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi internals!
In one of the discussions (about the deprecated keyword,
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 @
Pierrick
On 7 January 2013 01:40, Stas Malyshev smalys...@sugarcrm.com wrote:
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of
On Mon, Jan 7, 2013 at 4:50 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I
I wanted some thought from you guys about the idea of giving PHP scripts the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
Class ReflectionZVal {
// Retains info about the variable
Nathan,
On Mon, Jan 7, 2013 at 12:10 PM, nat...@starin.biz wrote:
I wanted some thought from you guys about the idea of giving PHP scripts
the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
On Mon, Jan 7, 2013 at 6:10 PM, nat...@starin.biz wrote:
I wanted some thought from you guys about the idea of giving PHP scripts
the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
Class
On Mon, 7 Jan 2013, nat...@starin.biz wrote:
I wanted some thought from you guys about the idea of giving PHP scripts the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
Class
Hi!
Out of the urgent need to access files with a path longer than MAX_PATH on
Windows, I started some research.
At first I thought it might be a good idea to write my own stream wrapper
extension (e.g. file_long://.) .
Before I started, I tried to find out, why those paths don't work in the
From: Derick Rethans [mailto:der...@php.net]
Sent: Monday, January 07, 2013 11:22 AM
To: nat...@starin.biz
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] new Class ReflectionZVal
On Mon, 7 Jan 2013, nat...@starin.biz wrote:
function __construct($variable);
That's inherently flawed, as
On 07.01.2013 18:30, Nicolai Scheer wrote:
Any comment is much appreciated, if I can help implementing this feature,
let me know.
I can't really comment on the feasibility, but from having seen many
people stumble upon problems with too long paths over the years (recent
framework development
On Mon, 7 Jan 2013, nat...@starin.biz wrote:
From: Derick Rethans [mailto:der...@php.net]
Sent: Monday, January 07, 2013 11:22 AM
On Mon, 7 Jan 2013, nat...@starin.biz wrote:
function __construct($variable);
That's inherently flawed, as passing a variable in can modify it's
hi,
On Mon, Jan 7, 2013 at 6:30 PM, Nicolai Scheer sc...@planetavent.de wrote:
Out of the urgent need to access files with a path longer than MAX_PATH on
Windows, I started some research.
At first I thought it might be a good idea to write my own stream wrapper
extension (e.g.
On 07.01.13 20:14, Pierre Joye wrote:
functions. Next major version (6) will support unicode filenames,
which will solve the 255 chars horrible limitation.
I thought the Unicode effort was abandoned long time ago. You sound like
someone is still actively working on it?
- Martin
--
PHP
On Mon, Jan 7, 2013 at 8:22 PM, Martin Jansen mar...@divbyzero.net wrote:
On 07.01.13 20:14, Pierre Joye wrote:
functions. Next major version (6) will support unicode filenames,
which will solve the 255 chars horrible limitation.
I thought the Unicode effort was abandoned long time ago. You
It would be indeed nice if the \\?\ prefix was not needed in userspace
and php would do the work. But just for now I really would like to see
php
support for long paths on windows at all. To my mind the changes needed
for
the prefix workaround are function is minimal-invasive. Correct
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
Whatever you decide on in terms of syntax, most likely won't satisfy every
the needs of every userland annotation library, so
Cof... cof...
https://wiki.php.net/rfc/annotations
Good luck convincing php-src folks.
You'd be my hero.
On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz ras...@mindplay.dk wrote:
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established
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
trick to bypass open_basedir, etc.)?
All of them, as the paths are
Hi. I like the proposal of this RFC very much ;-)
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
25 matches
Mail list logo
