Re: [PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.
On 14 December 2016 at 14:37, Christoph M. Becker <cmbecke...@gmx.de> wrote: > On 14.12.2016 at 14:32, Michael Wallner wrote: > > > On 14/12/16 14:17, Richard Quadling wrote: > >> Hi. > >> > >> I'm trying to find the replacement for Z_TYPE_PP (and several other > >> Z_xxx_PP). > >> > >> It seems these are no longer present in PHP7. > > > > In PHP-7, you usually do not encounter zval**, so the _PP macros were > > gone. Try _P(*zval) instead. > > See also <https://wiki.php.net/phpng-upgrading> for further information. > > -- > Christoph M. Becker > > Thank you for that. I wasn't sure where to look for the answer. -- Richard Quadling
[PHP-DEV] Looking for Z_TYPE_PP in all the wrong places.
Hi. I'm trying to find the replacement for Z_TYPE_PP (and several other Z_xxx_PP). It seems these are no longer present in PHP7. But, according to http://lxr.php.net/source/search?q===Z_TYPE_PPPHP-MASTER, there is still 1 use case of this particular macro. So. I'm hoping to see what the change for this is as it can't currently compile under PHP7? I'm not a hardcode C / PHP core developer, but I'm getting asked to provide support for the win32service extension. Currently it fails to compile : https://bugs.php.net/bug.php?id=73733 Just looking for some pointers. Literally! Ha ha! Regards, Richard Quadling.
[PHP-DEV] How do I detect a script failure in an extension's PHP_RSHUTDOWN_FUNCTION callback?
Hi. There is a bug report for the win32service pecl extension ( https://bugs.php.net/bug.php?id=69170). As a past contributor to this extension, I want to offer some help, even though I'm not on Windows any more (nor have access to a license). What I would like to provide is the ability to detect the nature of the scripts termination (for example, but not limited to, fatal error, unhandled exception, parse error - maybe, exit(n), etc.) Is this possible? If so, some suggestions would be nice. Thanks. Richard. -- Richard Quadling Twitter : @RQuadling
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On 14 January 2015 at 14:00, Pavel Kouřil pajou...@gmail.com wrote:
PS: Personally, I find the scalar typehint idea useless and cannot
find a real use case for it. Richard, would you mind giving an
example?
The point of the 'scalar' typehint comes about because we need to reject
non compatible types. Just like we do when we say array or callable.
Currently, if we want a method/function to accept a scalar, then we cannot
put any type hinting in and so we can supply an array, callable, class or
interface.
Being able to say 'scalar' would mean I can instantly inform the user that
any scalar can be used and that no type juggling will happen automatically.
For example, take ...
?php
function sum(scalar $left, scalar $right) { return $left + $right;}
?
Now in this example, sure the parameters will be juggled because of the +
operator.
But without the typehint, and the lack of operator overloading, you would
get an error if non-scalars are supplied in the addition, rather than in
the call. The + is fine, it is the wrong params to the function that should
be the problem. And a scalar typehint is the better place I think.
Now if we have polymorphic behaviour ...
?php
function sum(scalar $left, scalar $right) { return $left + $right;} // Type
juggled addition
function sum(array $left, array $right) { return array_merge($left,
$right);} // Array merging
function sum(string $left, string $right) { return $left . $right;} //
String concatenation.
?
(OK, 'sum' isn't a perfect example, but you see the point I hope).
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On 14 January 2015 at 09:41, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, January 14, 2015 11:33 AM
To: Leigh
Cc: PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Leigh,
On 14 Jan 2015, at 09:17, Leigh lei...@gmail.com wrote:
I really don't like this behaviour being changed at the call site. If
I design a function that I _know_ should only take a string, then I
want it to be an error if the user supplies anything else, so that
they know they messed up.
I don’t like the idea of being forced to use strict (or weak) type
checking
because the API author decided as much.
I don't either. But I don't like the user to do it either, it's something
that is a part of the language definition.
I completely agree with both Robert and Leigh. I liked the v0.1 one, but
v0.2 is DOA from my point of view. Arguably, from my POV, it's the one
option that's even worse than having strict typing exclusively.
Zeev
The issue of scalar type hinting has been around for a while, with various
proposals and RFCs, but no consensus. Each time a certain level of progress
is made, more issues arise.
It would seem that the major issues is that whatever a library/framework
developer decides, the user of that library/framework would have to develop
their application to fit. Is this such a bad thing? The comeback to that is
that PHP supports type juggling, so there is a different mechanism for
non-scalars to scalars. Fair enough.
From the lib developer's perspective, if a parameter to a function/method
is going to be treated as an integer and is expected to be an integer, then
they should be able to force/limit this just like they can when they say it
must be an array/callable/class/interface. But take into account the option
to enforce the type juggling.
I get 3 questions from this.
1 - Should the type hint restrict non matching types?
2 - When should the value be juggled to match the type hint if it is
different?
3 - Could we allow different signatures for the same method name? - A
different question entirely, but one that may be worth having in relation
to this proposal.
Whatever mechanism is used, it needs to be of zero effort for the user, but
fully understood of the effect.
I think to answer all of this, and to provide enough flexibility that
everyone can be made happy and understand the effect, I think the issues
could be resolved with the following.
1 - A type hint of 'scalar' is required.
This excludes other types (array/callable/class/interface) and would
specifically mean that no type juggling will take place as part of the
parameter passing.
If no type juggling is going to take place, why does it matter what the
type hint is? The advantage of having 'scalar' as a type hint is, as I
said, excludes non-scalars.
Now, if the method does something to the value and the value is passed by
reference, then that would need to be documented clearly.
2 - A scalar type type hint will automatically juggle. PHP is a dynamic
language and, as such, type juggling is used throughout. It shouldn't be
any different when a parameter is type hinted for scalars.
The frustration seems to be that without a way to say that this scalar will
NOT be type juggled (loose) or that it will be (strong) then we cannot move
forward.
Now, some of the comments related to this proposal (and others) is what to
do when the scalar type is of a different type to the parameter.
I think I've covered this by the use of the type hint 'scalar'.
Scalars get type juggled. Period. For good or bad. Until PHP becomes a
strongly type language, type juggling exists.
With the hinting, we can let users know that type juggling will now also
apply to parameters.
So.
?php
// Any type.
function anyType($a){}
// Current types.
function anArray(array $b){}
function aCallable(callable $c){}
function aClass(stdclass $d){}
function anInterface(Countable $e){}
// Any scalar - not juggled.
function anyScalar(scalar $f){}
// Any scalar - juggled
function willBeJuggledToBool(bool $g){}
function willBeJuggledToString(string $h){}
function willBeJuggledToFloat(float $i){}
function willBeJuggledToInteger(integer $j){}
?
Considering that there are no errors generated when type juggling of
scalars take place, there should be no errors when type juggling scalar
type hints for parameters.
In essence, if you are coding with scalars (ignore type hinting) and
relying on PHP to do the right thing when type juggling takes place, then
the same level of acceptance should be used when type juggling of scalar
parameters.
TL;DR; Rejecting calls to a scalar type typehinted function because the
value is of the wrong type doesn't fit with PHP's type juggling.
--
Richard Quadling
[PHP-DEV] Gist to allow for [SAPI] specific sections in ini files.
Hi. I've started playing with PHP installed on my Mac (and Centos VM). The version I had preinstalled on the VM uses an additional directory for ini files. I wanted to have some settings that were different depending upon the SAPI but not have a completely different set of files. So, I created the following gist which SEEMS to be working for me. https://gist.github.com/RQuadling/6562855 If anyone is interested, where should I go next? Regards, Richard. -- Richard Quadling Twitter : @RQuadling
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 2 September 2013 12:16, Nikita Popov nikita@gmail.com wrote: On Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans der...@php.net wrote: On Wed, 28 Aug 2013, Nikita Popov wrote: On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = No, php.ini-development should have what PHP does by default. That's not the case currently and as far as I know that is so intentionally. ini-development and PHP defaults differ not just in obscure extension settings, but also in core options like error_reporting, short_tags, maximum_execution_time, variables_order, register_argc_argv, display_startup_errors, output_buffering, etc etc etc. If these differences are not intentional, we should fix this. But I'm pretty sure they are. Nikita Also remember that different SAPI's have defaults too. -- Richard Quadling Twitter : @RQuadling
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
Hi. At the moment we can type hint array, classes, interfaces, callable, etc. As PHP is loosely typed and has type juggling thinking of (or at least trying to get PHP to enforce) a particular type (string, int, float, boolean) would be the wrong way to go - too many different behaviours (block if not a suitable type, block if not a suitable castable value, nonblocking with auto juggling, etc.). But if we consider that type juggling is the domain of the type 'scalar', then this would/could act as a suitable hinter. If a method has been designed to accept a scalar, there is nothing to stop the passing in of a resource, callable, closure or object, etc. But with the type hint, in my head, it is now no different to any other type hint. scalar, callable, interface, class, array (and others I'm sure). This isn't about trying to cast the value to a type - PHP is intrinsically loosely typed and that is core to everything. But as the core can easily tell an array from a callable, then a scalar would seem to fit right in. And if we can have scalar type hinting, scalar return type hinting would/should also be possible. Is this a feasible option? -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] RFC Proposal: New assign value operator
On 25 June 2013 11:01, Tom Oram t...@scl.co.uk wrote:
Hi everyone,
I've got an idea for an RFC proposal and from reading the instructions it
looks like I should run it past you guys first.
I have not made any contributions to PHP before although I have made some
custom modifications in house in the past and while I'm no longer familiar
with the PHP code base I am confident I have the skills to implement this
should it be accepted.
What I want to propose is a new assignment operator which rather than
setting the variable to completely new value it would update the value
while maintaining the type.
The main motivation for this is for easy assignment to value objects aka
assignment operator overloading via a magic method (prehaps called
__assign).
Here is an example ( for now I will use the PASCAL style assignment
operator := as the new operator as it is a know assignment operator and
currently not used in PHP):
// For a class defined like so...
class MoneyValue
{
protected $amount;
public function __assign($value)
{
$this-amount = $value;
}
}
// The amount could then be assigned using the new operator like this
$price = new MoneyValue();
$price := 29.99;
While the primary focus would be for assignment operator overloading as I
just displayed in the previous example, for consistency it could be used
with scalar values to preserve type like so:
// $str is now a string
$str = 'Original String';
// Using the new assignment variable would cast the value being assigned to
the variable's type
// (in this case a string). So
$str := 7;
// Would be the equivalent to
//
// $str = (string) 7;
//
// $str === 7
Another quick example:
$num = 5;
$num := '12';
// Equivalent to
//
// $num = (int) '12';
//
// $num === 12;
So what do you guys think?
If I get a good response I'll look into how to create a proper RFC and
start trying to work out how to implement it.
Many thanks and look forward to some responses,
Tom
Hi.
I'm not going to comment on the merits as such, but I'd be interested in
knowing what problem this RFC would solve?
Considering PHP has type juggling scalars, it would SEEM (I may have missed
the point) that this could result in data loss when the enforced conversion
results in 0/False/.
$num = 8;
$num := data from user; // 0
Unless that is the expected behaviour.
Where would this RFC change be used?
And having said all of that, I'm not against it, just want to see what it
would be useful for that isn't already part of PHP's toolbox.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
[PHP-DEV] Random Monday thought.
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Random Monday thought.
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.comwrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.
Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Random Monday thought.
On 3 June 2013 18:22, Brandon Wamboldt bran...@brandonwamboldt.ca wrote:
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.
On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadl...@gmail.comwrote:
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.com
wrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In
fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the
semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a
way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.
Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
Ah. DOH!
Would having an interface that swapped the default property accessor logic
be any better?
So, I could say ...
?php
class myBase implements \PHPMaintainedSetterGetterLogic {}
?
Hmmm...
I know it is still not perfect.
Shame.
I really would have liked setter/getter.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 26 May 2013 07:44, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I did not do a very good job explaining what I meant. I meant to say that requiring the timezone to be set prevents you from running without an ini file without any warnings. This is a big annoyance. If you insist on using the tool in a wrong way, you will be annoyed as the tool would not work in a way you want it to work. The right way is to set up the ini file. It takes about 2 seconds. Not in direct response to the above point, but more of a comment on this thread, and the various reappearances of this thread. As I understand things, some of the issues with asking the OS for the timezone are: 1 - The OS may not present a timezone in a way that PHP can easily access in a consistent way (i.e. too many flavours, mechanisms, etc.). 2 - The machine's local time and/or timezone may not be set correctly anyway. A point come to mind, in addition to all of this (and I'm not an expert, but this may be important) ... As more and more site/services are being hosted in the cloud, allowing requests to be handled locally geographically, in different timezones, does it make ANY sense in setting a timezone at all other than UTC? From what I can see, a server (which may not be under our control) COULD have pretty much any time and/or timezone on it. So even if we DO set a timezone in PHP, the time could still be out and that really isn't a good thing. If setting the timezone is so critical that a warning MUST be given when it is not set and that by ignoring the warning (either because of a lazy dev or a dev who cannot see the warning due to shared setup or something else) the scripts running that rely on accurate datetimezone, why not make this a fatal error. Yes. I know you've all jumped off your chairs to complain, but either PHP MUST have this setting appropriately, or it can live without it. The grey area of PHP can run, but your results, well, meh! does not fit well. If all it takes is 2s to set the INI file, why bother running without the setting. Is there any process that could be run that would do the following ... 1 - Determine the machines current date/time. 2 - Determine the machines current timezone (or lack of ability to return that information). 3 - Verify the local time with a known/accurate/maintained time server. 4 - From all of this, make an accurate decision or best guess as to what the timezone should be. 5 - Set an entry in the php.ini file appropriate for the guessed_timezone. So, the warning COULD be given, but allow a dev to run a PHP Team sourced process to determine where in the world the server is (I have access to servers all over Europe. I don't know the timezones that they are all in initially and had to work to confirm that the machine date/time/timezone was accurate. It would seem that a script could do this better, consistently, etc.). Just an idea on trying to solve this. If it could be automated, essentially whatever manual steps a dev would take to accurately set the timezone on an unknown server, then this process would certainly seem to be useful. But only because PHP gives a warning that the lack of the timezone is an issue. Regards, Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Cannot call constructor
On 24 May 2013 13:11, Ferenc Kovacs tyr...@gmail.com wrote: On Thu, May 23, 2013 at 11:32 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Right now, to avoid this situation, you have to do: if (method_exists(get_parent_class(), '__construct')) parent::__construct(); If you don't check for the method existing, you get: Fatal error: Cannot call constructor ... This makes a lot of sense. I think we also discussed this idea some time ago, but it didn't go anywhere that time... last time it was discussed on the list: http://www.mail-archive.com/internals@lists.php.net/msg50504.html to summarize it: Etienne was arguing that for the concrete example (Spl classes) it would be better to make sure that the object is properly initialized so having a constructor in the spl classes. Anthony was the only one who was against the idea of removing the error when you call a parent constructor which doesn't (explicitly) have one. Otherwise everybody else seemed to agree with the above change and only the implementation was discussed: - we should remove the error completelly - we should make the error less serious (please don't do this) - we should always create a common ancestor for every class by default which have an empty constructor/destructor - we should always create an empty constructor/desctructor for every class without it. So maybe we could discuss this and based on the feedback create an rfc (with or without a vote for the alternative implementations). Hi. I'm not an expert here, so just thinking out loud ... If a theoretical \PHP\baseclass can have empty __construct()/__destruct(), what about the other magic methods? OK, I suppose cascading some of the magic methods to a parent and having a null parent at the very very bottom of the heap sounds useful. But I'm not totally sure. Is there much/any need for a true base class that ALL classes will extend from, including those in extensions. Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] vsprintf()
On 24 April 2013 17:31, Richard Bradley richard.brad...@softwire.comwrote: -Original Message- From: Rasmus Schultz [mailto:ras...@mindplay.dk] Sent: 24 April 2013 16:45 To: PHP internals Subject: [PHP-DEV] vsprintf() This is all kinds of wrong: http://3v4l.org/UZFME So the order in which the properties were defined is the magic that makes this work. Wow. WTF? Do I need to explain in detail why this is all kinds of effed up? Yes, please. What's the big deal here? If you coerce an object to an array, you get the public properties in the order in which they were declared. See http://www.php.net/manual/en/language.types.array.php If an object is converted to an array, the result is an array whose elements are the object's properties. The keys are the member variable names, with a few notable exceptions: What was the point of your email? Did you hope for some action to arise, or are you just letting off steam? Best, Rich Oh! Another magic method opportunity ... /** * Operates just like __toString(), but returns an array. */ public function __toArray(); (ducking) -- Richard Quadling Twitter : @RQuadling
Re: [PHP-DEV] References in rfc:propertygetsetsyntax
On 22 January 2013 01:08, Clint Priest cpri...@zerocue.com wrote:
On 1/21/2013 12:36 PM, Richard Quadling wrote:
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of get{}.
How about pass-by-reference for set{}?
It works, it was simply not included in that section, which it now is:
Documented in the references section:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?#references
Normally, a function definition dictates this.
But if $value is already passed, a reference to it ($value) is not
going to be referencing the external variable surely?
Whilst objects are always passed by reference (I assume this is still
the case for this rfc and I can see no reason why it isn't), and I
think I can see the sort of issues that setting an accessor to a
reference (binding the value of a property in this class to something
external to the class - yeah - just eek!), is this an issue?
Will users _want_ ...
set($value){ $this-externally_linked_var = $value; }
I'm not expecting any changes to anything, just looking for clarification.
Regards,
Richard.
--
-Clint
Brilliant. Thank you.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors
On 22 January 2013 08:15, Lars Schultz lars.schu...@toolpark.com wrote:
Am 22.01.2013 09:07, schrieb Nikita Popov:
It's not just about the lines of code. It's about having a more readable
and more intuitive syntax. Am I the only one who thinks that public $date
{ get; set(DateTime $date); } looks pretty ugly/unclear compared to
public DateTime $date;?
FWIW: I agree;) If accessors get through, I'd rather have this alternate
syntax. The other looks like a typo. I don't get to vote though...
I'm not an expert, so I may be getting the wrong end of the stick.
If you type hint the property, you cannot supply anything but that
type when you set it?
Where as, if you type hint the set parameter, you can supply that
type, and have the set method extract/perform whatever is required and
assign that result to the local property, which may be of a different
type. I would assume that the property has it's own docblock to
reflect the stored type.
Of course, I certainly see a bad case of confusion being presented
here if the stored type and the set type are different. And it would
seem that type hinting the property would solve this, but you know
developers will always want to get around blocks, is there any
sensible use case for having type hinted set() parameter as well as
type hinted property?
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] References in rfc:propertygetsetsyntax
Hello.
This may have already been covered, so apologies ...
With https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#references,
the return by reference is handled by the use of get{}.
How about pass-by-reference for set{}?
Normally, a function definition dictates this.
But if $value is already passed, a reference to it ($value) is not
going to be referencing the external variable surely?
Whilst objects are always passed by reference (I assume this is still
the case for this rfc and I can see no reason why it isn't), and I
think I can see the sort of issues that setting an accessor to a
reference (binding the value of a property in this class to something
external to the class - yeah - just eek!), is this an issue?
Will users _want_ ...
set($value){ $this-externally_linked_var = $value; }
I'm not expecting any changes to anything, just looking for clarification.
Regards,
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] run-tests.php and dynamic extension dependencies
On 28 November 2011 13:36, Derick Rethans der...@php.net wrote: On Mon, 28 Nov 2011, Ferenc Kovacs wrote: On Mon, Nov 28, 2011 at 2:11 PM, Derick Rethans der...@php.net wrote: I'm currently writing a shared extension thta depends on another shared extension (igbinary). make test doesn't handle this at the moment, because it removes every extension= line from it's temporary php.ini. This means that the dependent extension (igbinary) now isn't loaded, which means my extension doesn't load either and obviously all the tests fail. I've attached a patch that adds a new --EXTENSIONS-- section to the PHPT format. The run-tests.php script makes sure that all extensions in that last are added to the PHP command with -dextension=... , but only if they're not build in (or already loaded in some other way). The patch is simple, and it doesn't touch any other section or functionality so I'm suggesting to commit it to PHP 5.3/5.4 and trunk some time soon. wouldn't --INI-- + extension do the same? No, as the run-tests.php framework changes extension_dir to ./modules/. It would also cause issues if you try to load an extension that is built-in. And it's not portable because not on every platform the extension name = extension.so Can you use PHP_SHLIB_SUFFIX? -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changes to constructor signature checks
On 23 November 2011 18:37, Anthony Ferrara ircmax...@gmail.com wrote:
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
on definition, as it is superfluous...
Option 2. Fix grandchild signature checking to be inline for how
signatures work with other methods.
Personally, I think option 2 is the better one. I see it being odd
and inconsistent that all methods work one way, and constructors work
differently. But that's just my feeling (and I know others disagree
there).
And please don't reduce the error level of a signature change (as it
would introduce even more inconsistency)...
Just my $0.02...
Anthony
On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't think
it's a large enough issue to drag on, even when I disagree with it - both
theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface would
not happen anyway, so this does not affect them.
** The current change represents a minor break in BC, that should be noted
in the manual. **
Also, a decision needs to be made on what to do with grandchildren. As I
mentioned, the following produces no E_FATAL and no warnings:
abstract class A { abstract public function __construct($a, $b); }
class B extends A { public function __construct($a, $b) {} }
class C extends B { public function __construct(ArrayObject $d) {}
While this is correct behavior to me (ability for concrete to use its own
ctor), using the *current logic* strict signature checking enforced from an
abstract, then the above is also wrong.
** Can we decide what to do with that situation? **
On 11/18/11 5:05 AM, Pierre Joye wrote:
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
I think this is a sufficient compromise- I don't see anything E_FATAL about
a signature change in ctors (I actually see nothing wrong with it, but it's
clear the community is divided there).
** Can we make that change? **
Thanks,
-ralph
What is the normal way for userland developers to learn about
constructors? Do they know about LSP? If they do, does it apply to
constructors?
A comment on StackOverflow [1]
At its heart LSP is about interfaces and contracts as well as how to
decided when to extend a class vs. use another strategy such as
composition to achieve your goal.
I am self taught. It was always my understanding that the constructor
was special in that it is, essentially, a magic method that can only
respond to the new keyword. Being able to call the constructor
directly, ..., that does feel a little odd as I can't actually
construct a new instance that way.
Using an interface to enforce the sig is fine. That's the exact nature
of an interface, to enforce the contract by design and if the
StackOverflow comment is accurate, then my understanding of interfaces
is fine with regard to LSP.
An abstract class, by its very nature is not formed. It isn't a
contract. It is an idea and the concrete doesn't need to fit
perfectly. OK. There is some things that are fixed, method signatures
most accept the parameters defined in the subclass but can add more
(as I understand things).
But is the signature of the constructor in an abstract class to be
enforced? I feel that it shouldn't be. It is a special method.
WikiPedia [2] has an article on Constructor Overloading. It says
Constructors, used to create instances of an object, may also be
overloaded in some object oriented programming languages.. OK, so
WikiPedia may have a different opinion tomorrow.
Whilst we don't support overloading in the same way (I think we can
simulate it with __call() easily enough with ReflectionParameter being
my friend here maybe).
We, DO, provide the tools to allow overloading and non LSP coding
practises. Is it a great leap to also allow the same flexibility with
constructors?
Regards,
Richard Quadling.
[1]
http://stackoverflow.com/questions/56860/what-is-the-liskov-substitution-principle
[2] http://en.wikipedia.org/wiki/Constructor_overloading#Constructor_overloading
--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 23 November 2011 01:50, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Folks: I just stumbled upon a regression in 5.4. In an array, a sub-sub-key of an existing key is now returning a letter of the value indexed by the main key. I'm raising it here so it doesn't get lost. https://bugs.php.net/bug.php?id=60362 Thanks, --Dan I've just ran the code for the bug through all the V5 releases/betas/alphas/RCs. V5.0.0 to V5.0.2 BEHAVIOR CHANGED: sub-key 'non_existent' is not set. expected: sub-key 1 is set: string(1) o --- good: sub-sub-key 'sub_sub' is not set. good: sub-sub-key 0 is not set. --- BEHAVIOR CHANGED: sub-key 'non_existent' is empty. expected: sub-key 1 is NOT empty: string(1) o --- good: sub-sub-key 'sub_sub' is empty. good: sub-sub-key 0 is empty. V5.0.3 (don't have) V5.0.4 to V5.3.9RC2-dev (as at around 10am GMT on the 23rd Nov 2011). expected: sub-key 'non_existent' is set: string(1) f expected: sub-key 1 is set: string(1) o --- good: sub-sub-key 'sub_sub' is not set. good: sub-sub-key 0 is not set. --- expected: sub-key 'non_existent' is not empty: string(1) f expected: sub-key 1 is NOT empty: string(1) o --- good: sub-sub-key 'sub_sub' is empty. good: sub-sub-key 0 is empty. V5.4+ (betas and RCs) expected: sub-key 'non_existent' is set: string(1) f expected: sub-key 1 is set: string(1) o --- BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) f BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) o --- expected: sub-key 'non_existent' is not empty: string(1) f expected: sub-key 1 is NOT empty: string(1) o --- BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) f BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) o So there was a previous bug fix in V5.0.2 (maybe 5.0.3). So, the whole type juggling point here is mute. It has been that way for a very long time. I just didn't realise it. And if that is a valid result (var_dump($arr['exists']['non_existent']) === 'f') - which it now is obviously is, then the change in V5.4 is certainly a bug fix. But, it is a significant enough issue that warrants a decent amount of documentation. -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On 23 November 2011 15:31, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Again Folks:
On Wed, Nov 23, 2011 at 09:14:09AM -0500, Daniel Convissor wrote:
$a = 'foo';
echo $a['blah'] . \n;
But that second one echos out f. This is a huge WTF.
Two things for the record on this front. First, i've been actively
using PHP for, what, ten years or so, and have never run into this
behavior before. Second, this behavior turns the following one liner:
if (isset($arr['package']['attribs']['version'])) {
Into this:
if (is_array($arr)
array_key_exists('package', $arr)
is_array($arr['package'])
array_key_exists('attribs', $arr['package'])
is_array($arr['package']['attribs'])
array_key_exists('version', $arr['package']['attribs'])
!empty($arr['package']['attribs']['version']))
{
I agree with Daniel on this.
Just looking for any test relating to isset() to see what tests will now fail.
Neither of the isset() tests ext/standard/tests/general_functions look
at arrays with associative indices.
The behaviour with regard to unavailable associative indices has no tests.
But using loose typing as a fallback for non existent keys seems
really really wrong.
Especially if the key is a constant. On what planet should ...
isset($arr['exists']['test_existance']) should become isset($arr['exists'][0])
That just seems really wrong and the work around is awful.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
On 18 November 2011 13:31, Felipe Pena felipe...@gmail.com wrote: 2011/11/18 Pierre Joye pierre@gmail.com: same here, and for any other places in the ob_* APIs. Functions returns false on error, cleaning something already cleaned or empty is not an erro. Same opinion here. WOW. All the developers agreeing with a common goal. Go on. I dare any one of you to spoil my good mood. I handed my notice in today. Off to work for Fantasy Shopper in the New Year. Very excited. I know most (if not all) of you don't know who I am, but hey, it's Friday and tonight is insane drinking until you fall over night! Have a good weekend everyone. I know I will. -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
On 18 November 2011 17:37, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Nov 18, 2011 at 5:40 PM, Richard Quadling rquadl...@gmail.com wrote: On 18 November 2011 13:31, Felipe Pena felipe...@gmail.com wrote: 2011/11/18 Pierre Joye pierre@gmail.com: same here, and for any other places in the ob_* APIs. Functions returns false on error, cleaning something already cleaned or empty is not an erro. Same opinion here. WOW. All the developers agreeing with a common goal. it happens. :) Go on. I dare any one of you to spoil my good mood. I handed my notice in today. Off to work for Fantasy Shopper in the New Year. Very excited. I know most (if not all) of you don't know who I am, but hey, it's Friday and tonight is insane drinking until you fall over night! Have a good weekend everyone. I know I will. good luck with your next gig! (if I would guessed, I would said that your next job will be some official position at Experts Exchange.) -- Ferenc Kovács @Tyr43l - http://tyrael.hu No. I'm going to be running the back end project of the new social gaming site Fantasy Shopper (http://fan.sh/6/370). High Street and Fashion Retailing meets social gaming for real world value. New, exciting and very very interesting. Lots of scope for growth. New ideas, integration into different media/technologies. Gamification of shopping but with the real shops and real products. We just won the Amazon Web Services StartUp Challenge 2011. The first non US company to ever win it. http://aws.amazon.com/startupchallenge/ We are all extremely pleased with ourselves. And it is a great opportunity for me too. So feeling really good. Richard. P.S. Experts Exchange would have been great too, but I don't know if it is really in the same league. -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] some notes about traits
On 16 November 2011 00:17, Rasmus Schultz ras...@mindplay.dk wrote:
Here's a better example of something useful that actually works:
trait Accessors
{
public function __get($name)
{
return $this-{'get'.$name}();
}
public function __set($name, $value)
{
$this-{'set'.$name}($value);
}
}
class OrderLine
{
use Accessors;
public $price;
public $amount;
public function getTotal()
{
return $this-price * $this-amount;
}
}
$line = new OrderLine;
$line-price = 20;
$line-amount = 3;
echo Total cost: .$line-total;
I like that example. It shows, at a fairly simple level, the ability
to compose a class from potentially multiple traits.
Putting the __magic_methods in a trait, what a great idea. This
mechanism is allows for all sorts of easy to expand ideas.
You _COULD_ use this trait to implement discrete getters and setters ...
?php
/**
* Trait to provide setter and getter functionality
* with an exception for any missing method.
*/
trait Accessors
{
public function __get($name)
{
if (method_exists($this, 'get' . $name))
{
return $this-{'get' . $name}();
}
elseif (property_exists($this, $name))
{
return $this-{$name};
}
else
{
throw new Exception(Cannot retrieve value of
'$name'.);
}
}
public function __set($name, $value)
{
if (method_exists($this, 'set' . $name))
{
$this-{'set' . $name}($value);
}
elseif (property_exists($this, $name))
{
$this-{$name} = $value;
}
else
{
throw new Exception(Cannot set value for '$name'.);
}
}
}
/**
* @property float $price
* @property float $amount
* @property float $tax
* @property-readonly float $total
*/
class OrderLine
{
use Accessors;
protected $price;
protected $amount;
protected $tax;
public function getTotal()
{
return $this-price * $this-amount * (1 + ($this-tax / 100));
}
protected function getPrice()
{
return $this-price;
}
protected function getAmount()
{
return $this-amount;
}
protected function setPrice($price)
{
$this-price = $price;
}
protected function setAmount($amount)
{
$this-amount = $amount;
}
}
$line = new OrderLine;
$line-price = 20;
$line-amount = 3;
$line-tax = 10;
echo Total cost: .$line-total;
?
outputs ...
Total cost : 66
So, the actual methods are hidden from public, but a developer can
extend the class to add additional processing.
Interestingly, I've used property_exists to expose public access to
protected properties. I suppose that is always possible. Bad design
really. I would guess you wouldn't mix the different access mechanisms
(public/protected/private, __get/__set, getter()/setter()).
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __constructor parameter limitations.
On 19 September 2011 10:17, Etienne Kneuss col...@php.net wrote:
Hi,
2011/9/19 Frédéric Hardy frederic.ha...@mageekbox.net
Hi !
What is the utility of abstract method if implementation can not follow
the signature (constraints ?) of the abstract method ?
In this case, abstract methods are totaly useless !
Moreover, i think that it's not compatible with Liskov substitution
principle.
Subclasses can loosen the preconditions, that's eactly what happens here and
it is perfectly fine in theory.
WOW. I really didn't expect this as a response to what, for me, was
quite an innocent question. Normally I get a 3 comments pointing me in
the right direction and I'm happy.
Maybe its me. But something that is abstract certain implies to me a
loose idea. The keywords have inherent meaning. At least in English.
If a class, abstract or otherwise, has the requirement to have an
enforced parameter list for a method, then would seem to be the role
of an interface. An abstract class and an method declared in an
interface, both require implementation. But with an interface, you are
not able to change the parameters. would seem to satisfy LSP.
Unless you use an interface to enforce the parameter order, how else
do you guarantee the contract?
If you also enforce the parameters for other methods (abstract or
otherwise - I'm still not 100% on the reason for the difference - or,
at this stage, if there even is a difference), then interfaces are
seemingly redundant.
Take the following code ...
?php
abstract class abstractBase {
abstract public function __construct($a, $b);
}
class ConcreteBase extends abstractBase {
public function __construct($a, $b, $c = null) {
}
}
class SuperCrete extends ConcreteBase {
public function __construct($a, $b, $c, $d = null) {
parent::__construct($a, $b, $c);
}
}
$cb = new ConcreteBase(1,2);
$sc = new SuperCrete(1,2,3);
?
The signatures here feel completely right, though MAYBE one could
argue that SuperCrete's constructor is off because $c is not optional.
I don't think $a and $b can ever become optional or missing from any
sub-class' definition.
As things stand, 5.4.0-beta doesn't report any problem with this code.
Have I made a mountain out of a mole hill?
(http://en.wikipedia.org/wiki/Make_a_mountain_out_of_a_molehill for
those who don't know the English idiom).
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __constructor parameter limitations.
Hi. With the recent BC with regard the locking of the constructor's signature for subclasses, what is the expected mechanism for allowing a subclass to have additional parameters? You can always supply them and use func_get_args() / func_num_args() / etc. to read them. It would seem that the limitation restricts the capabilities. I'm not a purist. Software development is a compromise between purity and getting the job done in an efficient and understandable manner. By allowing undocumented parameters to the constructor (due to the enforced signature), this would seem to break things on a different front (I can't docblock non defined parameters for examples). Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __constructor parameter limitations.
On 17 September 2011 15:52, Ferenc Kovacs tyr...@gmail.com wrote:
maybe Richard referring to https://bugs.php.net/bug.php?id=55085 ?
but those change only affects the abstract classes.
Tyrael
On Sat, Sep 17, 2011 at 3:43 PM, Nikita Popov nikita@googlemail.com
wrote:
Hi Richard!
Which change are you talking about? I just tried doing:
?php
class A { public function __construct($a) { } }
class B extends A { public function __construct($a, $b) { } }
And it worked on 5.4 Beta 1 without errors.
Nikita
On Sat, Sep 17, 2011 at 3:27 PM, Richard Quadling rquadl...@gmail.com
wrote:
Hi.
With the recent BC with regard the locking of the constructor's
signature for subclasses, what is the expected mechanism for allowing
a subclass to have additional parameters?
You can always supply them and use func_get_args() / func_num_args() /
etc. to read them.
It would seem that the limitation restricts the capabilities. I'm not
a purist. Software development is a compromise between purity and
getting the job done in an efficient and understandable manner.
By allowing undocumented parameters to the constructor (due to the
enforced signature), this would seem to break things on a different
front (I can't docblock non defined parameters for examples).
My question was due to the documentation commit
http://news.php.net/php.doc.cvs/8818 and
http://news.php.net/php.doc.cvs/8819.
Not being an expert, so I don't know all the theory, but it would seem
an abstract class defines the idea and the concrete class defines it
more - I need a better grasp of words here.
An interface is the absolute here. Sub classes (the super class being
abstract or otherwise), should be able to define MORE parameters (with
or without default values). Otherwise they aren't extending, but
implementing - and for me that's the role of an interface.
It is only interfaces that guarantee things because the interface IS
the guarantee.
A class isn't beholden to anything it inherits. You can override
methods, completely obscuring the super class if you so want.
A subclass can completely divorce itself from the superclass.
But not with an interface.
PHP has always been a very very flexible language. I feel that if a
developer absolutely must enforce a method's signature, then an
interface is going to do that 100% and is a relatively easy way to do
things. Enforcing method signatures in subclasses (I don't know why
abstract classes are treated differently) does sort of make the
interface redundant.
Unless there is a real issue with the internal engine, then the method
signatures should be flexible. Unless an interface is used.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A couple of missing directories if configure.js is forgotten.
Sure thing. https://bugs.php.net/bug.php?id=55709 and https://bugs.php.net/bug.php?id=55710 2011/9/15 Pierre Joye pierre@gmail.com: hi Richard, Can you open a bug for each of your patches please? Thanks! 2011/9/15 Ángel González keis...@gmail.com: Richard Quadling wrote: Hi. Sometimes I remove Release prior to nmake to make sure everything builds clean. 2 directories fail to get build Release\win32 Release\devel The attached patch fixes that. - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL Richard. Shouldn't you add them to BUILD_DIRS_SUB instead? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A couple of missing directories if configure.js is forgotten.
2011/9/15 Ángel González keis...@gmail.com: Richard Quadling wrote: Hi. Sometimes I remove Release prior to nmake to make sure everything builds clean. 2 directories fail to get build Release\win32 Release\devel The attached patch fixes that. - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL Richard. Shouldn't you add them to BUILD_DIRS_SUB instead? Yep! See bug https://bugs.php.net/bug.php?id=55710 with latest patch. It was an edge case for the win32 directory caused by having pecl/win32service configured for building. Any extension with win32 in it would have caused the issue. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A couple of missing directories if configure.js is forgotten.
Hi. Sometimes I remove Release prior to nmake to make sure everything builds clean. 2 directories fail to get build Release\win32 Release\devel The attached patch fixes that. Index: win32/build/Makefile === --- win32/build/Makefile(revision 316815) +++ win32/build/Makefile(working copy) @@ -91,7 +91,7 @@ @echo Recreating build dirs @if not exist $(BUILD_DIR) mkdir $(BUILD_DIR) @cd $(BUILD_DIR) - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL @if not exist $(BUILD_DIR_DEV) @mkdir $(BUILD_DIR_DEV) NUL @cd $(PHP_SRC_DIR) Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea Index: win32/build/Makefile === --- win32/build/Makefile(revision 316815) +++ win32/build/Makefile(working copy) @@ -91,7 +91,7 @@ @echo Recreating build dirs @if not exist $(BUILD_DIR) mkdir $(BUILD_DIR) @cd $(BUILD_DIR) - @for %D in ($(BUILD_DIRS_SUB)) do @if not exist %D @mkdir %D NUL + @for %D in ($(BUILD_DIRS_SUB) devel win32) do @if not exist %D @mkdir %D NUL @if not exist $(BUILD_DIR_DEV) @mkdir $(BUILD_DIR_DEV) NUL @cd $(PHP_SRC_DIR) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/session/tests/rfc1867_invalid_settings.phpt branches/PHP_5_4/ext/session/tests/rfc1867_invalid_settings_2.phpt trunk/ext/session/tes
On 13 September 2011 17:27, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Sep 13, 2011 at 6:23 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/13/11 7:49 AM, Ferenc Kovacs wrote: Stas, I still don't know why do have a custom php.ini, and why is it used. The make test should create tmp-php.ini for you (and copy your Everybody has custom php.ini, what do you mean why? Nobody uses just defaults. It is used because -n -c is not passed when you run run-tests. Right, but the goal of these tests is to test behavior under certain conditions. If a test can't be executed in a generic way then its setting must be changed. It seems to be the case with this one. Hi all. Surely the test must first determine if it is an appropriate test for the environment. Just like we have tests check to see if an extension is available before running then tests that are tuned to a specific value from a php.ini file (default or custom) must first check that the test is appropriate to the value being tested. As a daft example. If you were testing that the data written to a session file was correct, the format of the serialisation, as defined in session.serialize_handler, has to be taken into consideration. If the php.ini said to use WDDX, testing the default format would be incorrect. So, if there are radically different outcomes, depending upon the values read from INI files (default or custom), then multiple tests are needed for each value, or the test needs to branch accordingly and indicate that a particular value is untested - highlighting unexpected changes in the default value (maybe). With reference to the discussion a while ago about what PHP considers the right settings for php.ini, in my mind the default settings for testing should be the production values. I think this is the case in 5.4, that is running tests with no php.ini is the equivalent to running with php.ini-production which is the defaults built into the engine. If not, then each developer will be having a different INI file and testing will be for different value and test fixes on one platform could result in a failure on another. If a test requires a different INI file, then it should set it itself. If it is the case that every developer creates the same ini file for a specific value when testing, then maybe the default value is incorrect. As I see it, testing for different values in INI files can only be done by having multiple tests or by a single test generating multiple sub-tests to check for the known values. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: drop bison 1.x?
On 2 September 2011 00:23, Pierre Joye pierre@gmail.com wrote: It would be nice to get at least a little bit of the context before going in any kind of arguing. For one the failing test happening after my commit was my mistake. It has nothing to do with the bison versions but me having committed a wrong expectf expression. However, the 1.x support was the reason why I made this change. Instead of making it right I've updated my boxes with bison 2.x. Lazy and better.1 That being cleared, anyone using 1.x will have noticed that the tests did not pass. Fact is that it looks like I am the only tester using 2.x. Do you have any example of supported systems still having only bison 1.x support? Also 1.x is 13 years old, I would very surprised to see anyone still using such an old system with 5.3. Now, as stated earlier, my testing hosts do not have 1.x anymore and I won't care about it anymore either. So basically nobody here takes care if it anymore but let claim we do :) On Sep 2, 2011 12:04 AM, Ferenc Kovacs tyr...@gmail.com wrote: The default build tools for building PHP on Windows uses Bison 1.27. http://windows.php.net/downloads/php-sdk/php-sdk-binary-tools-20110512.zip contains [2011-09-02 11:36:29] [D:\php-sdk-binary-tools-20110512\bin] [] bison.exe --version GNU Bison version 1.27 -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Choosing a distributed version control system for PHP
On 26 August 2011 08:48, dukeofgaming dukeofgam...@gmail.com wrote: Having current SVN-only contributors learn it might going to be quite a challenge. That's me. And I am VERY used to TortoiseSVN - a visual tool integrated into Windows Explorer (not IE, but the filesystem exploring tool for Windows). I recently worked with some mac users and they were a little jealous of that ability. I point and click and commit from my explorer. I really don't want to have to work at the command line. Sure I can, but the tool needs to be a LOT easier than that. With SVN, things feel pretty simple. I don't currently get git. It SEEMS very complicated for no gain - when all I'm working on is 1 extension (pecl/win32service) and phpdoc. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionClass::newInstanceWithoutConstructor()
On 25 August 2011 10:46, Sebastian Bergmann sebast...@php.net wrote: I have attached a patch to https://bugs.php.net/bug.php?id=55490 that implements ReflectionClass::newInstanceWithoutConstructor() to create an object a class without invoking the constructor. As there are certain internal classes that would crash when their constructor is not invoked, this new method of the Reflection API only works for userland-defined classes. Unless there are objections, I will commit this change to PHP_5_4 and trunk on Monday. I will add the method to the documentation as well, of course. Wouldn't ReflectionClass::newMockInstance() be a better name? What other use cases exists? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 12 August 2011 20:02, Stas Malyshev smalys...@sugarcrm.com wrote: Branches are different things than github forks, for different purposes. Branch is a project, fork is a workspace. You can have multiple people work on a project, using multiple workspaces. And today I learned something. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getopt bc break 5.2 - 5.3
On 8 August 2011 12:40, Martin Spütz mar...@spuetz.net wrote:
Hello,
I have a lot legacy code that doesn't work with 5.3's getopt.
PHP 5.2.14 (cli) (built: Sep 24 2010 12:50:53)
$ php test.php Module.Controller.Action -p foobar
array(1) {
[p]=
string(6) foobar
}
PHP 5.3.6 (cli) (built: Aug 8 2011 11:02:31):
$ php test.php Module.Controller.Action -p foobar
array(0) {
}
test.php:
var_dump(getopt(p:));
Is this by-design?
Thanks,
Martin
Can you try ...
php test.php -- Module.Controller.Action -p foobar
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 7 August 2011 21:50, David Soria Parra d...@php.net wrote: Hi Internals, Distributed Version Control Systems (DVCS) getting more and more popular. In fact they have been discussed within the PHP community and on Internals a few times. It came to my attention that more and more people like to see PHP move to a DVCS to solve some of the current issues (and get other ones). I was asked to put together a RFC, and so here we are. I've created an initial draft. It is mostly based on the very good Python PEP-0374. It compares Git and Mercurial. https://wiki.php.net/rfc/dvcs There are reasons for choosing these systems: * Both are quite popular * I know them * Most PHP devs that I know, know at least on of them * Big projects have recently moved to them, they have similar requirements like PHP The RFC is far from done, so please help me finishing it and get it out. This is a call for participation to help to get a (probably heated) discussed started and work on the RFC to make it good enough to finally choose a system or, and that is a valid option, stay with SVN. So if: - you are interested in DVCS - know a little bit about PHPs requirements for a DVCS - are not a fanboy Feel free to discuss this and add your thoughts to the RFC. I would love to not do this on my own. Feel free to catch me on IRC (dsp_ on php.pecl) and discuss it. NOTE: this is not the place for any religiouise discussion about git vs mercurial whatsover. if you have nothing else to add than hg is $*** anyway or think hosting platform XY will solve all our problems without reading the RFC carefully, please post to alt.relgion.* and not here. - David I feel I have a major objection to using a DVCS for PHP. Currently, a single source provides a sense of authority. If bad code is committed, it will be quickly dealt with. If good code is incomplete it may be withdrawn or fixed. In most cases the features that exist in a branch are well thought out and many clever brains have seen it and interacted with it to make it what it is. So, when someone like me comes along, someone capable of building the code and playing with it at a very minor level, I can be sure that if things don't work, it is probably me that's broke it and that I can rely on the branch to contain good working code. OK. I know ITRW, things do get left unfinished or plain broken. But it isn't as if the code belongs to a single person who may have not spent all their time with it. Whilst I am happy to use my own builds on my dev setups, I'm also happy to rely on the official releases from The PHP Group. Now let's envisage a DVCS. There will be (not might be, but will be), multiple, and potentially conflicting/incompatible, versions available. Which do I choose? If everyone is capable of forking PHP, which is the official one? In the event of a single official repo, then why bother with a DVCS? (I'll admit I'm naive on the true requirement of DVCS, as I think SVN works very well). The main thing I'm worried about is if feature X splits the core devs so much that there are 2 competing repos, both with a significant number of core devs supporting each repo, how do I choose which is which? If my abilities include being able to code at the core level, which should I support? Both? All 3, 4 or 10 different forks? Having a single repository for the code makes the code the official, authoritative version. A DVCS will have too many champions and I feel would drastically dilute that authority. Regards, Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] asString() method vs __toString() magic method.
On 3 August 2011 00:51, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/2/11 7:51 AM, Etienne Kneuss wrote: The (historic) reason is that the toString conversion occurs at various places in the engine, and in some of them, throwing exceptions caused trouble. It is not clear whether this limitation it still required. In any case, it could almost certainly be fixed. In theory, yes. In practice, that means ensuring every place in the engine that does convert_to_string() can be safely interrupted by an exception and can handle that exception properly. This is pretty hard to do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 What would be a good way to explain this in the documentation. Just saying that you can't is only going to present more questions. Explaining it a way that isn't too technical, but covers the basis would be good. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] asString() method vs __toString() magic method.
Hi.
Given the relatively simple code below, why can't I throw an exception
in __toString()?
?php
class AlwaysFails {
public function asString() {
throw new Exception('Failed in asString()');
}
public function __toString() {
throw new Exception('Failed in __toString()');
}
}
$failure = new AlwaysFails;
try {
echo $failure-asString();
}
catch(Exception $ex) {
echo $ex-getMessage();
}
try {
echo $failure;
}
catch(Exception $ex) {
echo $ex-getMessage();
}
?
outputs ...
Failed in asString()
Fatal error: Method AlwaysFails::__toString() must not throw an
exception in Z:\fa1.php on line 21
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] asString() method vs __toString() magic method.
On 2 August 2011 16:09, Keloran ava...@gmail.com wrote: i didnt think any of the magic functions could throw exceptions All magic methods can throw exceptions except __toString. There is some oddity with __set_state() (in terms of the pattern of output is different). http://pastebin.com/nGkP7kKf outputs ... In : failure2::__construct Thrown exception in : failure2::__construct In : failure1::__get Thrown exception in : failure1::__get In : failure1::__set Thrown exception in : failure1::__set In : failure1::__call Thrown exception in : failure1::__call In : failure1::__callStatic Thrown exception in : failure1::__callStatic In : failure1::__isset Thrown exception in : failure1::__isset In : failure1::__unset Thrown exception in : failure1::__unset In : failure1::__invoke Thrown exception in : failure1::__invoke In : failure1::__clone Thrown exception in : failure1::__clone DateTime::__set_state(array( 'date' = '2011-08-02 16:54:03', 'timezone_type' = 3, 'timezone' = 'Europe/London', )) In : failure3::__destruct Thrown exception in : failure3::__destruct In : failure1::__sleep Thrown exception in : failure1::__sleep In : failure1::__wakeup Thrown exception in : failure1::__wakeup But __toString() throws a Fatal Error. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception throwed if parent::__construct() not called in \DirectoryIterator subclass
On 28 July 2011 20:36, John Crenshaw johncrens...@priacta.com wrote: 2011/7/28 Frédéric Hardy frederic.ha...@mageekbox.net: Hello ! In PHP 5.4 alpha, an exception is throwing if a subclass of \DirectoryIterator not called the parent constructor. Moreover, this exception can not be catched in the constructor of the subclass. This behavious seems to be a good idea, because \DirectoryIterator may be in an inconsistant state if the parent constructor is not called. But i think that it's not a good idea, because it's a BC break. It's not the case in 5.3 and i have unit test cases which fail by this new behavior, because moked \DirectoryIterator class does not call the parent constructor. In context of unit test, the fact that \DirectoryIterator is inconsistant may be not a problem and can be the desired behavior. I strongly agree. Throwing an exception ONLY because the parent constructor wasn't called is a serious departure from expectations. It is fine for other code in the parent class to fail later due to incomplete/improper initialization which may likely be caused by failure to call the parent constructor earlier, (In fact, that is even expected in many cases) but I cannot conceive of any acceptable reason for the error described here. Even though the change was certainly well intentioned, it clearly didn't account for the possibility of unusual but valid coding situations (such as mocks and other code generation tactics that should be able to reasonably depend on consistent language behaviors). If the constructor MUST be called, then it would seem that you must not be allowed to extend it and instead, have another method which you must use. Badly, beforeConstruct() and/or afterConstruct(), but then we are moving to AOP (which would be nice). Enforcement of the constructor can only be achieved by making it final. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On 25 July 2011 05:34, Gwynne Raskind gwy...@darkrainfall.org wrote:
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is missing initializer, with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).
Index: Zend/zend_API.h
===
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info)
ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)
+#define ZEND_FE_END { NULL, NULL, NULL, 0, 0 }
+
#define ZEND_ARG_INFO(pass_by_ref, name)
{ #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref)
{ NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h
===
--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END
#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N
-- Gwynne
On Sat, Jul 23, 2011 at 19:23, Rasmus Lerdorf syst...@php.net wrote:
On 07/23/2011 04:07 PM, Gwynne Raskind wrote:
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.
As there is also ZEND_NS_FE (I'm not seeing a PHP_NS_FE, due to no
namespaces in PHP ? I think), should there also be ZEND_NS_FE_END (and
for the purist in me PHP_NS_FE and PHP_NS_FE_END).
The only extension I've seen using ZEND_NS_FE is
https://github.com/lstrojny/functional-php.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: hi. We had a discussion about the magic_quotes removal that it is weird that even though that mq was deprecated in 5.3, we still have/had that enabled by default (if you didn't set it from the command line or through a php.ini, the default value which is set from the source by the PHP_INI_ENTRY_* macros). I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. for one thing, this would be less confusing (what do we mean by default? PHP_INI_ENTRY_* or the php.ini? why are they different? etc.), the second thing would be the principle of the fail-secure principle: usually the production settings are more secure and less verbose(display_errors for example). what do you think? of course, if this keeps traction, a proper RFC would be needed, but for now, I'm just throwing ideas. My preference would be to have the defaults be for a production environment. So, if you do absolutely nothing except copy php.exe and a few DLLs, (no ini file), the defaults work to an agreed safe standard. I would envisage that this standard changes over time if weaknesses are found and exploited (I'm not saying there are any). I would then like 1 ini file that only contains specific changes to the defaults for a development environment. I would also like 1 ini file that exactly matches the defaults and that this file must be maintained in line with the internal macros. It would serve as a one stop place to see all the settings as they are defined by the PHP group and could indicate the preference for production and development. So, for a truly lazy developer, it is 1 ini file rename (activate the development environment) and only the agreed entries are amended from the production safe environment, rather than overriding any defaults from the macros, which could have changed and are now out of sync with the INI file. Of course, what is considered safe is for you guys to decide, but with so many settings in the INI files and, as we have seen, disagreement between the internal macros, a little consensus should go a long way to be able to help ISPs and shared hosters have a more uniform standard. Maybe, and this is right of the top of my head, if PHP is installed for a production environment with no INI file, or if an ini file doesn't alter any of the core settings (maybe a separation of INI files for core and extensions?), it could be labelled/considered as a virgin PHP install. Something which could be marketed / advertised. Essentially, the PHP Group agree that for a production environment, these are the settings that are the safest to use. If there are considerations that need to be made for shared hosters, then maybe some mechanism to set these appropriately. So, for a user coming to an ISP and looking at hosting, they can see We use Virgin PHP Settings or something like that and know that they won't be different to a documented standard. Add this labelling to the phpinfo() page and it makes things very very clear what is in play. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new gcov.php.net machine is up
On 23 July 2011 17:16, Antony Dovgal t...@daylessday.org wrote: Thanks Nuno, great job! On 07/23/2011 08:03 PM, Nuno Lopes wrote: Hi, Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net up and running. This new machine is running linux 64 bits, so expect a few differences in the test results. I believe most things are ported from the old machine, including all daemon's configurations. I fired an experimental run of the cron job. Please help me by reporting extensions that are not enabled, daemons that are misconfigured and why (and therefore some tests are failing or skiping), missing valgrind suppressions, and so on. Thanks to Nexcess for offering a new machine to replace the old one. Nuno Excellent work. I see from the recent report that there are a LOT of similar warnings. I'm guessing that those warnings, whilst they are generated on a linux x64 box, would be the same for win32 (and anything else). What sort of policy is needed in addressing casting warnings like this. I get a LOT of warnings about casting of doubles/floats to ints/longs, along with the potential for potential data loss. How feasible is it to aim for a 100% warning free build? I'm not meaning that we should suppress the warnings. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes removal previous patch
On 22 July 2011 12:30, Pierre Joye pierre@gmail.com wrote: patch applied to trunk and 5.4, had to resist not to apply it to 5.3 :D As the great collective once said, Resistance is futile. Surrender to your inner-borg. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
On 22 July 2011 16:17, Alex Howansky alex.howan...@gmail.com wrote:
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo in foo::bar\n;
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo in baz::bar\n;
}
}
$obj = new baz();
$obj-bar();
echo $obj-zoo, \n;
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Thanks,
--
Alex Howansky
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic quotes removal previous patch
On 21 July 2011 10:19, Pierre Joye pierre@gmail.com wrote: hi Pierrick! Thanks for the updated patch :) Now the only question remaining is which level warning we should use for the setter. I'm happy with E_CORE. Objections? Baited breath I've got the champagne on ice ... so long mq! -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Coding for the differences in 5.3 and 5.4 _zend_class_entry structure.
Hi. Just seeing if I can get a small extension upgraded from 5.3 to 5.4 (the pecl/inclued extension). This is my attempt to learn more about internals and hopefully increase my contribution to the project. Prior to doing any work, I'm getting these errors ... ..\pecl\inclued\inclued.c(116) : error C2039: 'filename' : is not a member of '_zend_class_entry' D:\BuildPHP\PHP_5_4\PHP_5_4\Zend\zend.h(462) : see declaration of '_zend_class_entry' ..\pecl\inclued\inclued.c(116) : error C2198: 'add_assoc_string_ex' : too few arguments for call ..\pecl\inclued\inclued.c(117) : error C2039: 'line_start' : is not a member of '_zend_class_entry' D:\BuildPHP\PHP_5_4\PHP_5_4\Zend\zend.h(462) : see declaration of '_zend_class_entry' ..\pecl\inclued\inclued.c(117) : error C2198: 'add_assoc_long_ex' : too few arguments for call ..\pecl\inclued\inclued.c(130) : error C2039: 'filename' : is not a member of '_zend_class_entry' D:\BuildPHP\PHP_5_4\PHP_5_4\Zend\zend.h(462) : see declaration of '_zend_class_entry' ..\pecl\inclued\inclued.c(130) : error C2198: 'add_assoc_string_ex' : too few arguments for call ..\pecl\inclued\inclued.c(131) : error C2039: 'line_start' : is not a member of '_zend_class_entry' D:\BuildPHP\PHP_5_4\PHP_5_4\Zend\zend.h(462) : see declaration of '_zend_class_entry' ..\pecl\inclued\inclued.c(131) : error C2198: 'add_assoc_long_ex' : too few arguments for call So, filename and line_start are missing and should be user.info.filename and info.user.line_start. At this stage, I'm guessing that the add_assoc_string_ex errors are a knock-on effect as I can't see any difference in the macro definitions. So, I assume there has to be a #define to separate ... add_assoc_string_ex(class_entry, filename, sizeof(filename), ce-filename, 1); and add_assoc_string_ex(class_entry, filename, sizeof(filename), ce-info.user.filename, 1); http://svn.php.net/viewvc/pecl/apc/trunk/apc_zend.h?r1=303382r2=303383; introduced a set of macros to cover some of the elements of zend_class_entry, but not for all of the elements of info.user, but contains an adequate pattern to implement the rest of the elements. Adding ... #if ZEND_MODULE_API_NO = 20100409 #define ZEND_ENGINE_2_4 #endif ... #if defined(ZEND_ENGINE_2_4) #define ZEND_CE_FILENAME(ce) (ce)-info.user.filename #define ZEND_CE_LINESTART(ce) (ce)-info.user.line_start #else #define ZEND_CE_FILENAME(ce) (ce)-filename #define ZEND_CE_LINESTART(ce) (ce)-line_start #endif to inclued_zend.h (I don't know if I should put these in inclued_zend.h or php_include.h) and using these macros in inclued.c would be a start, but there are 2 ways I've found of determining the ZEND_ENGINE value. http://lxr.php.net/opengrok/xref/PECL/bcompiler/php_bcompiler.h#54, http://lxr.php.net/opengrok/xref/PECL/apc/apc_php.h#51 (others extensions also use #if ZEND_MODULE_API_NO = 20100409 ...). As several extensions have had to implement these #defines to distinguish between the different zend engine versions, should these level playing field macros be moved (and completed) form the extension to core? OOI. Applying those changes allows inclued.c to compile, but now leaves me with errors in inclued_zend.c. These seem to be similar in issue but relate to the znode structures. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Magic Quotes in PHP, the Finalle
On 19 July 2011 09:57, Reindl Harald h.rei...@thelounge.net wrote: anybody who maintains a server should make a explicit config and not relying on random defaults Consider me told. Amazed that a 2 year old deprecation notice is still outstanding, but told all the same. I think, rather than having production and development, we need best practise. And these ini files only contain the things needed to alter the default settings. Currently, the production and development ini files cover ALL the settings. Consider what has been said about the shared hosters - they don't read stuff to help themselves. They simply install, choose a ini file (maybe) and they're done. Having it so that they have to read ini files, release notes, etc. ... well, fast buck === short cut somewhere. If there was an approved best practice INI file which only covered the changes to the defaults, this would be a fast win for PHP in that we can say that this really is all you need to know about how PHP has moved on in the defaults department. Sure, we used to use magic quotes. Now we don't. Best practice would specifically imply potential BC. Exactly because the position has changed. So, any errors due to an ini setting in the best practice file is a big warning straight away. As it stands : A - Some of the defaults don't get altered anywhere. The defaults work and are carried through to the INI files, making the entries in the INI files redundant and possibly dangerous if PHP then changes the defaults. B - Some of the defaults are overriden based upon environment. That's also fine but if the values are changed in both production and development, then the default is wrong and should be changed to match what is currently being used in the INI filles I suppose it is all about trying to keep the most people happy. The bleeding-edge want safe, secure and fast runtime where the defaults are right and the minimum amount of changes is needed to tune to the environment (sapi and extension mainly I'd say). The hosters want the least number of support issues - so bugger security, let's keep all those bad practices and ini settings. I think a minimal php.ini-best-practice would certainly highlight this to the hosters. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7, upgrade Libpng to 1.2.45
On 19 July 2011 11:25, Pierre Joye pierre@gmail.com wrote: done. And thank you for the update to http://windows.php.net/downloads/php-sdk/deps -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7, upgrade Libpng to 1.2.45
Yep. Got it! I've just tried rebuilding my PHP (5.3 and 5.4). Both getting the same linker error. [snip] xbm.c rc /n /fo Release\php_gd2.dll.res /d FILE_DESCRIPTION=\GD imaging\ /d FILE_NAME=\php_gd2.dll\ /d URL=\http://www.php.net\; /d INTERNAL_NAME=\GD extension\ /d THANKS_GUYS=\Thanks to Rasmus Lerdorf, Stig Bakken, Jim Winstead, Jouni Ahto, Ilia Alshanetsky, Pierre-Alain Joye, Marcus Boerger\ win32\build\template.rc Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. libpng_a.lib(crc32.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance libpng_a.lib(compress.obj) : error LNK2005: _compress already defined in php5.lib(php5.dll) Creating library Release\php_gd2.lib and object Release\php_gd2.exp LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Release\php_gd2.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return code '0x2' Stop. I'm building gd as a shared module. On 19 July 2011 12:07, Pierre Joye pierre@gmail.com wrote: global pkg is not but the standalone one is On Tue, Jul 19, 2011 at 12:59 PM, Richard Quadling rquadl...@gmail.com wrote: On 19 July 2011 11:25, Pierre Joye pierre@gmail.com wrote: done. And thank you for the update to http://windows.php.net/downloads/php-sdk/deps -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7, upgrade Libpng to 1.2.45
Toggling between libpng-1.2.45-vc9-x86.zip and libpng-1.2.46-vc9-x86.zip and 1.2.45 works for me but 1.2.46 doesn't. On 19 July 2011 13:15, Richard Quadling rquadl...@gmail.com wrote: Yep. Got it! I've just tried rebuilding my PHP (5.3 and 5.4). Both getting the same linker error. [snip] xbm.c rc /n /fo Release\php_gd2.dll.res /d FILE_DESCRIPTION=\GD imaging\ /d FILE_NAME=\php_gd2.dll\ /d URL=\http://www.php.net\; /d INTERNAL_NAME=\GD extension\ /d THANKS_GUYS=\Thanks to Rasmus Lerdorf, Stig Bakken, Jim Winstead, Jouni Ahto, Ilia Alshanetsky, Pierre-Alain Joye, Marcus Boerger\ win32\build\template.rc Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. libpng_a.lib(crc32.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance libpng_a.lib(compress.obj) : error LNK2005: _compress already defined in php5.lib(php5.dll) Creating library Release\php_gd2.lib and object Release\php_gd2.exp LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Release\php_gd2.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return code '0x2' Stop. I'm building gd as a shared module. On 19 July 2011 12:07, Pierre Joye pierre@gmail.com wrote: global pkg is not but the standalone one is On Tue, Jul 19, 2011 at 12:59 PM, Richard Quadling rquadl...@gmail.com wrote: On 19 July 2011 11:25, Pierre Joye pierre@gmail.com wrote: done. And thank you for the update to http://windows.php.net/downloads/php-sdk/deps -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.7, upgrade Libpng to 1.2.45
That seems to be linking just fine. Thank you. On 19 July 2011 16:23, Pierre Joye pierre@gmail.com wrote: please try again (fetch the lib again) On Tue, Jul 19, 2011 at 3:42 PM, Richard Quadling rquadl...@gmail.com wrote: Toggling between libpng-1.2.45-vc9-x86.zip and libpng-1.2.46-vc9-x86.zip and 1.2.45 works for me but 1.2.46 doesn't. On 19 July 2011 13:15, Richard Quadling rquadl...@gmail.com wrote: Yep. Got it! I've just tried rebuilding my PHP (5.3 and 5.4). Both getting the same linker error. [snip] xbm.c rc /n /fo Release\php_gd2.dll.res /d FILE_DESCRIPTION=\GD imaging\ /d FILE_NAME=\php_gd2.dll\ /d URL=\http://www.php.net\; /d INTERNAL_NAME=\GD extension\ /d THANKS_GUYS=\Thanks to Rasmus Lerdorf, Stig Bakken, Jim Winstead, Jouni Ahto, Ilia Alshanetsky, Pierre-Alain Joye, Marcus Boerger\ win32\build\template.rc Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. libpng_a.lib(crc32.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance libpng_a.lib(compress.obj) : error LNK2005: _compress already defined in php5.lib(php5.dll) Creating library Release\php_gd2.lib and object Release\php_gd2.exp LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Release\php_gd2.dll : fatal error LNK1169: one or more multiply defined symbols found NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return code '0x2' Stop. I'm building gd as a shared module. On 19 July 2011 12:07, Pierre Joye pierre@gmail.com wrote: global pkg is not but the standalone one is On Tue, Jul 19, 2011 at 12:59 PM, Richard Quadling rquadl...@gmail.com wrote: On 19 July 2011 11:25, Pierre Joye pierre@gmail.com wrote: done. And thank you for the update to http://windows.php.net/downloads/php-sdk/deps -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On 18 July 2011 01:31, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 7/17/11 3:03 PM, Richard Quadling wrote: Why bother having defaults if you don't use them. Err, well, the way PHP ini system works you always have defaults - something is always stored in the hash. My local ini file is 6 lines long. Works perfectly. And you rely on magic_quotes being on, right? Then you have peculiar definition of working perfectly. Currently working really only encompasses running PhD on Windows (new setup for the new home laptop). But, in essence, the inability to rely on one default setting inescapably leads to the inability to rely on any of the defaults. So, the default values are flawed. And therefore relying on them is flawed. So bugger me. So, I _HAVE_ to maintain an INI file that, for the most time, will have the same values as the built-in defaults, but then having to constantly maintain it for every release of PHP, rather than just accepting the defaults. So why bother having defaults at all? Just store NULLS for everything and force all settings to be made via the ini file. Hmmm. Overkill?. So set the default values to appropriate safe/secure values. Hmm. Dev or Production? It would seem that my relying on the default values is my fundamental mistake because the defaults cannot be meaningful for all environments or are counter to the currently perceived best value (magic_quotes is still enabled by default? JHC - why? PHP5.3.0 is nearly 3 years old and yet the default value is still to have them enabled? So the documentation is clearly incorrect. This feature has been DEPRECATED as of PHP 5.3.0.. Nope. The feature is alive and well and if you don't read alter your ini file to go against the current default value you are leaving yourself wide open). A big fuss was made on PHP Classes over the recent announcement of the plan to deprecate ext/myql. One of the issues raised was about shared hosting. Do shared hosters set the INI files a certain way? Do they just rename php.ini-production? Do they just leave things as the default/built-in? Do they care? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Magic Quotes in PHP, the Finalle
On 18 July 2011 16:40, Keloran ava...@gmail.com wrote: personally I'm of the opinion that even 5.4 should actually cause a fatal error, but I know this not going to happen 5.4 throw an E_DEPRECATED, but with this being rolled into E_ALL, it still might get ignored 5.4.1 set default to off 5.4.4 throw an E_WARNING or E_FATAL if turned on Considering the documentation says it was deprecated in 5.3.0, just kill it off. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] 5.4 features vote
On 17 July 2011 02:04, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Stas: Nobody runs PHP with -n, who would you do that? INIs are the recommended setting, if you ignore that, you do it at your own peril. I've seen many servers that run with php.ini files that have only a few lines in them, relying on the defaults for most of the behavior. --Dan Why bother having defaults if you don't use them. My local ini file is 6 lines long. Works perfectly. If I should be setting an option a certain way every time, then the default has to be considered incorrect. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
On 14 July 2011 20:42, Ferenc Kovacs tyr...@gmail.com wrote: To spare the 5.4 features vote thread from the off-topic discussion, we can continue here. Hannes Landeholm brought this idea up, see http://news.php.net/php.internals/53956 and http://news.php.net/php.internals/53959 I would suggest that Hannes create an rfc, and add some examples and introduce the weak references in general and how this can be useful, what problems do they solve (it was discussed in the bugreport, but it wasn't clear as far as I can tell from the comments). Not being an expert here, so the questions may have obvious answers. How often does the gc cycle run during a script? Can preemptive cleanup actually cause more of a headache? In reading about weak references on http://en.wikipedia.org/wiki/Weak_reference, weak references look like a perfect use case for memory limited caches, but I wonder if there would be a way of synching a TTL to the weak referenced objects, so that they essentially automatically expire (or can be expired and expunged). A system controlled TTL for weak referenced objects. So, void SplWeakRef::__construct(object $ref, [int $ttl = -1]) $ttl = -1 would allow the object to be gc'd in the normal way, but any other value would be a hint to how long the object would be expected to last for. If gc happens frequently, then $ttl acts as a limiter and I think this could be very useful. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Outreach Project (Was: Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long)))
On 11 July 2011 09:26, Pierre Joye pierre@gmail.com wrote: On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider j...@horde.org wrote: Try that for String and it reveals a different picture. Horde 3 used that too FWIW. Jan. Even the php5 versions of Horde? That's rather bad given the so strong and loud warnings we gave about using common names w/o namespace, by the time of the date problem. Do we need a sort of out-reach program here? Something that will be more active in announcing the various potential BC changes that are going to happen in PHP? Rather then just having the projects/leaders/developers pull from our various sources, we (as in the PHP group) actively subscribe to THEIR lists/FB/twitter/etc. If this is feasible and supported, I think that any BC we introduce needs to have support to give details on workarounds. In some cases, this could be as simple as renaming a class/function/method/etc. In other cases, more work dependent upon the actual project. I would recommend only pushing of BC info. New features/enhancements/etc. that are non-bc (from our perspective and research), should not be pushed. This means that if I (as a third party developer) get the call from PHP saying We will be breaking classes called string! I really really need to do something about it. It may be a pull list is fine/enough, but I guess we already have these and yet modern projects are still not preparing themselves. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] preg_match
On 8 July 2011 16:31, Mike Robinson m...@rile.ca wrote: On July-08-11 10:01 AM Rafael Dohms wrote: [snip] first time using preg_match is a nightmare. IMHO, preg_match is poetry in motion. Going through a million lines of code replacing ereg[i] with preg_match because it was deprecated in 5.3 - *that* is a nightmare. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Could've used preg_replace_all() ? Maybe? You _are_ a programmer, right? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] getimagesize - return named keys for width, height, type and attributes
On 8 July 2011 17:10, DIXON P. paul.di...@durham.ac.uk wrote: Hi, I've attached a patch ... Rename as .txt to get through the mailing list s/w. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] getimagesize - return named keys for width, height, type and attributes
On 8 July 2011 17:21, DIXON P. paul.di...@durham.ac.uk wrote: Thanks Richard, Renamed and attached. -Original Message- From: Richard Quadling [mailto:rquadl...@gmail.com] Sent: 08 July 2011 17:13 To: DIXON P. Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [PATCH] getimagesize - return named keys for width, height, type and attributes On 8 July 2011 17:10, DIXON P. paul.di...@durham.ac.uk wrote: Hi, I've attached a patch ... Rename as .txt to get through the mailing list s/w. For consistency, should bits and mime become 4 and 5? This would work in the same way as using named capturing in a regex, where you get both the position index and the name in the result array and I think various db_fetch_as_array type functions also. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
2011/7/6 Johannes Schlüter johan...@schlueters.de: On Wed, 2011-07-06 at 16:46 +0100, Richard Quadling wrote: 2011/7/6 Johannes Schlüter johan...@schlueters.de: On Tue, 2011-07-05 at 16:50 +0100, Richard Quadling wrote: C:\php5\php.exe --verbose -f d:\docs\phd\render.php -- --verbose That happens with all options. $ php -n run-tests.php -n You missed out the -- That separates arguments from php.exe and the script. As long as one remembers that, they should be OK. This is not needed usually: $ cat t.php ?php print_r($argv); $ php -n t.php -n Array ( [0] = t.php [1] = -n ) On windows ... copy con C:\t.php ?php print_r($argv); ^Z 1 file(s) copied. php -v PHP 5.3.7RC3-dev (cli) (built: Jul 4 2011 14:05:17) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies C:\PHP5\php.exe -n -f C:\t.php -n Array ( [0] = C:\t.php ) C:\PHP5\php.exe -n -f C:\t.php -- -n Array ( [0] = C:\t.php [1] = -n ) php --help specifically shows this too. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
2011/7/7 Richard Quadling rquadl...@gmail.com: 2011/7/6 Johannes Schlüter johan...@schlueters.de: On Wed, 2011-07-06 at 16:46 +0100, Richard Quadling wrote: 2011/7/6 Johannes Schlüter johan...@schlueters.de: On Tue, 2011-07-05 at 16:50 +0100, Richard Quadling wrote: C:\php5\php.exe --verbose -f d:\docs\phd\render.php -- --verbose That happens with all options. $ php -n run-tests.php -n You missed out the -- That separates arguments from php.exe and the script. As long as one remembers that, they should be OK. This is not needed usually: $ cat t.php ?php print_r($argv); $ php -n t.php -n Array ( [0] = t.php [1] = -n ) On windows ... copy con C:\t.php ?php print_r($argv); ^Z 1 file(s) copied. php -v PHP 5.3.7RC3-dev (cli) (built: Jul 4 2011 14:05:17) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies C:\PHP5\php.exe -n -f C:\t.php -n Array ( [0] = C:\t.php ) C:\PHP5\php.exe -n -f C:\t.php -- -n Array ( [0] = C:\t.php [1] = -n ) php --help specifically shows this too. Aha! C:\PHP5\php.exe -n C:\t.php -n -- -j Array ( [0] = C:\t.php [1] = -n [2] = -- [3] = -j ) Without -f, all arguments after the script name belong to the script. Without -f, argument order becomes important. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
On 6 July 2011 15:14, Mike Robinson m...@rile.ca wrote: On July-06-11 12:58 AM Adam Harvey wrote: On 6 July 2011 06:00, Richard Quadling rquadl...@gmail.com wrote: I'd also add in the display_startup_errors to this also. As I see it, the idea is to make things as noisy or as quiet as possible. Agreed. That was an oversight on my part. I'll update the patches to handle that as well. Nice. I have use for this. Best Regards, Mike Robinson What happens of both LOUD and quiet are used. Personally, I'd say this is an error and abort. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
2011/7/6 Johannes Schlüter johan...@schlueters.de: On Tue, 2011-07-05 at 16:50 +0100, Richard Quadling wrote: C:\php5\php.exe --verbose -f d:\docs\phd\render.php -- --verbose That happens with all options. $ php -n run-tests.php -n You missed out the -- That separates arguments from php.exe and the script. As long as one remembers that, they should be OK. Non bikeshedding thought ... Being able to enable full error reporting at the command line has to be complimented though by fully disabling error reporting ... -Q, --quiet or -S, --silent What would happen with logging then? Will that be switched off, too? If error_reporting() is set to 0, what errors can be generated? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
On 5 July 2011 16:33, Adam Harvey ahar...@php.net wrote: Developers, Romans, countrymen, I'd like to propose the addition of a -W switch to the CLI SAPI which would enable the display of errors and maximum error reporting. This brings us into line with other languages such as Perl, and allows us to evangelise to users that they should run php -W script.php as the preferred way of developing and running new, E_STRICT-compliant scripts. The RFC is at https://wiki.php.net/rfc/cli-strict, and comes with a patch, which is accessible at http://www.adamharvey.name/patches/php-cli-strict.patch.txt. If the response isn't overwhelmingly negative and we don't get caught up in discussions for the next few days, I'll look at calling for a vote in a week or so (given it's not a language-level change). Thanks, Adam Bikesheding thought ... -V, --verbose That could get interesting ... C:\php5\php.exe --verbose -f d:\docs\phd\render.php -- --verbose Non bikeshedding thought ... Being able to enable full error reporting at the command line has to be complimented though by fully disabling error reporting ... -Q, --quiet or -S, --silent Question, ... When does the ini file get read and processed in regards to the command line params? Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] -W option for CLI strict mode
On 5 July 2011 17:22, Adam Harvey ahar...@php.net wrote: On 5 July 2011 23:50, Richard Quadling rquadl...@gmail.com wrote: Non bikeshedding thought ... Being able to enable full error reporting at the command line has to be complimented though by fully disabling error reporting ... -Q, --quiet or -S, --silent Pierre made the same suggestion. It would be easy enough to implement, obviously; I'll put a v1.1 patch up with that included. I'd also add in the display_startup_errors to this also. As I see it, the idea is to make things as noisy or as quiet as possible. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Friendly log messages for CLI server
On 30 June 2011 12:24, Derick Rethans der...@php.net wrote: On Thu, 30 Jun 2011, Johannes Schlüter wrote: On Thu, 2011-06-30 at 07:08 +0200, David Zülke wrote: On 29.06.2011, at 01:19, Johannes Schlüter wrote: On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote: - Colours messages according to their response code (success=green, client error=yellow, server error=red) I would prefer if this would be an ini option (if (cli_web_server.color isatty) color = true) default can be on, but I've seen cases where such magic failed and created hard-to use results (due to control sequences in log files or such). The code could detect if it's outputting to a TTY or not and only use color codes if the output isn't redirected somewhere else. It *is* checking this. And I showed an example (script(1)) where the environment pretends to be a TTY and isn't. My suggestion was to add an ini option in addition to the check. I'm fine with that, but let's leave it set to 1 by default? People with complex requirements can then turn it off if they want to. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php In Windows, there is no default colouring support at the console, so it would make sense if it was off by default. I use a tool called ANSICon which provides the colouring support (http://en.wikipedia.org/wiki/ANSI_escape_code#Support and source+bins at http://adoxa.110mb.com/ansicon/). So, for me turning it on would work for me. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unexpected modification of a variable
On 29 June 2011 15:53, Pascal COURTOIS pascal.court...@nouvo.com wrote:
Hi,
Is there any way that a variable can be changed within a function without
passing it by reference ?
I have a code like that:
function myfunction($var)
{
some code
print_r($var); = prints $var which is an object
anotherfunction($var); // call by value
print_r($var); = $var has changed
}
I thought that since there's no reference in any way to the variable it
cannot be changed in the function. Am I wrong ?
For variables ...
?php
$variable = 'rock';
function paper() {
global $variable;
$variable = __FUNCTION__;
}
function sissors() {
$GLOBALS['variable'] = __FUNCTION__;
}
echo $variable, PHP_EOL;
paper();
echo $variable, PHP_EOL;
sissors();
echo $variable, PHP_EOL;
?
For objects, $var is always an alias to an object identifier which
points to the same object...
http://docs.php.net/manual/en/language.oop5.references.php
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] voting rfc
2011/6/23 Larry Garfield la...@garfieldtech.com: I agree that part is uncomfortably vague. To use me as an example, I've been on this list for a few years, post periodically but not super-frequently, and haven't written any C code for PHP itself. However, I'm one of only two people from the Drupal project I know of on this list. While I'm not the project lead (he isn't on this list), I'm one of the leading developers, such as it is in an amorphous project like Drupal. That probably makes me the closest there is to a Drupal representative to this list, given that Drupal doesn't officialize much of anything. :-) I'm sure there are other projects with a vested interest whose people don't know C well enough to engage in most conversations on this frequently busy list. So... would we get a say or not? :-) --Larry Garfield On 06/21/2011 03:52 PM, Pierre Joye wrote: We thought there was no need to over regulate this part. It is something like mentors, if you just come in, post a couple of times or daily but nobody can second you and you lead zero OSS project, then the chance that you can vote will be rather low. Your option? Contribute! :-) On Tue, Jun 21, 2011 at 5:57 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: That really neads clearing, because if i understand correctly, I should get ability to vote (userland developer activly reading the list and writing to list on some maters). So the question - do i get a vote ability? :-) 21.06.2011 17:36 пользователь Philip Olsonphi...@roshambo.org написал: Whilst it may be democratic to allow 1 person 1 vote, I would honestly hope that my vote, as a non-core developer, would count less then say, Zeev or Rasmus. Simply because my bread and butter is NOT in the core and my understanding of the finer points may (and in all honestly will be) lost to me. Until I can prove to the community a clear understanding and provable technical ability to affect core without completely breaking everything, then it would be unfair to pollute the vote, but my vote should still be recorded at a secondary level. Maybe as an interested party. The main vote has to be amongst those capable of effecting the change. At least in principle by having php-src karma if a major language change or pecl karma for pecl+core related changes. Maybe there should be some different voting criteria, or the ability to create a specific voting criteria per vote. Internal only (something that won't affect userland code - a new memory manager or a significant change in internal mechanisms) Affects PECL (a change in the core that will have an impact on multiple PECL extensions) Userland Change (something that will alter an existing feature - obviously, this could be a BC). Userland Enhancement / New Feature (something that will work in a new version of PHP - possible name collision to existing userland code). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
On 20 June 2011 01:39, Arpad Ray array...@gmail.com wrote:
On Mon, Jun 6, 2011 at 5:31 PM, Richard Quadling rquadl...@gmail.com wrote:
Not an internals expert, but I do have a question.
When would the session handler object be destroyed?
If sessions are being logged to a DB (maybe via a userland PHP class),
is internal reference counting enough to handle the order of
destruction?
If the DB connection is destroyed before the session handler gets it
destructor called (or the session_write_close equivalent), the session
won't be able to log the data and there would be no warning to the
client as engine is in auto tidy up mode.
Hi,
Many thanks for your question, because I hadn't given the matter much
thought. The current patch (#7) uses static methods so it doesn't
change the status quo - the user would need still need to manually
close the session (or register a shutdown function) in order to use an
object in the close() method.
I've spent some time thinking about this and I think we have a couple
of options. First of all I've changed the interface so that the
methods are no longer static, it would already accept an object before
but it would just use it find the class name, and call the methods
statically. Now it only accepts an object.
The two options I've implemented are:
Destructor in the SessionHandler class:
http://spellign.com/patches/php-trunk-session-oo8-destruct.patch
This works ok with some provisions:
- The user's SessionHandler class must hold on to any objects it will
need in close(), (in a property, presumably). While it's possible that
the session handler would still get destructed afterwards, this is the
only way to ensure it.
- If the user overrides __destruct(), they must call parent::__destruct().
Automatically register a shutdown function:
http://spellign.com/patches/php-trunk-session-oo8-shutdown_function.patch
The only argument I can think of against it is that it's possible the
user might, out of habit, register their own shutdown function *after*
calling session_set_save_handler(). In that case their shutdown
function would find the session already closed.
Obviously, if the developer takes care and calls the destructors in
the right order, then everything will be OK, but this is not something
I see very often.
What about circular references and interdependent references?
This would give the destructor option some trouble - in this case
instances are destructed in the order in which they were created, and
it seems likely that the DB object from your example would be created
first.
I prefer the shutdown function option. We could even ensure that the
user's shutdown function always gets called first by adding a separate
hash of internal shutdown functions, however I think that would
overcomplicate matters for something we can clearly document.
The option I haven't mentioned is to preserve the status quo, I think
that would be a pity since we have the chance to address it while
keeping BC now.
I've moved the tests into a separate patch so the above differences are
clearer:
http://spellign.com/patches/php-trunk-session-oo8-tests.patch
Regards,
Arpad
Thanks for looking into this a lot more.
I've always used a First-In-Last-Out (FILO) creation/destruction order
and incorporated the concept of ownership.
Any time an instance of a class is created, it has to be owned by
another instance (of any type) or by a pseudo top-parent. In my case,
I always have an instance of tApp, to which I attach my DB resource
container (invariable I communicate with multiple unlink DB servers)
and a session class (old skool).
tApp is created, DB(s) are linked to. Session is started.
As part of the app destructor, the session is closed first. Always.
Then the DB connectors. For me, during the shutdown of tApp, there is
no more activity to be processed, so the cleanup can take place in a
controlled manner. And the reverse order seems the best way.
And I always call the destructor on tApp as part of my code. A
try{}finally{} clause would certainly be beneficial but probably not
essential.
Hopefully, by the time my script has finished, all resources are
closed and finalised and the script engine shutdown/cleanup cycle is
doing nothing.
Essentially, it is moving the cleanup process into the hands of the
developer. If they don't control the order, I'm not sure you can
predict the order. Or if it can be predicted, it may not be the
desired order.
I think this is a great addition to PHP. I think it needs to be
PHP\SessionHandler. I think all new classes should be namespaced to
PHP, but that's another topic I'm sure.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date_diff broken?
On 17 June 2011 00:51, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I've been looking into various tests and discovered something strange in
date_diff. Example code:
?php
$start = new DateTime('2010-10-04 02:18:48 EDT');
$end = new DateTime('2010-11-06 18:38:28 EDT');
$int = $start-diff($end);
var_dump($start);
As a result of this I'm getting this:
object(DateTime)#1 (3) {
[date]=
string(19) 2010-10-04 06:18:48
[timezone_type]=
int(2)
[timezone]=
string(3) EDT
}
As you can see, the date in $start changed, even though it shouldn't happen.
Looks like it's because of timelib_diff() which has this:
timelib_apply_localtime(one, 0);
timelib_apply_localtime(two, 0);
which converts times in diff arguments to localtime. It then does:
timelib_apply_localtime(one, 1);
timelib_apply_localtime(two, 1);
which is supposed to convert them back, but in fact it does not, since first
conversion seems to have killed TZ information. I'd propose to fix it by
making time_diff operate on copies of one and two instead of real
structures, but maybe somebody has a better idea?
Just ran Stas' script against a lot of 5.3's.
V5.3.0alpha2 : string(19) 2010-10-04 06:18:48
V5.3.0alpha3 : string(19) 2010-10-04 06:18:48
V5.3.0beta1 : string(19) 2010-10-04 06:18:48
V5.3.0RC2 : string(19) 2010-10-04 06:18:48
V5.3.0RC3 : string(19) 2010-10-04 06:18:48
V5.3.0RC4 : string(19) 2010-10-04 06:18:48
V5.3.0 : string(19) 2010-10-04 06:18:48
V5.3.1RC1 : string(19) 2010-10-04 06:18:48
V5.3.1RC2 : string(19) 2010-10-04 06:18:48
V5.3.1RC3 : string(19) 2010-10-04 06:18:48
V5.3.1RC4 : string(19) 2010-10-04 06:18:48
V5.3.1 : string(19) 2010-10-04 06:18:48
V5.3.2RC1 : string(19) 2010-10-04 06:18:48
V5.3.2RC2 : string(19) 2010-10-04 06:18:48
V5.3.2RC3 : string(19) 2010-10-04 06:18:48
V5.3.2 : string(19) 2010-10-04 06:18:48
V5.3.3RC1 : string(19) 2010-10-04 06:18:48
V5.3.3RC2 : string(19) 2010-10-04 06:18:48
V5.3.3RC3 : string(19) 2010-10-04 06:18:48
V5.3.3 : string(19) 2010-10-04 06:18:48
V5.3.4RC1 : string(19) 2010-10-04 06:18:48
V5.3.4RC2 : string(19) 2010-10-04 06:18:48
V5.3.4 : string(19) 2010-10-04 06:18:48
V5.3.5 : string(19) 2010-10-04 06:18:48
V5.3.6RC1 : string(19) 2010-10-04 06:18:48
V5.3.6RC2 : string(19) 2010-10-04 06:18:48
V5.3.6RC3 : string(19) 2010-10-04 06:18:48
V5.3.6 : string(19) 2010-10-04 06:18:48
Even though the behaviour is wrong, it is consistent.
There are no user notes commenting on this issue in the documentation.
Can't check the bug base at the moment due to it being down.
If either of the dates use a TLA timezone (EDT, PST, GMT), rather than
the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 15 June 2011 17:23, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! With pecl/http (DEV-2 branch) and the Functional extension (on github) both creating namespaces within the extension, I think there is a requirement for a mechanism to allow an extension to record the namespace(s) that it has, in a similar fashion to how functions and classes are known to core. There's no such thing as registered namespaces, at least in the engine. Namespace is just a part of class/function name. You could enumerate classes/functions and split their names, but I'm not sure for what such list will be useful. Could you explain? But, trawling all the classes and functions, extracting and aggregating the namespace would really not seem to be the way to go. And that wouldn't take into account the user defined namespaces. Again, there's no such thing as list of user defined namespaces, at runtime. You'd have to go through all classes/functions and split their names. Again, I'm not sure what would be the use of it. Currently, I can find the names of functions, classes and interfaces - be they from an extension or userland code. But I can't get namespaces, or their aliases. I'm not totally sure of any other use. That's why I was asking. As (or if) more extensions start to use namespaces to protect their contents from name collision, we are probably going to have namespace collision before long. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 16 June 2011 14:03, Martin Scotta martinsco...@gmail.com wrote: Martin Scotta On Thu, Jun 16, 2011 at 9:40 AM, Richard Quadling rquadl...@gmail.com wrote: On 15 June 2011 17:23, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! With pecl/http (DEV-2 branch) and the Functional extension (on github) both creating namespaces within the extension, I think there is a requirement for a mechanism to allow an extension to record the namespace(s) that it has, in a similar fashion to how functions and classes are known to core. There's no such thing as registered namespaces, at least in the engine. Namespace is just a part of class/function name. You could enumerate classes/functions and split their names, but I'm not sure for what such list will be useful. Could you explain? But, trawling all the classes and functions, extracting and aggregating the namespace would really not seem to be the way to go. And that wouldn't take into account the user defined namespaces. Again, there's no such thing as list of user defined namespaces, at runtime. You'd have to go through all classes/functions and split their names. Again, I'm not sure what would be the use of it. Currently, I can find the names of functions, classes and interfaces - be they from an extension or userland code. But I can't get namespaces, or their aliases. I'm not totally sure of any other use. That's why I was asking. As (or if) more extensions start to use namespaces to protect their contents from name collision, we are probably going to have namespace collision before long. that's why naming convention are meant for? Maybe, but because of a lack of convention on naming, we have namespaces. It people named their classes/functions/etc with sensible long names, containing something that was unique to their project, after doing plenty of research for similar sounding names, we wouldn't need namespaces. When/if github/functional and/or pecl/http-DEV2 go live, these will be the first 2 namespaces provided by PHP extensions (that could be in general use). Are you all saying that the potential for a naming-collision is negligible? It seems so. As I see it, a namespace is a container. Like a class acts as a container for methods and properties, so a namespaces acts as a container for classes, interfaces and functions, ring-fencing them to avoid name collisions. So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
On 16 June 2011 17:40, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/16/11 8:37 AM, Richard Quadling wrote: Maybe, but because of a lack of convention on naming, we have namespaces. No, we have namespaces not because we couldn't agree on naming convention, but because any naming convention without namespaces would lead to ugly code (which you call sensible long names but which rapidly stop being sensible if you actually try to do it). I was joking. So it would seem appropriate to have the ability to investigate a namespace to see what it contains and/or if it exists. Why? For exactly the same reasons you have class_exists(), interface_exists(), function_exists(). Classes and functions actually exist as objects in the engine. Namespaces do not. They are just parts of names. You can not instantiate a namespace, you can not call a namespace. So these reasons do not apply. And now I understand. Thanks for that. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Getting a list of registered namespaces.
Hi. With pecl/http (DEV-2 branch) and the Functional extension (on github) both creating namespaces within the extension, I think there is a requirement for a mechanism to allow an extension to record the namespace(s) that it has, in a similar fashion to how functions and classes are known to core. On the surface, the namespace seems to be consumed by the class name or function name. ReflectionClass and ReflectionFunciton both have a getNamespaceName() method, but there is no corresponding method for ReflectionExtension, which would need to getNamespaceNames() as an extension could potentially register multiple namespaces - maybe nested ones. In both of these methods, the namespace is simply extracted from the current entity name, but without a way of recording the namespace(s) provided by an extension. I think the following should exist array get_declared_namespaces ( [ bool $categorize = false ] ) Returns the namespaces currently defined. If categorized, the namespaces are categorised by the extension that loads them or with a key of 'user' for user defined namespaces. and array ReflectionExtension::getNamespaces() Returns the namespaces for the extension being reflected. And I think that phpinfo() should output a Registered Namespaces right at the top of the page, alongside the Registered Streams. But, trawling all the classes and functions, extracting and aggregating the namespace would really not seem to be the way to go. And that wouldn't take into account the user defined namespaces. So, (unless I'm mistaken and missing something), an extension needs to record its namespaces somewhere along with userland namespaces. Initially, I thought that putting a pointer to a list in zend_module_entry would be enough to allow the php core code to pick it up from the extension, but that would need to be at a suitable version change rather than mid-cycle. But really, this is out of my depth now. Maybe a mentor/mentee would be useful here. Regards, Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] http://news.php.net/php.cvs/65214 causing win32 compile problems.
Hi. http://news.php.net/php.cvs/65214 Revision: http://svn.php.net/viewvc?view=revisionrevision=312112 Log: - Fixed bug #54624 (class_alias and type hint) Bug: http://bugs.php.net/54624 (Open) class_alias and type hint (II.) is causing me compile issues on Win32... zend_compile.c Zend\zend_compile.c(2583) : error C2143: syntax error : missing ';' before 'type' Zend\zend_compile.c(2584) : error C2143: syntax error : missing ';' before 'type' Zend\zend_compile.c(2587) : error C2065: 'found' : undeclared identifier Zend\zend_compile.c(2587) : error C2065: 'found2' : undeclared identifier Zend\zend_compile.c(2617) : error C2061: syntax error : identifier 'do_inherit_method_check' Zend\zend_compile.c(2617) : error C2059: syntax error : ';' Zend\zend_compile.c(2617) : error C2059: syntax error : 'type' Zend\zend_compile.c(2875) : error C2065: 'do_inherit_method_check' : undeclared identifier Zend\zend_compile.c(2943) : error C2065: 'do_inherit_method_check' : undeclared identifier NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return code '0x2' Dropping back to the previous revision allows the compilation to proceed. I was going to look at the rmtools logs, but they are offline it seems (or the URLs different or I don't have rights). Anyway. Not sure if this is win32 only, but thought that you should know. Regards, Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] SVN Account Request: spankmaster79
On 9 June 2011 15:09, Daniel Brown danbr...@php.net wrote: On Thu, Jun 9, 2011 at 05:38, Sebastian Beyer sebastian.be...@spankomedia.ath.cx wrote: Translating the documentation Into...? If you're undecided, we could use more people on the Klingon translation team. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ My personal fawouwit would be Elmer Fudd. http://www.google.com/webhp?hl=xx-elmer -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 8 June 2011 09:47, Alexey Shein con...@gmail.com wrote:
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
We have the situation in the docs that parameters declared as arrays
do not follow the typehinting rules, but parameters as class names do.
Re-using the callback from the docs could get confusing when
extensions start to typehint on it, but not the core..
I think there is a subtle difference between a callback, and a callable.
In javascript for example, callback is something that is executed on
certain events onsuccess is the typical example.
There is nothing that says the callable parameter gets executed as a
part of an event, and I think the default usecase would be to execute
it right away (f.e. filtering data).
I think I would prefer callable, but I could live with either.
Wikipedia defines callback as a reference to executable code, or a
piece of executable code, that is passed as an argument to other
code. So there's no event meaning put by default, it's just very
often seen callback's usage in javascript.
I just like callback term more :)
An interesting issue here.
Closures, classes with an __invoke method and strings containing
existing function names all pass is_callable() and can be called using
().
But, array('class', 'method') also passes is_callable, but isn't a callback.
http://pastebin.com/Yb5nJ8DB
outputs ...
object is callable
Invoked : Wed, 08 Jun 2011 11:24:09 +0100
object is callable
Closure : Wed, 08 Jun 2011 11:24:09 +0100
string is callable
Wed, 08 Jun 2011 11:24:09 +0100
array is callable
Handling Array via call_user_func
Func array : Wed, 08 Jun 2011 11:24:09 +0100
So, callable and callbacks are 2 different things.
Callable
1 - closures.
2 - classes with an __invoke method.
3 - strings to an existing function.
4 - array('class', 'method')
Callbacks
Only 1, 2 and 3 from the above list.
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-06-08 at 11:27 +0100, Richard Quadling wrote:
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
This is fixed. See thread
From: Felipe Pena felipe...@gmail.com
To: internals internals@lists.php.net
Subject: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Date: Sun, 5 Jun 2011 12:52:45 -0300 (06/ 5/11 05:52:45 PM)
johannes
Thank you.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sites still down?
On 8 June 2011 22:24, Lester Caine les...@lsces.co.uk wrote: What is the current state of play on the sites that were taken down in March. I'm trying to get a clean copy of files from http://pecl2.php.net/downloads/php-windows-builds/php-libs/ Take a look at http://windows.php.net/downloads/php-sdk/ In fact, take a look around http://windows.php.net/downloads. Different bundles of libraries, depending upon what you are building. I've just started building 5.4, so needed new libraries for GD. Thanks to the long suffering Pierre for the URL to this (Pierre, I remembered it ... see). Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 7 June 2011 15:00, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable To avoid another flamewar.. Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? I always thought it was publish and be damned. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Getting integer value for ini entries that support shorthanded sizing.
Hi.
Is there a mechanism to get the memory_limit value rather than the
string when it is set with the K, M or G shorthands.
I can see that ...
PHP_INI_ENTRY(memory_limit, 128M, PHP_INI_ALL, OnChangeMemoryLimit)
...
static PHP_INI_MH(OnChangeMemoryLimit)
{
if (new_value) {
PG(memory_limit) = zend_atol(new_value, new_value_length);
} else {
PG(memory_limit) = 130; /* effectively, no
limit */
}
return zend_set_memory_limit(PG(memory_limit));
}
calls zend_atol - which does the translation.
The value is applied to the PHP Global structure, but the value
retrieved and stored in the ini_entries array from the ini file (the
string 1G for example) is not overwritten.
Would it be worthwhile amending the INI macros so that zend_atol and
zend_atoi (and others if appropriate) where called earlier in the
sequence of events.
That way, ini_get('memory_limit') would return the memory limit in
bytes, rather than the shorthand.
Richard
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
On 3 June 2011 02:18, Arpad Ray array...@gmail.com wrote: Hi, A while ago I submitted a patch to allow session_set_save_handler() to accept a class, and support the inheritance of the default session handler's methods. The RFC has a more detailed description and the current patch: https://wiki.php.net/rfc/session-oo Changes since this was last discussed: - More sanity checking to prevent handlers being called in unexpected states - ZTS fixes Any thoughts? Regards, Arpad Not an internals expert, but I do have a question. When would the session handler object be destroyed? If sessions are being logged to a DB (maybe via a userland PHP class), is internal reference counting enough to handle the order of destruction? If the DB connection is destroyed before the session handler gets it destructor called (or the session_write_close equivalent), the session won't be able to log the data and there would be no warning to the client as engine is in auto tidy up mode. Obviously, if the developer takes care and calls the destructors in the right order, then everything will be OK, but this is not something I see very often. What about circular references and interdependent references? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Enum
On 3 June 2011 08:26, Dennis Haarbrink dhaarbr...@gmail.com wrote:
So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signatures
I'm wondering if the enum storage would work like an array.
The parallel ...
array('YES', 'NO', 'MAYBE') vs. enum{YES, NO, MAYBE}
In this example, all the keys of the array would be the same as the
values of the enum
array(0 = 'YES', 1 = 'NO', 2 = 'MAYBE') vs. enum(YES = 0, NO = 1, MAYBE = 2}
In both cases, there is a name/value pairing. In both cases an
unassigned key (for the array) or value (for the enum) is
automatically determined.
If a non sequential integer value is used ...
array(2047 = 'E_ALL_PRE_5_2', 6143 = 'E_ALL_5_2', 30719 =
'E_ALL_5_3') vs enum{E_ALL_PRE_5_2 = 2047, E_ALL_5_2 = 6143, E_ALL_5_3
= 30719}
then this still follows a recognisable pattern of key/value.
If a non numeric key(array) or value(enum) is used, then I think the
enum{} should follow the existing array() rules.
If a mix is used, then there is already a well documented pattern of
behaviour that I think should be followed.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
On 27 May 2011 08:17, Ferenc Kovacs i...@tyrael.hu wrote: On Fri, May 27, 2011 at 6:10 AM, Scott MacVicar sc...@macvicar.net wrote: On 26 May 2011, at 20:03, Philip Olson phi...@roshambo.org wrote: Hello geeks, A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following: ?php $inf = pow(0, -2); var_dump($inf); // float(INF) var_dump($inf == $inf); // bool(false) var_dump($inf === $inf); // bool(true) ? That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true. Is this is how we want it? And how should this be documented/explained? I think I changes this :-) It didn't make sense that == and === produce different results. Though if someone has a better understanding of maths then we can fix it. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php https://twitter.com/#!/SaraMG/status/73903500198821888 @PhilipOlson If anything it should be: inf==inf, but inf !== inf. After all, not all infinities are the same, but they are all infinite. and I agree with Sara on this one. Tyrael I wonder if INF is really any different to NULL. If null==null null===null, why can't $inf==$inf $inf===$inf php -r var_dump(PHP_VERSION, NF, INF==INF, INF===INF, NULL, NULL==NULL, NULL===NULL); string(9) 5.3.7-dev float(INF) bool(false) bool(true) NULL bool(true) bool(true) I think of NULL and INF as states (no value assigned vs the ultimate value assigned). You can't really determine the value only the nature of the value. And the nature of INF is INF, so INF==INF and INF===INF, just as NULL==NULL and NULL===NULL So, when you compare them, you can't compare the value (in the traditional sense), just the states and the states are the same both, so === should return true. I think 5.4.0-dev has it right. As long as -INF != INF -INF !== INF (which I'm sure is right). Of course, if you come from SQL, any comparison to NULL always fails. Even to other NULLs. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Porting PECL to userspace
On 20 May 2011 17:15, Larry Garfield la...@garfieldtech.com wrote: Hi all. I'm working with a fellow developer on an experimental project. There are some PECL modules that we want to try and use in an open source project where we cannot guarantee that PECL modules will be available, since it's intended for widespread distribution on both shared hosts and custom hosting. The thought we had was to do a user-space port of the PECL module to include in the project and rely on that. Then if the PECL module is installed, we don't include the library (either via an extension_loaded() check or just relying on autoload) and the PECL implementation gets used instead. Poof, nice speed boost. The questions I have are: 1) Is this even a viable approach? It seems like it, but to my knowledge no one else has done this to any serious extent which makes me wonder if there's a reason the road less traveled is less traveled. 2) Is anyone else doing this? No sense doing it ourselves if someone else already is. 3) What would be the cleanest way to do so? We had the thought of partially automating the process by having PHP auto-generate at the very least the subs of any classes and functions that the module provides. However, when my colleague tried using the same parser as is used for generating documentation he says he got several times as many classes as the manual says the module has. We were using the PECL HTTP module as our sample (http://www.php.net/http). (I don't know the exact details of what he did at the moment.) Is that not a viable approach? Would we be better off using reflection? Is there some other tool we're not aware of? If viable I'd love if this would start a trend, but we'll see where it goes. I know it wouldn't work for all PECL modules, obviously, but I suspect it could work for several, and provide an easy way for different PHP projects to share backend code without needing lots of C developers. --Larry Garfield If you using an extension that exists as glue to a third party library, then you are going to need PHP to communicate at a very low level. Something I'm not sure would be possible at the moment. If the extension is self contained, then this would more likely be a good candidate. You can use reflection to build the stubs easily enough But I'm not sure all the things you can do in C can be done in PHP, not without a LOT of effort. Talking to third party libraries or making c calls to the OS is out. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [rmtools][php-5.4] Build error between r and 311062
On 16 May 2011 00:44, Pierre Joye pierre@gmail.com wrote: hi, On Mon, May 16, 2011 at 12:11 AM, Richard Quadling rquadl...@gmail.com wrote: On 15 May 2011 21:37, nore...@php.net wrote: This is an automatic mail from the rmtoool's build bots. New build errors have been introduced between and 311062. The errors are: php-5.4, build ts-windows-vc9-x86: , NMAKE, error, U1077, 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe' : return code '0x2', Full logs are available at (htmlized versions too): http://windows.php.net/downloads/snaps/php-5.4/r311062 With 3,475 warnings in the Win32 x86 VC9 nts build, how do you see the wood for the trees? If the warnings can be ignored, why not suppress them? Ideally almost all could be suppressed. However there are many false positive or cases that can't happen (theoretically). Keeping in mind that this log is the static analyzer logs. Once I got the new machines running, both normal and analyzers log will be published. The key then is to detect the delta between two revisions (should be up soon) and then fix those already. That being said, a warning php has been a sweet from many of us but some devs simply do not want that ;-). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org some devs simply do not want that Why not? I'm guessing the amount of effort required to resolve false positives outweighs the benefit. When I was taught programming, compiler warnings were explained as the compiler telling me that I had not made my intent 100% crystal clear and that the compiler was making a good guess but possibly an incorrect or inappropriate one. Not a bug per se, but just an error in judgement. And when you are compiling across so many different systems, would it not be beneficial to at least re-examine some of these warnings. Just in case ...? Or am I just wasting my time and you all know exactly which warnings are just junk? Are you all that good? Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [rmtools][php-5.4] Build error between r and 311062
On 15 May 2011 21:37, nore...@php.net wrote: This is an automatic mail from the rmtoool's build bots. New build errors have been introduced between and 311062. The errors are: php-5.4, build ts-windows-vc9-x86: , NMAKE, error, U1077, 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe' : return code '0x2', Full logs are available at (htmlized versions too): http://windows.php.net/downloads/snaps/php-5.4/r311062 With 3,475 warnings in the Win32 x86 VC9 nts build, how do you see the wood for the trees? If the warnings can be ignored, why not suppress them? Richard -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 11 May 2011 07:50, dukeofgaming dukeofgam...@gmail.com 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 documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. I'm guessing experience and interpretation is everything here. From reading the Oracle page, to me, it seems annotations ARE documentation. It just depends upon who or what is reading them. The first line of the page ... They have no direct effect on the operation of the code they annotate. In other words, annotations are just like comments. At least in terms of what I understand the compiler does and what the runtime processing does. The use of the @ isn't a fooling (according to Oracle) ... The use of the @ symbol in both Javadoc comments and in annotations is not coincidental—they are related conceptually.. What I can't see from the link is _WHY_ annotations can't just be docblocks? Annotations and comments don't affect the code. Annotations and comments would need to be parsed to read them. I understand that caching of the annotation could be an issue. And this leads to a gap in my knowledge/understanding. Why does _this_ script need to know anything about its annotations? Especially as They have no direct effect on the operation of the code they annotate. It would seem wasteful to process dead data for no purpose in _this_ script. It only seems useful for some sort of external process reading the annotation/comment (say a documentor or a tool to build code for runtime operation). In those cases, these are one offs (ish), so caching would not seem to serve any real benefit here. Whilst I think the syntax of the annotation may be worth discussing, the annotation can surely only exist in a comment, at least with regard to PHP. And I'm guessing that the primary use of annotations within PHP would be in runtime processing, so is this really about the parsing of docblocks. I think using PHP code in a docblock (with the appropriate tag ... @annotation maybe) would cover the requirements. Possibly. Due to phpdocumentor not being updated to handle namespaces yet, annotations are also not going to work correctly there. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
On 9 May 2011 15:44, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. But surely it is a motivational factor to learn C, and have a go at implementing the feature yourself! That's what Open Source is all about. If you don't like the feature, or it is missing one, _DO_ something about it. Saying that the developers are not interested isn't really doing anything. You really can't expect volunteers to simply down tools from family, life, paid work to jump through hoops, attempting to make sense of every user's request. No matter how loud they shout. Now. If you had a pot (and a big pot) of money, then maybe you could sponsor some developers for your pet peeve. I'll take your money. As a volunteer to the PHP project (mainly making an arse of myself in as many places as possible) and a PHP user, I am deeply indebted to all the work undertaken by the core devs. I get paid because of them. Please treat the devs nicely is all I'm really saying. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
On 25 April 2011 11:29, Reindl Harald h.rei...@thelounge.net wrote: nobody says stop selling guns because somebody can shoot in his foot It'd be a place to start though. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On 20 April 2011 15:18, Dave Ingram d...@dmi.me.uk wrote: On 04/19/11 15:44, Michael Morris wrote: watch ($var) - $var is sent to the console on the line this statement is made with the statment now watching 'var'.. init value x, and then each time it changes it is updated in the console. Just my 0.02 as a user, but it strikes me that watch() could be a handy addition that would be difficult and/or extremely painful to do in userland. Dave Being able to watch($var [, ...]), unwatch($var [, ...]) and trace([bool $start = true]) without a debugger in userland ... Just like you can overload session handling logic by using session_set_save_handler(), would something like ... bool debugging_set_handler(callback $watch, callback $unwatch, callback $trace); be of use? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
2011/4/20 Johannes Schlüter johan...@schlueters.de: On 04/20/11 04:18 PM, Dave Ingram wrote: On 04/19/11 15:44, Michael Morris wrote: watch ($var) - $var is sent to the console on the line this statement is made with the statment now watching 'var'.. init value x, and then each time it changes it is updated in the console. Just my 0.02 as a user, but it strikes me that watch() could be a handy addition that would be difficult and/or extremely painful to do in userland. ... but this can be relatively easily be done in a debug extension and that's where this belongs. johannes If the extension could allow for userland interpretation of the debug events ... then I think that's the best of all worlds. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On 17 April 2011 15:51, Mikael Fernandus S mika...@gmail.com wrote: As a non core dev, I would like to say that the patches are so handy and this feature will be so helpful in portable php development scenarios. +1 on this and hoping it will make into the main branch pretty soon. Similar with others, my suggestion is to put the docroot and router script as parts of the options. An option to specify max number of connections would be nice but perhaps it can be in a future wishlist. Regards, Mike On Sun, Apr 17, 2011 at 8:17 AM, Philip Olson phi...@roshambo.org wrote: Greetings Moriyoshi and all, Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet. Also the wiki is up again so: - RFC: https://wiki.php.net/rfc/builtinwebserver - Patch is here: http://gist.github.com/835698 Regards, Philip What would happen if you could combine these patches with the Win32Service pecl extension ... could you not have a real PHP orientated web server running which was capable of starting up and shutting down with the OS. Hey! Who would need IIS or Apache then! (OK. Just kidding). -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On 14 April 2011 09:59, Eloy Bote Falcon eloyb...@gmail.com wrote:
What is the purpose of that generateHash function? It doesn't work in the
isset check.
Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z]) without
notices at all unless any of $x $y or $z are not defined, you don't need to
check the indexes one by one.
2011/4/14 Ole Markus With olemar...@olemarkus.org
On Thu, 14 Apr 2011 02:24:56 +0200, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
I think these shortcuts could be really useful for array elements, but
for other variables I am really sceptical and I think they would do
more harm than good. Generally I do not really see any reason why a
variable should not be 'instanciated' before use.
So
+1 if this shortcut is implemented to only work for array elements.
-1 for any other variable type.
There are two issues here.
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2. Offering a shortcut for the common idiom isset($x) ? $x : $y in
line with the DRY design principle. A notice would never be emitted
here in any case. The problem is that this idiom is still in wide use
despite the shortcut ternary operator already provided, because an
isset() check is different to a boolean cast.
Some thoughts:
- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
not about suppressing notices at all, but about offering a default
value, and the idiom quite probably only uses isset() because it
predated null in the language.
I have never felt the need for a shortcut in these cases. It would be
interesting to see some code where this would be practical.
- If we view 2. in this way, the two problems are independent, and it
seems to me it would be best to solve them independently, rather
than with a single operator.
So, I suggest:
1. An array lookup mechanism that suppresses the notice for undefined
keys. It would work the same as regular array index lookups except
that the notice for undefined keys (and only for undefined keys)
would not be generated (it would not just be hidden, but would never
be even generated).
This is what I feel PHP is missing. Particularly when it comes to
multi-dimensional arrays. Because this feature is missing I tend to do
something like
function generateHash($x, $y, $z)
{
return $x::$y::$z;
}
if (isset($a[generateHash($x, $y, $z)]) {
...
}
instead of
if (isset($a[$x]) isset($a[$x][$y]) isset($a[$x][$y][$z])) {
...
}
Arguing about syntax is then a second step. However, my views on this
are:
I think it best to avoid discussing the actual syntax before agreeing on
what we really need.
--
Ole Markus With
Systems Architect - Sportradar AS
Developer - Gentoo Linux
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
http://news.php.net/php.internals/51877
array_key_exists($key, $array) for arrays
array_key_exists($varname, get_defined_vars()) for locally scoped variables.
No need to use @.
isset() and empty() will not differentiate between an undefined
variable or index and a variable or an array element which is assigned
null.
The E_NOTICE only ever gets fired for the undefined variable/key ...
Notice: Undefined variable
Notice: Undefined index
I think it depends upon the developer's requirement.
Are they attempting to determine the existence of a variable/index
entry or are they attempting to determine if the variable/element is
null.
I always declare my variables. So, I don't want to use isset() as they
will be an incorrect test. I use is_null(). Specifically testing the
value. If I've made a mistake and NOT declared the variable (or made a
typo), I want to know. I don't want to hide it with isset()/empty().
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On 14 April 2011 11:07, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2011 12:02, schrieb Richard Quadling: I always declare my variables. So, I don't want to use isset() as they will be an incorrect test. I use is_null(). Specifically testing the value. If I've made a mistake and NOT declared the variable (or made a typo), I want to know. I don't want to hide it with isset()/empty() yes and no $config['modulename'] = array ( 'icon' = 'bla.gif', 'default_params' = array ( 'autocleanup' = 1, 'ignore_user_abort' = 0, ) ); if 'default_params' are optional you NEED isset() to decide do something with them or skip operations I think that depends upon the developer. I don't mix the tests for existence. Mixing the tests means a typo in the isset() will hide the lack of existence. But array_key_exists() is not going to do that. If the key exists then I can process it. If not, then I can't. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Considering that the main impetus for these threads is to write code
that does not generate the notice regarding missing variables or
indices, neither isset() or empty() will provide that completely.
If a variable is declared, but assigned null, it is not set and it is
empty. But so what. The variable exists and will not generate a notice
if access is attempted. No suppression of the non existent notice is
necessary.
The issue is one of undefined variables and indices. That's what the
E_NOTICE says ...
Notice: Undefined variable
Notice: Undefined index
To directly detect the presence of a key, then array_key_exists() is
the function that covers the requirement.
Global variables are easily detectable using array_key_exists($key, $GLOBALS);
Properties for an object ... property_exists().
For locally scoped variables, the function get_defined_vars() can be
combined with array_key_exists().
But the obvious overhead of having to extract all the variables into a
temp array is probably going to be a performance no-no.
The script below (and in [1] in case the formatting all goes wonky),
demonstrates this.
Ideally, a construct that specifically detects if a variable is
declared, irrespective of its value, would be the perfect solution as
this could be combined with isset() or empty() as the developer needs.
Richard.
[1] http://pastebin.com/qLNYtfAw
?php
error_reporting(-1);
function report($desc, $isset, $empty, $defined) {
return
$desc .
' isset() = ' . ($isset ? 'true ' : 'false') .
' empty() = ' . ($empty ? 'true ' : 'false') .
' defined = ' . ($defined ? 'true ' : 'false') .
PHP_EOL;
}
function tester() {
// $undefined_variable = '';
$defined_variable_null_value = null;
$defined_variable_value = 'non null variable';
$array = array(
// 'undefined_key' = '',
'defined_key_null_value' = null,
'defined_key_value' = 'non null element',
);
$defined_vars = get_defined_vars();
echo
report('Undefined variable ',
isset($undefined_variable),
empty($undefined_variable),
array_key_exists('undefined_variable', $defined_vars)),
report('Defined variable null value ',
isset($defined_variable_null_value),
empty($defined_variable_null_value),
array_key_exists('defined_variable_null_value', $defined_vars)),
report('Defined variable non-null value ',
isset($defined_variable_value),
empty($defined_variable_value),
array_key_exists('defined_variable_value', $defined_vars)),
report('Undefined key ',
isset($array['undefined_key']),
empty($array['undefined_key']),
array_key_exists('undefined_key', $array)),
report('Undefined key null value',
isset($array['defined_key_null_value']),
empty($array['defined_key_null_value']),
array_key_exists('defined_key_null_value', $array)),
report('Undefined key non-null value',
isset($array['defined_key_value']),
empty($array['defined_key_value']),
array_key_exists('defined_key_value', $array));
}
tester();
?
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On 12 April 2011 12:33, Richard Quadling rquadl...@gmail.com wrote: [1] http://pastebin.com/qLNYtfAw Updated to http://pastebin.com/cqSEcGpN to include 0 and '' values. The output is ... Undefined variableisset() = false empty() = true defined = false Defined variable null value isset() = false empty() = true defined = true Defined variable 0isset() = true empty() = true defined = true Defined variable non-null value isset() = true empty() = false defined = true Undefined key isset() = false empty() = true defined = false Undefined key null value isset() = false empty() = true defined = true Undefined key non-null value isset() = true empty() = false defined = true Undefined key 0 value isset() = true empty() = true defined = true Attempting to access any variable where defined = false would be the only place the E_NOTICE is generated. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
