Am 09.01.2013 13:03, schrieb Yahav Gindi Bar:
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps
wrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only before a class keyword
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only before a class keyword, before a property
or method declaration.
In none of those scopes would [ ] be a parsing issue I believe...
Th
Am 12.10.2012 23:06, schrieb Nikita Popov:
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
p
Hi
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There are
lan
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request $request, Closure $onFound);
}
An implementation of the interface could be as follo
Hi,
typehinting should definitely be available for this feature. But I have
another question. Why not go more consistent with the rest of the
language? I have mentioned this previously as the first proposal comes
up on the list. In my opinion the AS3 getter and setter
syntax(http://help.adobe
Hi,
comments inline.
Am 17.07.2012 18:57, schrieb Stas Malyshev:
There's no version 5.4.4-1. The patch was
85a62e9086db7a8ddfcda4ab1279a2439935f8d5 merged but since then there
were other changes to the code. Mike, could you please check if we
have
a regression there?
OK, someone in the bug
Hi,
please can someone look into this issue. It seems that in version
5.4.4-1 the bug was fixed, but in newer versions this issue still
exists. So please can someone merge the patch with the newer versions?
https://bugs.php.net/bug.php?id=55544
Cheers,
Christian
--
PHP Internals - PHP Runti
Am 18.04.2012 09:18, schrieb Ferenc Kovacs:
On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev
wrote:
Hi!
One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists,
especially
if you need to change only the last one - you hav
Am 09.03.2012 09:41, schrieb Arvids Godjuks:
Overall good job. I would prefer it a little stricter like people
already
mention, but it's a step forward definitively with witch I'm totally
fine
to live with.
Same from me. Good job.
--
PHP Internals - PHP Runtime Development Mailing List
To un
Am 09.03.2012 09:42, schrieb Gustavo Lopes:
That said, I think we could move to a mild BC breaking change for
php-next that would make zpp stricter (with or without user-land
scalar type hinting/coercion).
A big +1 from me for this change.
--
PHP Internals - PHP Runtime Development Mailing
Hi,
Am 07.03.2012 13:32, schrieb Antony Dovgal:
On 03/07/2012 03:47 PM, Christian Kaps wrote:
The Apache logs prints:
FastCGI: comm with server "/home/christian.kaps/fcgi.sock" aborted:
idle timeout (30 sec)
FastCGI: incomplete headers (0 bytes) received from server
"/home
Hi,
before I submit a Bug report I wanted to validate if it's a bug or not.
I try to increase the max_execution_time for a test script. What I have
done is to set php_admin_value[max_execution_time] = 100 in the config
for my pool. The phpinfo() output shows this value for
max_execution_time.
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in
PHP. As a userland developer it would help me to write clean and more
robust code. But I think this proposal is only a workaround to get a
round the main problem. It's a try to push similar functiona
Hi internals,
someone in the "Return Type Hinting for Methods RFC" thread had the idea
of a "numeric" type hint. I will capture this idea and propose a
"scalar" type hint. I understand the problem of the current discussion
about scalar type hints(int, float, string, double, ...). But there
sh
Hi,
I also find this syntax confusing and I think it has a huge WTF factor.
Some thoughts about the syntax:
- At the first glance, it isn't clear which visibility the getter or
setter has
- The extra indentation level makes the code more unreadable
class Foo {
/**
*
*/
priv
Hi,
why not creating a more function like syntax for this feature. In my
opinion it looks more cleaner particularly when using more than one line
in a setter or getter. The other thing is that you can use type hints
with this syntax.
As example:
class Foo {
private $bar;
public se
Am 25.11.2011 13:34, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 1:28 PM, Christian Kaps
wrote:
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
**wrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
wrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try
plication, that makes use of dynamic class
names
should make use of class_exists() in any case. An exception after
calling
class_exists() is just bad, but the classloader cannot distinguish
between
the reasons, why it is called.
2011/11/25 Christian Kaps
> Am 25.11.2011 08:24, schrieb M
gle autoloader.
On Fri, Nov 25, 2011 at 7:46 AM, Christian Kaps
wrote:
Am 25.11.2011 10:34, schrieb Rafael Kassner:
I think an autoloader can't be raise any kind of error. If the
class
will be loaded by another autoloader on the stack and the first
throws
an Exception, this will be a w
continues silent. And now the engine
tries to instantiate a not existing class, which ends in a fatal error.
On Fri, Nov 25, 2011 at 6:06 AM, Christian Kaps
wrote:
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
lass
names
should make use of class_exists() in any case. An exception after
calling
class_exists() is just bad, but the classloader cannot distinguish
between
the reasons, why it is called.
2011/11/25 Christian Kaps
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:
Am 25.11.2011 09:55, schrieb Sebastian Bergmann:
Am 25.11.2011 09:06, schrieb Christian Kaps:
Or am i wrong here?
Yes you are. The idea is that you can have multiple autoload
callbacks
which are invoked in sequence. The first one that is able to load
the
requested class will end that
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step
Hi internals,
I've written a RFC about the optimization of the autoloader error handling.
Please take a moment to review the RFC and post any questions, suggestions or
concerns here.
https://wiki.php.net/rfc/autoloader_error_handling
Cheers,
Christian
--
PHP Internals - PHP Runtime Developm
Am 11.11.2011 12:53, schrieb Anthony Ferrara:
Would it not be possible that the autoloader mechanism catch all
exceptions
made by any autoloader which fails to load a class. Only if none of
the
register autoloaders can load the requested class the autoloader
mechanism
throws an AutoloadExcepti
Hi
.. snip ..
Hm... so there should never have the normal available?
I need to think over this again then. While I tend to agree with
autoloader never triggering errors or exceptions, the debug mode is
the unique way to notice if user during developer haven't done any
mistake.
Maybe we can only
Hi,
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
1. The interface should be named SplClassLoader and the register and
unregister methods should be removed.
It should be possible to define class loader implementations without
registering them as
I know this topic has been discussed enough, but I think one argument
was not brought up yet. The proposed solution has a bad OO design
because it violates against the "Single responsibility principle".
Another issue is that the proposed class is only one possible solution
to load PSR-0 conform
>>
>>
>>
>>
> In addition, as I understand and would like to make you aware that
> static is not allowed in compile time class constants. Which is
> slightly unusual and perhaps could be changed because it seems that
> there is already runtime resolving taking place here.
>
It's available si
On Mon, 12 Sep 2011 14:43:33 +0100, Gustavo Lopes wrote:
Em Mon, 12 Sep 2011 12:53:13 +0100, Sebastian Bergmann
escreveu:
Regarding state it is important to notice that PHP does *not*
execute
the constructor on all low level calls when instantiating the
wrapper
class - for whatever reason
Hi Gustavo,
thanks for your detailed explanation.
Nevertheless it might be useful to document these inconsistent(from the
userland point of view) behavior. Please see my comments inline.
Am 28.08.2011 17:22, schrieb Gustavo Lopes:
> On Sun, 28 Aug 2011 14:29:28 +0100, Christian Kaps
>
Hi,
I have some problems with the stream API. The methods stream_tell and
stream_seek works not as expected in some cases.
Before reading the next lines, please look at the short
gist(https://gist.github.com/1176641).
First example:
$fp = fopen('mfx://test1', 'w');
fwrite($fp, '12345678');
fsee
est version of APC or using svn's trunk?
>
> If not please try it and report a bug at pecl.php.net/apc if it still occurs
>
> Thanks for your feedback!
>
> On Fri, Aug 19, 2011 at 2:54 PM, Christian Kaps
> wrote:
>> Hi!
>>
>> I have a problem with APC
Hi!
I have a problem with APC and a custom stream wrapper implementation.
The wrapper is used to include generated PHP classes. If APC is enabled
it seems that the include statement(used with different URL's), loads
always the first included class from cache.
The following code illustrates the is
On Wed, 8 Jun 2011 15:39:59 +0200, Jordi Boggiano wrote:
On Wed, Jun 8, 2011 at 2:46 PM, Felipe Pena
wrote:
class foo {
public function __construct() {
$this->bar = function () { return 1; };
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
$this->bar = array($
On Wed, 8 Jun 2011 09:46:26 -0300, Felipe Pena wrote:
It works in the same way:
class foo {
public function __construct() {
$this->bar = function () { return 1; };
// $this->bar(); // error
$x = $this->bar;
$x(); // ok
$this->bar = array($this, 'baz');
//
On Wed, 8 Jun 2011 08:57:48 -0300, Felipe Pena wrote:
Hi,
2011/6/8 Christian Kaps
Hi,
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this->bar = array($this, 'baz');
$this->bar();
}
public function bar()
Hi,
Hi all,
Reading our bug tracker I noticed a good feature request [1] from
2009 which
points to an interesting feature that I think makes sense for us,
since we
are now working with $f() using objects and strings, and the
array('class',
'method') is an old known for call_user_func()-like
> Am 02.06.2011 13:15, schrieb Peter Lind:
>
> Anyway, I'll stop it here, as I doubt I'll convince you of anything
> (and vice versa).
>
> Just one thing to add: thanks for the work on PHP :) Much appreciated.
>
I think/hope that this RFC is a step in the right direction to make the
release pro
Hi,
are they any plans to add full namespace support for the Reflection API
in PHP 5.4. Until now there is only rudimentary
support implemented.
There would be a great benefit for userland annotation parsers, because
it could access the use statements to get the FQN
for an annotation. I think
Am 17.05.2011 um 02:22 schrieb Benjamin Dubois :
> Hi,
>
> Why not make all objects (maybe implicitly) extend a single root object,
> containing just skeleton ctor/dtor and implemented in the engine ?
>
> I don't know if it is actually possible in PHP, but that works for several
> other l
Am 11.05.2011 13:31, schrieb Richard Quadling:
> On 11 May 2011 07:50, dukeofgaming wrote:
>> It is really troubling to read that statement. Seems there are still some
>> that don't really have a clue of what annotations are, even when the RFC
>> clearly links to them. Annotations ARE NOT document
On Tue, 10 May 2011 15:20:14 +0100, Alain Williams wrote:
On Tue, May 10, 2011 at 03:55:26PM +0200, christian.k...@mohiva.com
wrote:
I'm a userland developer, reading the list since two years I think.
And
I must say I'm totally frustrated about the developing process
itself.
The actual prop
On Tue, 10 May 2011 15:13:32 +0200, Ferenc Kovacs wrote:
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and
on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectat
Hi,
is there any reason why a temporary file created with SplTempFileObject
isn't accessible by another e.g. SplFileObject instance.
$temp = new SplTempFileObject();
$temp->fwrite('A string');
var_dump($temp->getPathname());
The var_dump call returns always the PHP stream URL php://temp. Why the
Hi,
last week I wrote a bug report:
http://bugs.php.net/bug.php?id=54570
Maybe someone can look into it, because no modifications were made since
reporting. I am interested if it's a bug or If I should work around.
Greetings
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> >
> > No, as usual on Gentoo, config files are never overwritten, but
> > written to another place and tools like etc-update show you the
> > differences. I've merged the configs manually, and I'm pretty
> > sure I didn't add anything like error_repor
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> * Rasmus Lerdorf wrote:
>
>> Also, you said this happened between 5.3.2 and 5.3.3? Looking through
>> the diff between those two versions we did not add any new deprecation
>> warnings. We tend to not do that in a minor release. At least I don't
>>
Hi,
I like the idea of the property get/set syntax, but in my opinion it
doesn't figure with PHP's syntax, because it breaks the readability. The
problem for me is the nesting of the inner set and get. How do you
document these syntax.
/**
*
*/
public $name {
/**
*
*/
ge
On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling
wrote:
> Hello all.
>
> In trying to follow the annotations threads currently running, I've
> come to realise just how little I understand a LOT of what I read
> here.
>
> But, then again, I don't need to, so hurrah for me. I try to follow,
>
Am 16.09.2010 22:56, schrieb Chad Fulton:
> Hello,
>
> Based on comments from the annotations thread, I have created a
> docBlock parser RFC at http://wiki.php.net/rfc/docblockparser
>
> This RFC does not deal with annotations per se, but only with the idea
> of adding a function to the Reflection
Am 16.09.2010 18:02, schrieb Matthew Weier O'Phinney:
>
>> in my mind there is a big mistake when using annotations in PHPDoc comments.
> What is the mistake? You don't explain that anywhere in your reply -- you
> simply
> give code examples of how you feel they should work.
>
For me the mistake
>
> So the question to be answered is: Should PHP support Annotations?
>
> I'm +1.
>
+1
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 16 Sep 2010 10:10:21 +0200, Frederic Hardy
wrote:
> Hello !
>> This thought is brought on mainly by watching the annotations drama that is
>> currently occupying internals, does anyone else agree it might be a good
>> idea to have a slightly more formal procedure for requesting features
Hi,
it's reserved for the error control
operator(http://www.php.net/manual/en/language.operators.errorcontrol.php).
Greetings,
Christian
On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov
wrote:
> Hello all,
> Only today see that here is very intersting discussion.
> I have a question: why was
On Wed, 15 Sep 2010 10:46:45 +0200, Pierre Joye
wrote:
> The only difference in PHP is the complete lack of clear road map and
> the chaotic way of deciding things.
Yes, I personally see here a huge problem too.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
On Wed, 15 Sep 2010 10:12:43 +0200, Zeev Suraski wrote:
> At 09:37 15/09/2010, Christian Kaps wrote:
>>On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
>> wrote:
>>
>> > Whatever syntax it is, it is definitely new.
>>
>>Yes, but this should not be an a
On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
wrote:
> Whatever syntax it is, it is definitely new.
Yes, but this should not be an argument against it. So every new
feature can have new syntax or should PHP freeze on the current state!?
I can't honestly understand why developer shouldn't un
On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
wrote:
> Hi!
>
>> class User {
>>
>> [NotNull]
>> [Integer]
>> public $id;
>>
>> [NotNull]
>> [Regexp('/[a-z]*/i')]
>> [MinLength(2)]
>> [MaxLength(255)]
>> public $name;
>>
>> [NotNull]
>> [Zipcod
Am 14.09.2010 22:12, schrieb Stas Malyshev:
> I think we _already_ have metadata in PHP, albeit done through
> phpdocs. So the question is kind of moot :) We should see if it's
> enough for us or we want to add/change/extend it and if so, how.
>
Hi,
in my mind there is a big mistake when using a
Hi Benjamin,
I agree with you 100 percent.
Greetings,
Christian
On Mon, 13 Sep 2010 17:38:37 +0200, Benjamin Eberlei
wrote:
> I strongly disagree!
>
> PHPDocs are for what their name suggests, for comments, not for runtime
> code information. They allow arbitrary characters, their intent is fo
On Sun, 12 Sep 2010 11:55:16 -0700, Stas Malyshev
wrote:
> Hi!
>
>> 1. In Java annotations are a special type of an interface. But due the
>> lack of type hinting for scalar values we cannot use this construct,
>> because we cannot put some validation logic in an interface. My proposal
>
> I'm n
Hi Stas,
this type of annotations cannot be used as PHPDoc annotations due its
different syntax. In other languages like Java, C# or AS3 annotations
are an independent language construct and I think in PHP it should be
the same. I dont know how many non-performant user-land
implementations(hacks)
Hi,
>> %Annotation(%Email(checkMX = true));
at first I thought what for an ugly syntax. But after a time I think it
is regardless of whether the % or @(from Java, which I prefer over all,
if it were possible) syntax is used. It looks very similar. So I prefer
the % syntax so we can use the [] fo
On Thu, 26 Aug 2010 13:56:09 +0200 (CEST), Etienne Kneuss
wrote:
>
> I don't understand why aliasing of class names suddenly becomes an
issue,
> we now have namespaces which allow aliases.
>
> use NS\To\MyAnnotation as MyAnnot;
>
> [MyAnnot]
> class Foo {
>
> }
>
> there is no need to have th
On Thu, 26 Aug 2010 11:17:33 +0200, Benjamin Eberlei
wrote:
> Hey,
>
> 3.
> Ok that point may be relevant, but there is also a semantically nice and
> simple solution:
>
> array('JoinTable' => array(
> 'name' => 'users_phonenumbers',
> 'joinColumns' => array(
> 0 => array('JoinCo
Hi,
I love this RFC. But I have a view questions.
1.
> Since php does not support named parameter the __construct is called
> with an array as parameter
> [Foo("bar", baz="baz)]
> will call __construct(array("value" => "bar", "baz" => "baz));
>
I am a absolute C noob but I have implemented name
Am 10.08.2010 22:07, schrieb Brian Moon:
> On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
>> like DIRECTORY_SEPARATOR I guess
>>
>> Tyrael
>
> but, DIRECTORY_SEPARATOR is system dependent. The namespace separator
> is not. It is is always \.
>
OK. This is clear.
--
PHP Internals - PHP Runtime Develop
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
constant would be a better way to handle such cases.
Greetings,
Christian
I would like to see this in the next major/minor release, together with
the traits and the type-hint implementation. This would be a great language
improvement.
>From my end-developer standpoint a big +++
On Wed, 28 Jul 2010 22:49:03 -0300, Felipe Pena
wrote:
> Hi all,
> I've updated the patch
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith
wrote:
> On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
>
>>
>>
>> On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
>>
>>> Hi!
>>>
I know the discussion is about scalar type hints. But what is with a
object type hint as base
Am 17.06.2010 21:14, schrieb Stas Malyshev:
> Hi!
>
>> I know the discussion is about scalar type hints. But what is with a
>> object type hint as base for all objects?
>
> When it makes sense to accept any object, regardless of the class, but
> not other types? I wonder if it's really a common use
Hi,
I know the discussion is about scalar type hints. But what is with a
object type hint as base for all objects?
What is the next step to get type hinting in the next PHP release,
regardless of whether strict or weak?
Best regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing
> - trigger_error OR exceptions? (we said, that exceptions shouldn't be
> allowed inside the core, so maybe this can be only impelemted through
spl)
I think the exception discussion should be omitted. There exists some
other RFCs to fix this issue.
http://wiki.php.net/rfc/enhanced_error_handling
h
That sounds good and I hope it will be included in the next release.
Best regards,
Christian
> Hi:
>
> On 04 Jun 2010, at 13:46, Christian Kaps wrote:
>
>
>> A short while ago there was a discussion about implementing Traits in
>> the next PHP version
A short while ago there was a discussion about implementing Traits in
the next PHP version. How is the status of this?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
78 matches
Mail list logo
