date:20120424

Hi all,

I'm actually putting my head into ext/mysqlnd and I noticed weird
things about its API.

As you should know, ext/mysqlnd is a replacement for libmysql, that
is, all our 3 MySQL-related extensions may use it, and it is done by
default for 5.4 branch.
However, I've been surprised that ext/mysqlnd expose its API through
ext/mysqli only...

- mysqli_get_client_stats()
- mysqli_get_connection_stats()
- mysqli_get_cache_stats()

Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
the source code of ext/mysqli and not defined if ext/mysqli has been
compiled against libmysql.
There is a mismatch in the naming and the place here, those 3
functions should be part of ext/mysqlnd API, and be named
mysqlnd_().

What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?

I then suggest to expose ext/mysqlnd API through itself
(http://lxr.php.net/xref/PHP_5_3/ext/mysqlnd/php_mysqlnd.c#33) in
php_mysqlnd.c or create a new php_mysqlnd_fe.c
For the actual functions, please refer to
http://lxr.php.net/xref/PHP_5_3/ext/mysqli/mysqli_nonapi.c#392

Second, I would suggest to add a function that would reset the global
stat counter. The only way to do it actually is by passing in MINIT(),
so by restarting PHP ; it may be useful, and not very hard to develop,
to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.

Any ideas, comments ?

Cheers,

Julien

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

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

2012-04-24 Thread Johannes Schlüter

On Tue, 2012-04-24 at 13:35 +0200, jpauli wrote:
 - mysqli_get_client_stats()
 - mysqli_get_connection_stats()
 - mysqli_get_cache_stats()
 
 Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
 the source code of ext/mysqli and not defined if ext/mysqli has been
 compiled against libmysql.

With libmysql we don't have the statistics, therefore they are useless.

 There is a mismatch in the naming and the place here, those 3
 functions should be part of ext/mysqlnd API, and be named
 mysqlnd_().

Until 5.4 we couldn't do mysqlnd_get_connection_stats as there was no
way to get from an arbitrary zval (PDO or mysqli object, mysql resource)
to the corresponding MYSQLND*.

The other reason is that one idea for mysqlnd was that it doesn't expose
anything to the userland while ext/mysql is legacy and get's no
additions and PDO would allow user-defined functions,while that's not
really nice.

 What if I choose to only compile pdo_mysql (against mysqlnd) and not
 mysqli ?? I then would be able to use mysqlnd, but I would have access
 to its statistics, as its functions are part of ext/mysqli... Strange
 as well as embarrassing isn't it ?

You simply shouldn't do that ;-)

 Second, I would suggest to add a function that would reset the global
 stat counter. The only way to do it actually is by passing in MINIT(),
 so by restarting PHP ; it may be useful, and not very hard to develop,
 to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.
 
 Any ideas, comments ?

Feel free to open a ticket in the bug tracker and assign it to us (mysql
user).

johannes
-- 
Johannes Schlüter, MySQL Engineering Connectors and Client Connectivity
ORACLE Deutschland B.V.  Co. KG, Riesstr. 25, D-80992 München


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

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

2012/4/24 Johannes Schlüter johannes.schlue...@oracle.com:
 On Tue, 2012-04-24 at 13:35 +0200, jpauli wrote:
 - mysqli_get_client_stats()
 - mysqli_get_connection_stats()
 - mysqli_get_cache_stats()

 Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
 the source code of ext/mysqli and not defined if ext/mysqli has been
 compiled against libmysql.

 With libmysql we don't have the statistics, therefore they are useless.

Right, NP


 There is a mismatch in the naming and the place here, those 3
 functions should be part of ext/mysqlnd API, and be named
 mysqlnd_().

 Until 5.4 we couldn't do mysqlnd_get_connection_stats as there was no
 way to get from an arbitrary zval (PDO or mysqli object, mysql resource)
 to the corresponding MYSQLND*.

Aha, I like when an internals guy teach me internals stuff :)
So, OK for 5.3 , what about supporting that for =5.4 ?


 The other reason is that one idea for mysqlnd was that it doesn't expose
 anything to the userland while ext/mysql is legacy and get's no
 additions and PDO would allow user-defined functions,while that's not
 really nice.

That was my first question : Is it better to provide mysqlnd API
through all 3 MySQL extensions, or through a common mysqlnd_***() API
?
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.


 What if I choose to only compile pdo_mysql (against mysqlnd) and not
 mysqli ?? I then would be able to use mysqlnd, but I would have access
 to its statistics, as its functions are part of ext/mysqli... Strange
 as well as embarrassing isn't it ?

 You simply shouldn't do that ;-)

;-) OK, but that can be done easily. More and more people use
pdo_mysql and could be able to not compile other MySQL extensions (I
got some machines where only pdo_mysql is compiled in)


 Second, I would suggest to add a function that would reset the global
 stat counter. The only way to do it actually is by passing in MINIT(),
 so by restarting PHP ; it may be useful, and not very hard to develop,
 to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.

 Any ideas, comments ?

 Feel free to open a ticket in the bug tracker and assign it to us (mysql
 user).

More, I'm gonna work on a patch to feed the bug report with ;-)
Stats are not the hardest part of ext/mysqlnd :)

Julien.P

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

[PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Clint M Priest

I've updated the RFC to include details on adding isset/unset as well as 
references, detailed below:

isset/unset:

class TimePeriod {
private $Seconds = 3600;

public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
isset { return !is_null($this-Seconds); }
unset { $this-Seconds = NULL; }
}
}

References:


class SampleClass {

private $_dataArray = array(1,2,5,3);



public $dataArray {

get { return $this-_dataArray; }

}

}



$o = new SampleClass();

sort($o-dataArray);

/* $o-dataArray == array(1,2,3,5); */

Comments?

These would also include automatic implementations which call the respective 
functions on the backing field.  I could see only allowing isset/unset 
automatic implementations if get/set were also specified as automatic 
implementations.

Default implementations of isset/unset

I'm also fielding comments/ideas on a way to always provide automatic 
implementations of isset/unset for any accessor that didn't define one 
automatically.  One idea was for the isset (unspecified implementation) which 
would return true if the getter provided any value which evaluated to true, 
such as this:

class TimePeriod {
private $Seconds = 3600;

public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
}
}
/* Default Implementation Concept */

isset { return (int)$this-Hours; }
unset { $this-Hours = NULL; }

Note that the automatic implementation of unset is not strictly the same as an 
unset() but without any sort of unset implementation a call to unset() would do 
nothing.  Alternatively we could throw an error to a call on isset and/or unset 
against a property which didn't define an implementation.

Thoughts?

-Clint

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

2012-04-24 Thread Ulf Wendel


Am 24.04.2012 14:27, schrieb jpauli:

I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.


A fourth MySQL API is not my goal. There's enough confusion with three 
of them already.


Ulf

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

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

2012-04-24 Thread Johannes Schlüter

On Tue, 2012-04-24 at 14:27 +0200, jpauli wrote:
 Aha, I like when an internals guy teach me internals stuff :)
 So, OK for 5.3 , what about supporting that for =5.4 ?

Maybe. ;-)

 
  The other reason is that one idea for mysqlnd was that it doesn't expose
  anything to the userland while ext/mysql is legacy and get's no
  additions and PDO would allow user-defined functions,while that's not
  really nice.
 
 That was my first question : Is it better to provide mysqlnd API
 through all 3 MySQL extensions, or through a common mysqlnd_***() API
 ?
 I understand your thoughts, but I disagree as I think it would be much
 more clean to expose it via mysqlnd_***() API than through each MySQL
 ext (and for PDO that would be even more dirty). That would as well
 add more and more #ifdef MYSQLND inside their source...
 I was thinking the same way libxml2 API is provided inside ext/libxml
 instead of through each PHP XML extension API.

Well, as said, we couldn't before 5.4. I gave the historical reason
for the current state.

  What if I choose to only compile pdo_mysql (against mysqlnd) and not
  mysqli ?? I then would be able to use mysqlnd, but I would have access
  to its statistics, as its functions are part of ext/mysqli... Strange
  as well as embarrassing isn't it ?
 
  You simply shouldn't do that ;-)
 
 ;-) OK, but that can be done easily. More and more people use
 pdo_mysql and could be able to not compile other MySQL extensions (I
 got some machines where only pdo_mysql is compiled in)

All distros I recently checked put all three mysql extensions in the
same package. People who build PHP themselves should be able to fix this
easily. So this does not seem to be an issue. (while that's irrelevant
for the mysqli vs. myslqnd question)

johannes



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

Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Anthony Ferrara

Clint,

Very nice job overall!  Looking quite good.

  Alternatively we could throw an error to a call on isset and/or unset 
 against a property which didn't define an implementation.

I don't care for that concept much.  All it's doing is trading one set
of boilerplate for another.  I'd prefer the get() !== null approach,
since there is a zval allocated for it, so the isset() part.

And I do like the unset overloading, which is right inline with __unset()...

Additionally, is something like this possible?

class Foo {
private $bar = 1;
public $bar {
get { return $this-bar; }
set { $this-bar = (int) $value; }
}
}

The reason that I ask, is that's kind of what's done with __get() and
__set() right now, the magic is called when it's out of scope.  So in
this case, we can have a public variable with the same name as the
private one, but with validations attached to the public exposure...

Just a thought...

Anthony

On Tue, Apr 24, 2012 at 8:31 AM, Clint M Priest cpri...@zerocue.com wrote:
 I've updated the RFC to include details on adding isset/unset as well as 
 references, detailed below:

 isset/unset:

 class TimePeriod {
    private $Seconds = 3600;

    public $Hours {
        get { return $this-Seconds / 3600; }
        set { $this-Seconds = $value; }
        isset { return !is_null($this-Seconds); }
        unset { $this-Seconds = NULL; }
    }
 }

 References:


 class SampleClass {

    private $_dataArray = array(1,2,5,3);



    public $dataArray {

        get { return $this-_dataArray; }

    }

 }



 $o = new SampleClass();

 sort($o-dataArray);

 /* $o-dataArray == array(1,2,3,5); */

 Comments?

 These would also include automatic implementations which call the respective 
 functions on the backing field.  I could see only allowing isset/unset 
 automatic implementations if get/set were also specified as automatic 
 implementations.

 Default implementations of isset/unset

 I'm also fielding comments/ideas on a way to always provide automatic 
 implementations of isset/unset for any accessor that didn't define one 
 automatically.  One idea was for the isset (unspecified implementation) which 
 would return true if the getter provided any value which evaluated to true, 
 such as this:

 class TimePeriod {
    private $Seconds = 3600;

    public $Hours {
        get { return $this-Seconds / 3600; }
        set { $this-Seconds = $value; }
    }
 }
 /* Default Implementation Concept */

        isset { return (int)$this-Hours; }
        unset { $this-Hours = NULL; }

 Note that the automatic implementation of unset is not strictly the same as 
 an unset() but without any sort of unset implementation a call to unset() 
 would do nothing.  Alternatively we could throw an error to a call on isset 
 and/or unset against a property which didn't define an implementation.

 Thoughts?

 -Clint

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

Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Benjamin Eberlei

Hi!

would it be possible to add a second shorthand syntax to the complete
automatic implementation?

Examples:

class TimePeriod
{
public $Hours {};
public property $Hours;
public $Hours {property};
}

That could save quite some typing.

Overall, i really like it.

On Tue, Apr 24, 2012 at 2:56 PM, Anthony Ferrara ircmax...@gmail.comwrote:

 Clint,

 Very nice job overall!  Looking quite good.

   Alternatively we could throw an error to a call on isset and/or unset
 against a property which didn't define an implementation.

 I don't care for that concept much.  All it's doing is trading one set
 of boilerplate for another.  I'd prefer the get() !== null approach,
 since there is a zval allocated for it, so the isset() part.

 And I do like the unset overloading, which is right inline with
 __unset()...

 Additionally, is something like this possible?

 class Foo {
private $bar = 1;
public $bar {
get { return $this-bar; }
set { $this-bar = (int) $value; }
}
 }

 The reason that I ask, is that's kind of what's done with __get() and
 __set() right now, the magic is called when it's out of scope.  So in
 this case, we can have a public variable with the same name as the
 private one, but with validations attached to the public exposure...

 Just a thought...

 Anthony

 On Tue, Apr 24, 2012 at 8:31 AM, Clint M Priest cpri...@zerocue.com
 wrote:
  I've updated the RFC to include details on adding isset/unset as well as
 references, detailed below:
 
  isset/unset:
 
  class TimePeriod {
 private $Seconds = 3600;
 
 public $Hours {
 get { return $this-Seconds / 3600; }
 set { $this-Seconds = $value; }
 isset { return !is_null($this-Seconds); }
 unset { $this-Seconds = NULL; }
 }
  }
 
  References:
 
 
  class SampleClass {
 
 private $_dataArray = array(1,2,5,3);
 
 
 
 public $dataArray {
 
 get { return $this-_dataArray; }
 
 }
 
  }
 
 
 
  $o = new SampleClass();
 
  sort($o-dataArray);
 
  /* $o-dataArray == array(1,2,3,5); */
 
  Comments?
 
  These would also include automatic implementations which call the
 respective functions on the backing field.  I could see only allowing
 isset/unset automatic implementations if get/set were also specified as
 automatic implementations.
 
  Default implementations of isset/unset
 
  I'm also fielding comments/ideas on a way to always provide automatic
 implementations of isset/unset for any accessor that didn't define one
 automatically.  One idea was for the isset (unspecified implementation)
 which would return true if the getter provided any value which evaluated to
 true, such as this:
 
  class TimePeriod {
 private $Seconds = 3600;
 
 public $Hours {
 get { return $this-Seconds / 3600; }
 set { $this-Seconds = $value; }
 }
  }
  /* Default Implementation Concept */
 
 isset { return (int)$this-Hours; }
 unset { $this-Hours = NULL; }
 
  Note that the automatic implementation of unset is not strictly the same
 as an unset() but without any sort of unset implementation a call to
 unset() would do nothing.  Alternatively we could throw an error to a call
 on isset and/or unset against a property which didn't define an
 implementation.
 
  Thoughts?
 
  -Clint

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

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

On Tue, Apr 24, 2012 at 2:34 PM, Ulf Wendel ulf.wen...@oracle.com wrote:
 Am 24.04.2012 14:27, schrieb jpauli:

 I understand your thoughts, but I disagree as I think it would be much
 more clean to expose it via mysqlnd_***() API than through each MySQL
 ext (and for PDO that would be even more dirty). That would as well
 add more and more #ifdef MYSQLND inside their source...
 I was thinking the same way libxml2 API is provided inside ext/libxml
 instead of through each PHP XML extension API.


 A fourth MySQL API is not my goal. There's enough confusion with three of
 them already.

I agree with that, but I still think having mysqli_***() function that
is only related to mysqlnd stuff is a bad idea.


Julien

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

Re: [PHP-DEV] Expose mysqlnd API through all MySQL extensions

2012/4/24 Johannes Schlüter johannes.schlue...@oracle.com:
 On Tue, 2012-04-24 at 14:27 +0200, jpauli wrote:
 Aha, I like when an internals guy teach me internals stuff :)
 So, OK for 5.3 , what about supporting that for =5.4 ?

 Maybe. ;-)

I can start working on ideas/patches


 
  The other reason is that one idea for mysqlnd was that it doesn't expose
  anything to the userland while ext/mysql is legacy and get's no
  additions and PDO would allow user-defined functions,while that's not
  really nice.

 That was my first question : Is it better to provide mysqlnd API
 through all 3 MySQL extensions, or through a common mysqlnd_***() API
 ?
 I understand your thoughts, but I disagree as I think it would be much
 more clean to expose it via mysqlnd_***() API than through each MySQL
 ext (and for PDO that would be even more dirty). That would as well
 add more and more #ifdef MYSQLND inside their source...
 I was thinking the same way libxml2 API is provided inside ext/libxml
 instead of through each PHP XML extension API.

 Well, as said, we couldn't before 5.4. I gave the historical reason
 for the current state.

Got it, got it.


  What if I choose to only compile pdo_mysql (against mysqlnd) and not
  mysqli ?? I then would be able to use mysqlnd, but I would have access
  to its statistics, as its functions are part of ext/mysqli... Strange
  as well as embarrassing isn't it ?
 
  You simply shouldn't do that ;-)

 ;-) OK, but that can be done easily. More and more people use
 pdo_mysql and could be able to not compile other MySQL extensions (I
 got some machines where only pdo_mysql is compiled in)

 All distros I recently checked put all three mysql extensions in the
 same package. People who build PHP themselves should be able to fix this
 easily. So this does not seem to be an issue. (while that's irrelevant
 for the mysqli vs. myslqnd question)

Makes sense.


Julien

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

[PHP-DEV] display_errors=stderr is treated as display_errors=on

2012-04-24 Thread Franklin Tse

Hello,

I have PHP 5.4.0 running on IIS 7.5, of which the stderrMode setting has been 
ReturnStdErrIn500. A 500 response is expected when display_errors is set to 
stderr. However, a 200 response with error message is returned and instead of 
stderr, on is displayed in phpinfo.

A bug report was filed at https://bugs.php.net/bug.php?id=61556, but it was 
marked as not a bug.

Is that an expected behavior?

Thanks,
Franklin

[PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

2012-04-24 Thread Philip Olson

Hello everyone,

The following bug report brings up a good point:

  https://bugs.php.net/61784

The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now 
it returns boolean false. Instead it should return 0. Fixing this 
feels like a bug fix, which would go in 5.4.1. Thoughts?

Regards,
Philip



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

Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Anthony Ferrara

Clint,

Additionally, one more comment related to the read-only and
write-only.  I noticed that you're using E_ERROR for improper access.
Obviously you don't want this to be a warning, as the execution
shouldn't continue because that would be undefined.  However, what
about setting it to E_RECOVERABLE_ERROR, so that it can be captured
and recovered from...?  The engine wouldn't be in an unstable state,
so if we install an error_handler that throws an exception, there's no
reason to force-terminate the application...

I guess I'm just adverse to using E_ERROR except for cases where it's
literally not safe to continue (usually because the engine is put in
an inconsistent state)...

Anthony

On Tue, Apr 24, 2012 at 8:31 AM, Clint M Priest cpri...@zerocue.com wrote:
 I've updated the RFC to include details on adding isset/unset as well as 
 references, detailed below:

 isset/unset:

 class TimePeriod {
    private $Seconds = 3600;

    public $Hours {
        get { return $this-Seconds / 3600; }
        set { $this-Seconds = $value; }
        isset { return !is_null($this-Seconds); }
        unset { $this-Seconds = NULL; }
    }
 }

 References:


 class SampleClass {

    private $_dataArray = array(1,2,5,3);



    public $dataArray {

        get { return $this-_dataArray; }

    }

 }



 $o = new SampleClass();

 sort($o-dataArray);

 /* $o-dataArray == array(1,2,3,5); */

 Comments?

 These would also include automatic implementations which call the respective 
 functions on the backing field.  I could see only allowing isset/unset 
 automatic implementations if get/set were also specified as automatic 
 implementations.

 Default implementations of isset/unset

 I'm also fielding comments/ideas on a way to always provide automatic 
 implementations of isset/unset for any accessor that didn't define one 
 automatically.  One idea was for the isset (unspecified implementation) which 
 would return true if the getter provided any value which evaluated to true, 
 such as this:

 class TimePeriod {
    private $Seconds = 3600;

    public $Hours {
        get { return $this-Seconds / 3600; }
        set { $this-Seconds = $value; }
    }
 }
 /* Default Implementation Concept */

        isset { return (int)$this-Hours; }
        unset { $this-Hours = NULL; }

 Note that the automatic implementation of unset is not strictly the same as 
 an unset() but without any sort of unset implementation a call to unset() 
 would do nothing.  Alternatively we could throw an error to a call on isset 
 and/or unset against a property which didn't define an implementation.

 Thoughts?

 -Clint

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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

2012-04-24 Thread Paul Dragoonis

Happy to patch this once someone confirms this is a bug and not
changed behaviour in 5.4.

- Paul.

On Tue, Apr 24, 2012 at 4:29 PM, Philip Olson phi...@roshambo.org wrote:
 Hello everyone,

 The following bug report brings up a good point:

  https://bugs.php.net/61784

 The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now
 it returns boolean false. Instead it should return 0. Fixing this
 feels like a bug fix, which would go in 5.4.1. Thoughts?

 Regards,
 Philip



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


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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

Hi!

   https://bugs.php.net/61784
 
 The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now 
 it returns boolean false. Instead it should return 0. Fixing this 
 feels like a bug fix, which would go in 5.4.1. Thoughts?

I do not see a reason to hold 5.4.1 for this.


-- 
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] Expose mysqlnd API through all MySQL extensions

2012-04-24 Thread Andrey Hristov


 Hi,
On 04/24/2012 03:32 PM, jpauli wrote:

On Tue, Apr 24, 2012 at 2:34 PM, Ulf Wendelulf.wen...@oracle.com  wrote:

Am 24.04.2012 14:27, schrieb jpauli:


I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.



A fourth MySQL API is not my goal. There's enough confusion with three of
them already.


I agree with that, but I still think having mysqli_***() function that
is only related to mysqlnd stuff is a bad idea.



you probably hasn't seen mysqli_stmt_get_result() and result::fetch_all() :)



Julien



Andrey

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

Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

Hi!

 would it be possible to add a second shorthand syntax to the complete
 automatic implementation?
 
 Examples:
 
 class TimePeriod
 {
 public $Hours {};
 public property $Hours;
 public $Hours {property};
 }

How it is different from just public $Hours and why one would need this?

-- 
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] RFC: Property get/set syntax (added isset/unset and references)

Hi!

 public $dataArray {
 
 get { return $this-_dataArray; }

This is not correct. Please read:
http://php.net/manual/en/language.references.return.php


 These would also include automatic implementations which call the
 respective functions on the backing field.  I could see only allowing
 isset/unset automatic implementations if get/set were also specified
 as automatic implementations.

Could you please explain what is the use of automatic implementations?
I.e., why won't you just have a variable?
-- 
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] RFC: Property get/set syntax (added isset/unset and references)

Hi!

 These would also include automatic implementations which call the
 respective functions on the backing field.  I could see only allowing
 isset/unset automatic implementations if get/set were also specified
 as automatic implementations.

Another thing about that. The automatic implementation creates
variable starting with __. When exactly this happens - if all bodies are
not defined? Any of the bodies are not defined? What if I implement
interface like this:

interface iSampleInterface {
public $MyProperty {
get;
set;
}
}

Does this produce automatic __MyProperty or not?
-- 
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

[PHP-DEV] [RFC] Pure PHP Scripts (Updated)

Hi all,

I finally found some time today to update the RFC based on discussions
here.  Please have a look and let me know if I missed anything or if
there's anything else that needs clarifying:

https://wiki.php.net/rfc/phpp


I also want to know if this is sufficient to satisfy some of the concerns
that have been raised about being able to implement this into existing
frameworks that use a more tangled architecture.

Thanks!  =)

--Kris

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell

* The RFC starts off immediately talking about file extensions, but
the actual implementation proposed doesn't rely on file extensions or
suggest any enforcement of them. That disparity should be addressed
for clarity.

* The RFC quotes an entire discussion with a lot of harsh language
about coding practices that are currently considered standard in most
MVC frameworks, including the original message you were responding to
(which happened to be mine). I am not sure you intended to leave all
that in. In general that discussion contradicts the work you've done
elsewhere in the RFC to propose both .phpp and .phpf.

On Tue, Apr 24, 2012 at 3:52 PM, Kris Craig kris.cr...@gmail.com wrote:
 Hi all,

 I finally found some time today to update the RFC based on discussions
 here.  Please have a look and let me know if I missed anything or if
 there's anything else that needs clarifying:

 https://wiki.php.net/rfc/phpp


 I also want to know if this is sufficient to satisfy some of the concerns
 that have been raised about being able to implement this into existing
 frameworks that use a more tangled architecture.

 Thanks!  =)

 --Kris



-- 
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Arvids Godjuks

As far as I read there is no difference from the previous RFC - it
says essentially the same.

 The ?php tag, contained within one of these files, tells the webserver
to, in essence, “switch to PHP mode” and start parsing the data as PHP code.
When the ? tag is reached, the webserver “switches back” and resumes
parsing it as HTML. If no tags are given, the webserver will parse the file
data as HTML code until a ?php tag is reached. 

I'm I the only one who thinks that this is just plain wrong? I know for a
fact that there is no PHP mode on the WEB server level. I think I
understand what it tries to say, but I totally disagree with what is
written and don't want to guess anything.

24 апреля 2012 г. 22:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:

 Hi all,

 I finally found some time today to update the RFC based on discussions
 here.  Please have a look and let me know if I missed anything or if
 there's anything else that needs clarifying:

 https://wiki.php.net/rfc/phpp


 I also want to know if this is sufficient to satisfy some of the concerns
 that have been raised about being able to implement this into existing
 frameworks that use a more tangled architecture.

 Thanks!  =)

 --Kris

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell

That's a good point, it should say the PHP tokenizer, or something to
that effect (folks who spend more time with the internals could say
better what to call it).

The major difference from his previous version of the RFC is his
addition of the .phpf format, which would allow including a .php file
with ?php and ? in it from a .phpf file, but would not allow or need
any usage of ?php and ? within the .phpf file itself.

On Tue, Apr 24, 2012 at 4:14 PM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
As far as I read there is no difference from the previous RFC - it
says essentially the same.

The ?php tag, contained within one of these files, tells the webserver
to, in essence, switch to PHP mode and start parsing the data as PHP code.
When the ? tag is reached, the webserver switches back and resumes
parsing it as HTML. If no tags are given, the webserver will parse the file
data as HTML code until a ?php tag is reached.

I'm I the only one who thinks that this is just plain wrong? I know for a
fact that there is no PHP mode on the WEB server level. I think I
understand what it tries to say, but I totally disagree with what is
written and don't want to guess anything.

24 апреля 2012 г. 22:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:

Hi all,

I finally found some time today to update the RFC based on discussions
here. Please have a look and let me know if I missed anything or if
there's anything else that needs clarifying:

https://wiki.php.net/rfc/phpp

I also want to know if this is sufficient to satisfy some of the concerns
that have been raised about being able to implement this into existing
frameworks that use a more tangled architecture.

Thanks! =)

--Kris

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote:

 * The RFC starts off immediately talking about file extensions, but
 the actual implementation proposed doesn't rely on file extensions or
 suggest any enforcement of them. That disparity should be addressed
 for clarity.


Did you read the whole RFC?  Please refer to the Naming Conventions
section.  It addresses this explicitly.

Are you saying that section wasn't sufficiently clear or did you just miss
it?



 * The RFC quotes an entire discussion with a lot of harsh language
 about coding practices that are currently considered standard in most
 MVC frameworks, including the original message you were responding to
 (which happened to be mine). I am not sure you intended to leave all
 that in. In general that discussion contradicts the work you've done
 elsewhere in the RFC to propose both .phpp and .phpf.


Could you elaborate?  The only thing from the Internals discussion I
actually copy/pasted was the example I posted pertaining to the bitwise
constant; it was very technical in nature and didn't contain any harsh
language that I could see.  Or are you referring to something else?  If so,
please let me know what it is and I can fix it.



 On Tue, Apr 24, 2012 at 3:52 PM, Kris Craig kris.cr...@gmail.com wrote:
  Hi all,
 
  I finally found some time today to update the RFC based on discussions
  here.  Please have a look and let me know if I missed anything or if
  there's anything else that needs clarifying:
 
  https://wiki.php.net/rfc/phpp
 
 
  I also want to know if this is sufficient to satisfy some of the concerns
  that have been raised about being able to implement this into existing
  frameworks that use a more tangled architecture.
 
  Thanks!  =)
 
  --Kris



 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012/4/24 Tom Boutell t...@punkave.com

 That's a good point, it should say the PHP tokenizer, or something to
 that effect (folks who spend more time with the internals could say
 better what to call it).


Hmm yeah I guess that wording is a bit sloppy, isn't it?  I'm not sure what
the proper terminology would be there.  Any suggestions?



 The major difference from his previous version of the RFC is his
 addition of the .phpf format, which would allow including a .php file
 with ?php and ? in it from a .phpf file, but would not allow or need
 any usage of ?php and ? within the .phpf file itself.


Partially correct.  That is the only practical difference, but I also added
clarifying language based on concerns raised here.  For example, I added a
section clarifying that the references to a file extension are merely a
convention and do not represent a new parsing method based on filename.  I
also added clarifications on how script inclusion would work vs. direct
access via URL on a webserver.



 On Tue, Apr 24, 2012 at 4:14 PM, Arvids Godjuks
 arvids.godj...@gmail.com wrote:
  As far as I read there is no difference from the previous RFC - it
  says essentially the same.
 
   The ?php tag, contained within one of these files, tells the webserver
  to, in essence, switch to PHP mode and start parsing the data as PHP
 code.
  When the ? tag is reached, the webserver switches back and resumes
  parsing it as HTML. If no tags are given, the webserver will parse the
 file
  data as HTML code until a ?php tag is reached. 
 
  I'm I the only one who thinks that this is just plain wrong? I know for a
  fact that there is no PHP mode on the WEB server level. I think I
  understand what it tries to say, but I totally disagree with what is
  written and don't want to guess anything.
 
  24 апреля 2012 г. 22:52 пользователь Kris Craig kris.cr...@gmail.com
 написал:
 
  Hi all,
 
  I finally found some time today to update the RFC based on discussions
  here.  Please have a look and let me know if I missed anything or if
  there's anything else that needs clarifying:
 
  https://wiki.php.net/rfc/phpp
 
 
  I also want to know if this is sufficient to satisfy some of the
 concerns
  that have been raised about being able to implement this into existing
  frameworks that use a more tangled architecture.
 
  Thanks!  =)
 
  --Kris
 



 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

2012-04-24 Thread Ángel González

On 24/04/12 18:11, Paul Dragoonis wrote:
 Happy to patch this once someone confirms this is a bug and not
 changed behaviour in 5.4.

 - Paul.
Why would such behavior change be desired?
get_magic_quotes_gpc() is kept only for compatibility with scripts which
did magic quote detection.

As such, it should return its 'traditional' value.

get_magic_quotes_gpc() got wrongly deprecated in 5.4, then restored...
I think that when implementing it to always return that there are no
magic_quotes,
it was just inadvertedly changed to false. Which is the logical thing
as those 0/1 work as
booleans, but that should have been done long ago, when designing it,
not now.

Regards



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

RE: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Clint Priest

I will double-check (that it doesn't) but it should not per the spec, in the 
case of an interface this is not an automatic implementation but instead a 
'must-have' declaration, which could later become an automatic implementation 
when defined within a class which implements that interface.

-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com] 
Sent: Tuesday, April 24, 2012 12:34 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and 
references)

Hi!

 These would also include automatic implementations which call the 
 respective functions on the backing field.  I could see only allowing 
 isset/unset automatic implementations if get/set were also specified 
 as automatic implementations.

Another thing about that. The automatic implementation creates variable 
starting with __. When exactly this happens - if all bodies are not defined? 
Any of the bodies are not defined? What if I implement interface like this:

interface iSampleInterface {
public $MyProperty {
get;
set;
}
}

Does this produce automatic __MyProperty or not?
--
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] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Clint Priest

Here is a copy of what Dennis had written to me regarding automatic 
implementations from C# (the model):

 Originally, C# did not support automatically implemented properties. 
 There are several reasons why they were added.  The first reason, is that 
 while the syntax for properties is the same as the syntax for member 
 variables, there is still some subtle differences in behaviour that cannot be 
 accounted for by properties.  Here are some examples:

 - Variables may be used as input to out/ref arguments. Properties may not.
 - Properties may throw exceptions - variables will never do that.
 - Properties may have side effects or take a really long time to execute.
 Variables have no side effects and will always be as fast as can be expected 
 for the given type.
 - Properties support different accessibility - variables do not
 - When using reflection the properties and fields are treated as different 
 MemberTypes so are located differently (GetFields vs GetProperties for
example)

Some of these above example still apply (reflection, execution time), so the 
automatic implementations may simply be there as a way for authors to indicate 
their intention to make them execute code at a later time.

This suggestion below shortens the syntax even further.

-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com] 
Sent: Tuesday, April 24, 2012 12:11 PM
To: Benjamin Eberlei
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and 
references)

Hi!

 would it be possible to add a second shorthand syntax to the complete 
 automatic implementation?
 
 Examples:
 
 class TimePeriod
 {
 public $Hours {};
 public property $Hours;
 public $Hours {property};
 }

How it is different from just public $Hours and why one would need this?

--
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


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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

2012-04-24 Thread Philip Olson


On Apr 24, 2012, at 9:43 AM, Stas Malyshev wrote:

 Hi!
 
  https://bugs.php.net/61784
 
 The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now 
 it returns boolean false. Instead it should return 0. Fixing this 
 feels like a bug fix, which would go in 5.4.1. Thoughts?
 
 I do not see a reason to hold 5.4.1 for this.

The less people beginning to rely on this bug the better, and this is
a critical time. The impact of this BC break feels larger considering 
MQ is enabled by default in PHP 5.3 and below.

This change shouldn't damage the RC QA process as all this does (tm) 
is change the return of false to 0. And considering that the magic 
quotes feature is removed, this change should not affect other code.

Oh, sometimes it's nice that more people use == versus ===. ;)

Regards,
Philip

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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tjerk Meesters


On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

 On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote:
 
 * The RFC starts off immediately talking about file extensions, but
 the actual implementation proposed doesn't rely on file extensions or
 suggest any enforcement of them. That disparity should be addressed
 for clarity.
 
 
 Did you read the whole RFC?  Please refer to the Naming Conventions
 section.  It addresses this explicitly.
 
 Are you saying that section wasn't sufficiently clear or did you just miss
 it?
 

I think what he means is that the abstract section should be, well, abstract. 
Currently it appears more detailed than it should be by referring to file 
extensions on the let go. I would phrase that section in a way that doesn't 
rely on another section to explain the used terminology. 

Also, references such as .phpp are used throughout the document to indicate a 
particular type of source file rather than an actual file extension. As such I 
would recommend moving your terminology section to right underneath abstract. 
This would improve the readability. 


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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote:


 On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

  On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote:
 
  * The RFC starts off immediately talking about file extensions, but
  the actual implementation proposed doesn't rely on file extensions or
  suggest any enforcement of them. That disparity should be addressed
  for clarity.
 
 
  Did you read the whole RFC?  Please refer to the Naming Conventions
  section.  It addresses this explicitly.
 
  Are you saying that section wasn't sufficiently clear or did you just
 miss
  it?
 

 I think what he means is that the abstract section should be, well,
 abstract. Currently it appears more detailed than it should be by referring
 to file extensions on the let go. I would phrase that section in a way that
 doesn't rely on another section to explain the used terminology.

 Also, references such as .phpp are used throughout the document to
 indicate a particular type of source file rather than an actual file
 extension. As such I would recommend moving your terminology section to
 right underneath abstract. This would improve the readability.


Hmm I see your point.  Ok I'll update that langauge next time I can find a
spare moment.

So aside from that, what are your thoughts?  In addition to feedback on the
wording itself, I'd also be interested in hearing your thoughts on the
actual amended proposal itself.  Does the new script type alleviate your
main concerns about frameworks (keeping in mind that a compromise is a
solution that neither party likes but both parties can live with)?  What do
you think about the require/include syntax suggestions?  Should it be
comma-delinated or use as instead?  Etc.

Thanks!

--Kris

Re: [PHP-DEV] freeing zvals ref count

2012-04-24 Thread Etienne Kneuss

Hi,

On Wed, Apr 25, 2012 at 01:25, Yader Hernandez
yader.hernan...@gmail.com wrote:
 Hello,

 In the extension I'm currently working on, I call add_index_zval and on
 success, I call Z_ADDREF_P on the new zval.

 When I'm freeing everything, I need to remove the ref count. Digging
 through the source code, I found Z_DELREF_P. Would this be the correct
 macro to call? Is there anything else to keep in mind when calling it?

You should use zval_ptr_dtor instead. it will delref and free in case
the refcount hits 0.

Best,


 thx



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

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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

Hi!

 The less people beginning to rely on this bug the better, and this is
 a critical time. The impact of this BC break feels larger considering 
 MQ is enabled by default in PHP 5.3 and below.

I understand but a) nobody should be using magic quotes anyway and b)
holding release for 5.4.1 because of a very minor issue with easy
workaround doesn't seem productive for me. If we hold release for each
such thing, we'll never have 5.4.1 at all.

 This change shouldn't damage the RC QA process as all this does (tm) 
 is change the return of false to 0. And considering that the magic 
 quotes feature is removed, this change should not affect other code.

Code change means we can't release. I'm not comfortable putting untested
code in the release. We'll get it in 5.4.2.
-- 
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] RFC: Property get/set syntax (added isset/unset and references)

2012-04-24 Thread Clint Priest

That makes sense to me, a number (possibly all) of the errors I've 
added/modified could be eligible for this.  In those cases it would do the 
next best thing, such as ignore a setter definition, etc.  I may not have a 
perfect understanding of what would leave the engine in an unstable state 
however as Derick mentions on his post about E_RECOVERABLE_ERROR.  

 -Original Message-
 From: Anthony Ferrara [mailto:ircmax...@gmail.com]
 Sent: Tuesday, April 24, 2012 10:40 AM
 To: Clint Priest
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and 
 references)

 Clint,

 Additionally, one more comment related to the read-only and write-only.  I 
 noticed that you're using E_ERROR for improper access.
 Obviously you don't want this to be a warning, as the execution shouldn't 
 continue because that would be undefined.  However, what
 about setting it to E_RECOVERABLE_ERROR, so that it can be captured and 
 recovered from...?  The engine wouldn't be in an unstable
 state, so if we install an error_handler that throws an exception, there's no 
 reason to force-terminate the application...

 I guess I'm just adverse to using E_ERROR except for cases where it's 
 literally not safe to continue (usually because the engine is put in
 an inconsistent state)...

 Anthony

 On Tue, Apr 24, 2012 at 8:31 AM, Clint M Priest cpri...@zerocue.com wrote:
  I've updated the RFC to include details on adding isset/unset as well as 
  references, detailed below:

  isset/unset:

  class TimePeriod {
     private $Seconds = 3600;

     public $Hours {
         get { return $this-Seconds / 3600; }
         set { $this-Seconds = $value; }
         isset { return !is_null($this-Seconds); }
         unset { $this-Seconds = NULL; }
     }
  }

  References:

  class SampleClass {

     private $_dataArray = array(1,2,5,3);

     public $dataArray {

         get { return $this-_dataArray; }

     }

  }

  $o = new SampleClass();

  sort($o-dataArray);

  /* $o-dataArray == array(1,2,3,5); */

  Comments?

  These would also include automatic implementations which call the 
  respective functions on the backing field.  I could see only
 allowing isset/unset automatic implementations if get/set were also specified 
 as automatic implementations.

  Default implementations of isset/unset

  I'm also fielding comments/ideas on a way to always provide automatic 
  implementations of isset/unset for any accessor that didn't
 define one automatically.  One idea was for the isset (unspecified 
 implementation) which would return true if the getter provided any
 value which evaluated to true, such as this:

  class TimePeriod {
     private $Seconds = 3600;

     public $Hours {
         get { return $this-Seconds / 3600; }
         set { $this-Seconds = $value; }
     }
  }
  /* Default Implementation Concept */

         isset { return (int)$this-Hours; }
         unset { $this-Hours = NULL; }

  Note that the automatic implementation of unset is not strictly the same as 
  an unset() but without any sort of unset implementation
 a call to unset() would do nothing.  Alternatively we could throw an error to 
 a call on isset and/or unset against a property which didn't
 define an implementation.

  Thoughts?

  -Clint

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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

2012-04-24 Thread Philip Olson


On Apr 24, 2012, at 4:46 PM, Stas Malyshev wrote:

 Hi!
 
 The less people beginning to rely on this bug the better, and this is
 a critical time. The impact of this BC break feels larger considering 
 MQ is enabled by default in PHP 5.3 and below.
 
 I understand but a) nobody should be using magic quotes anyway and b)
 holding release for 5.4.1 because of a very minor issue with easy
 workaround doesn't seem productive for me. If we hold release for each
 such thing, we'll never have 5.4.1 at all.

I don\'t understand why get_magic_quotes_gpc() and get_magic_quotes_runtime()
get such a bad wrap. People using these functions are not using magic
quotes, but instead they (most) are writing code that will work in environments
that have it enabled. This helps code work in PHP 5.4 and below, as opposed 
to only PHP 5.4 and above.

And yes, the number of people that use \=== false\ here is small I reckon.
But this is a BC break in a BC function. Something feels very wrong about 
that.

So I understand that we cannot hold a release for every bug and that we 
have known bugs in every release, but will we revert this change after it
exists in two PHP releases? Whatever the case, this also means we\'ll have 
to document this change… and here I was trying to be lazy. :)

Regards,
Philip


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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell

Please review the section titled Inclusion of Mixed Code, which
contains the quoted conversation I referred to, with commentary about
bad, lazy architecture that is currently standard in numerous
frameworks. I understand that you feel that in future such frameworks
will make a different set of choices, but it still doesn't make sense
to import that old thread of argument into your RFC directly. I think
you mean to present the diagram only, with a more dispassionate
explanation of its purpose.

On Tue, Apr 24, 2012 at 7:27 PM, Kris Craig kris.cr...@gmail.com wrote:


 On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meest...@gmail.com
 wrote:


 On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

  On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote:
 
  * The RFC starts off immediately talking about file extensions, but
  the actual implementation proposed doesn't rely on file extensions or
  suggest any enforcement of them. That disparity should be addressed
  for clarity.
 
 
  Did you read the whole RFC?  Please refer to the Naming Conventions
  section.  It addresses this explicitly.
 
  Are you saying that section wasn't sufficiently clear or did you just
  miss
  it?
 

 I think what he means is that the abstract section should be, well,
 abstract. Currently it appears more detailed than it should be by referring
 to file extensions on the let go. I would phrase that section in a way that
 doesn't rely on another section to explain the used terminology.

 Also, references such as .phpp are used throughout the document to
 indicate a particular type of source file rather than an actual file
 extension. As such I would recommend moving your terminology section to
 right underneath abstract. This would improve the readability.


 Hmm I see your point.  Ok I'll update that langauge next time I can find a
 spare moment.

 So aside from that, what are your thoughts?  In addition to feedback on the
 wording itself, I'd also be interested in hearing your thoughts on the
 actual amended proposal itself.  Does the new script type alleviate your
 main concerns about frameworks (keeping in mind that a compromise is a
 solution that neither party likes but both parties can live with)?  What do
 you think about the require/include syntax suggestions?  Should it be
 comma-delinated or use as instead?  Etc.

 Thanks!

 --Kris




-- 
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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

Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)