Re: [PHP-DEV] [VOTE] Error message formatting for development

2011-08-10 Thread Derick Rethans
On Wed, 3 Aug 2011, Derick Rethans wrote:

 The RFC and patch can be found here:
 https://wiki.php.net/rfc/error-formatting-for-developers
 
 You can vote here:
 https://wiki.php.net/rfc/error-formatting-for-developers#vote

Voting is now closed and the RFC was accepted 16 for and 0 against. The 
patch has been committed.

cheers,
Derick
-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Property get/set syntax

2011-08-10 Thread Sebastian Krebs

Hi,

From time to time I'm looking over the existing RFCs and I'm wondering 
what happens to them. For example Property get/set syntax [1]. As far 
as I can see its already accepted for PHP6 [2], but now it seems to be 
orphaned. In my opinion it is a very nice enhancement, that helps to get 
rid of the Getter/Setter-mess. Are there any plans?


Bye,
Sebastian



[1] https://wiki.php.net/rfc/propertygetsetsyntax
[2] https://wiki.php.net/todo/php60

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Property get/set syntax

2011-08-10 Thread Paul Dragoonis
On Wed, Aug 10, 2011 at 8:05 PM, Sebastian Krebs 
sebastian.krebs.ber...@googlemail.com wrote:

 Hi,

 From time to time I'm looking over the existing RFCs and I'm wondering what
 happens to them. For example Property get/set syntax [1]. As far as I can
 see its already accepted for PHP6 [2], but now it seems to be orphaned. In
 my opinion it is a very nice enhancement, that helps to get rid of the
 Getter/Setter-mess. Are there any plans?

 @internals -  Is this something that could be proposed for 5.4.0? or is it
too late.


 Bye,
 Sebastian



 [1] 
 https://wiki.php.net/rfc/**propertygetsetsyntaxhttps://wiki.php.net/rfc/propertygetsetsyntax
 [2] https://wiki.php.net/todo/**php60 https://wiki.php.net/todo/php60

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Static method call syntax on objects

2011-08-10 Thread Sebastian Bergmann

 Is this exepcted behaviour?

   ➜  ~  cat test.php
   ?php
   class Foo {
   public static function bar() {
   print __METHOD__ . \n;
   }
   }

   $foo = new Foo;
   $foo::bar();


   ➜  ~  php test.php
   Foo::bar

 I, for one, was surprised that this does what it does with PHP 5.3 and
 PHP 5.4 (do not have older version of PHP hand).

--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Property get/set syntax

2011-08-10 Thread Kalle Sommer Nielsen
Hi Sebastian

2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com:
 Hi,

 From time to time I'm looking over the existing RFCs and I'm wondering what
 happens to them. For example Property get/set syntax [1]. As far as I can
 see its already accepted for PHP6 [2], but now it seems to be orphaned. In
 my opinion it is a very nice enhancement, that helps to get rid of the
 Getter/Setter-mess. Are there any plans?

This RFC by Dennis was never 100% finalized, however from what I
remember it was suggested too late in 5.3's development process to be
implemented, and so do I think we are in 5.4 already as the RFC would
need some extra care before sent to the list, perhaps even a patch for
parts of it.

The RFC itself evolved quite a bit doing its drafts on the wiki, I
remember having long emails with Dennis about the syntax, as it
evolved to allow many more things and additions to the object model,
like final properties, interfaces with properties, getters, setters,
 But in the end I think it would rime greatly with traits and
other goodies in 5.4 if someone took the time and care for this RFC,
just worried its way too late already.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Static method call syntax on objects

2011-08-10 Thread Stas Malyshev

Hi!

On 8/10/11 1:12 PM, Sebastian Bergmann wrote:

   Is this exepcted behaviour?

 ➜  ~  cat test.php
 ?php
 class Foo {
 public static function bar() {
 print __METHOD__ . \n;
 }
 }

 $foo = new Foo;
 $foo::bar();


 ➜  ~  php test.php
 Foo::bar

   I, for one, was surprised that this does what it does with PHP 5.3 and
   PHP 5.4 (do not have older version of PHP hand).



This is how FETCH_CLASS works now - when it has an object in where it 
expects class name, it uses object's class. We could call toString() 
instead but that might be even more surprising.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Static method call syntax on objects

2011-08-10 Thread Etienne Kneuss
Hello,

On Wed, Aug 10, 2011 at 22:20, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 On 8/10/11 1:12 PM, Sebastian Bergmann wrote:

   Is this exepcted behaviour?

     ➜  ~  cat test.php
     ?php
     class Foo {
         public static function bar() {
             print __METHOD__ . \n;
         }
     }

     $foo = new Foo;
     $foo::bar();


     ➜  ~  php test.php
     Foo::bar

   I, for one, was surprised that this does what it does with PHP 5.3 and
   PHP 5.4 (do not have older version of PHP hand).


 This is how FETCH_CLASS works now - when it has an object in where it
 expects class name, it uses object's class. We could call toString() instead
 but that might be even more surprising.

Well, FETCH_CLASS has always worked like that, but previously (5.3)
variables for class references were only allowed as part of the new
statement,
e.g. new $obj; The semantic remains the same, only that now variables
are also allowed for :: calls (since 5.3).

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Etienne Kneuss
http://www.colder.ch

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [RFC] Line markers in PHP

2011-08-10 Thread Gwynne Raskind
I've just created a new RFC, https://wiki.php.net/rfc/linecontrol ,
regarding adding cpp(1)'s linemarkers to PHP. Discussion is invited.

-- Gwynne

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Property get/set syntax

2011-08-10 Thread André Rømcke
On Wed, Aug 10, 2011 at 10:16 PM, Kalle Sommer Nielsen ka...@php.netwrote:

 Hi Sebastian

 2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com:
  Hi,
 
  From time to time I'm looking over the existing RFCs and I'm wondering
 what
  happens to them. For example Property get/set syntax [1]. As far as I
 can
  see its already accepted for PHP6 [2], but now it seems to be orphaned.
 In
  my opinion it is a very nice enhancement, that helps to get rid of the
  Getter/Setter-mess. Are there any plans?

 This RFC by Dennis was never 100% finalized, however from what I
 remember it was suggested too late in 5.3's development process to be
 implemented, and so do I think we are in 5.4 already as the RFC would
 need some extra care before sent to the list, perhaps even a patch for
 parts of it.


Type hinting is for instance not covered (should imho at least be on pair
with function signatures).



 The RFC itself evolved quite a bit doing its drafts on the wiki, I
 remember having long emails with Dennis about the syntax, as it
 evolved to allow many more things and additions to the object model,
 like final properties, interfaces with properties, getters, setters,
  But in the end I think it would rime greatly with traits and
 other goodies in 5.4 if someone took the time and care for this RFC,
 just worried its way too late already.



On 6.0 todo list:
There are lots of things that would be nice additions to php on the 6.0 todo
list*.
If all these have been voted for in the past, I'll suggest that they could
be worked on in upcoming 5.x versions as well leading up to an eventual 6.0
version.

*eg:

   - Property overloading RFC aka abstract/virtual properties and get/set
   handlers (derick) (related?)
   - add support for type-hinted return values. *caugh*
   - add ability to allocate persistent zvals in PHP.
   - add support for files 2GB once native 64bit integers are implemented
   (pierre,wez)
   - APC
  - include APC in the core distributions (turned off by default) and
  switch to mmap as default shared memory storage.
  - ability to move autoloaded main classes in apc's class lookup
  preventing the overhead of doing the inheritance process all the time.
  (marcus)





 --
 regards,

 Kalle Sommer Nielsen
 ka...@php.net

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] [RFC] Line markers in PHP

2011-08-10 Thread Nikita Popov
In my eyes this change isn't necessary and if it is, not with this syntax.

First the syntax: PHP is not C, we do not have preprocessing
instructions using hash notation. Such a syntax seems unfamiliar in
PHP. Additionally # is already used for single line comments so
there's actually is no backwards compatability: Old code that
accidentally was of your proposed form would trigger a line marker,
potentially causing much confusion when debugging. If we really do
need such a feature it should follow PHP's declare syntax:

declare(line=17, file='hi');
// or
declare(line=5) {
   // ...
}

Now concerning your use cases: It is fairly easy to rewrite PHP
errors. One of the examples you give are Smarty templates. Twig
(another template engine), already does line number rewrites by
inserting `// line ...` comments into the template and extracting that
information using the tokenizer.
(https://github.com/fabpot/Twig/blob/master/lib/Twig/Error.php#L147)
It's not terribly complicated. And this is the most complex case,
where line number distribution is not just off-by-n, but really
requires line-hints in the source. For the PHPT tests a simple
addition of the number of lines before the actual test will suffice.
Even no tokenizer needed.

(Sorry, forgot to send to list)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php