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
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_basedir, etc.)?
All of them, as the paths are passed right to
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 wrote:
> On parsing annotations in docblocks: please don't.
>
> First of all, there are already plenty of established userland
> implementati
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 at
>
> > 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-invasiv
On Mon, Jan 7, 2013 at 8:22 PM, Martin Jansen 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 sound like
> so
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 Inter
hi,
On Mon, Jan 7, 2013 at 6:30 PM, Nicolai Scheer 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. file_long://.) .
>
> Before
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 modi
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
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
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
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:
>
>
>
> C
On Mon, Jan 7, 2013 at 6:10 PM, 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 Reflec
Nathan,
On Mon, Jan 7, 2013 at 12:10 PM, 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:
>
>
>
> Cl
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 refe
On Mon, Jan 7, 2013 at 4:50 PM, Lester Caine wrote:
> Pierre Joye wrote:
>>
>> On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine wrote:
>>>
>>> Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I woul
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine 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 als
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 wrote:
> Hi!
>
> I've added the
This is what I was going for. Your idea looks better.
On Mon, Jan 7, 2013 at 4:45 PM, Anthony Ferrara wrote:
> Yahav and all,
>
>
> On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar wrote:
>
>> Hi internals!
>>
>> In one of the discussions (about the "deprecated" keyword, to be specific),
>> it wa
Yahav and all,
On Sun, Jan 6, 2013 at 4: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 grea
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 i
hi,
On Thu, Jan 3, 2013 at 4:59 PM, Steve Hanselman 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 | http://blog.thepim
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine 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 a
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
some
25 matches
Mail list logo
