Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
Hi! Here is another example from a real case (Horde_Date) Looks like the case of doing it wrong. In most cases it doesn't even need regexp, in others, generic regexp with post-parsing would probably be more efficient as this seems to do 20+ passes through the string. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update
Hi Terry, I don't have time right now (on this week), but I'll definitely take a look into your patch later. Thanks. Dmitry. On Sat, May 4, 2013 at 5:29 PM, Terry Ellison te...@ellisons.org.uk wrote: Please treat this email by way of request for feedback from the OPcache developers and anyone interested in influencing my next steps on my https://github.com/TerryE/**opcache https://github.com/TerryE/opcachefork of OPcache and specifically on the dev-filecache branch. The most appropriate channel is probably https://github.com/TerryE/**opcache/issueshttps://github.com/TerryE/opcache/issues-- unless you think that the comments have wider applicability for either the PECL or DEV communities. My ultimate aim is to take this to a point where the OPcache developers feel sufficiently comfortable to consider merging a future version back into OPcache. I have added some detailed project wiki pages documenting my scope and progress and in particular on https://github.com/TerryE/** opcache/wiki/MLC-OPcache-**detailshttps://github.com/TerryE/opcache/wiki/MLC-OPcache-detailsand a brief quote from the page: An indication of the potential performance benefits of OPcache CLI mode can be seen from a simple benchmark based on 100 executions of the MediaWiki runJobs.php maintenance batch script. This compiles some 44 PHP sources, comprising 45K lines and 1,312 Kbytes. The cached version reads a single runJobs.cache file of 1,013 Kbytes. Time in mSec Average Stdev Uncached Execution 179 7 Cached Execution77 7 (Image Load Overhead) 18 3 In other words for this script, the MLC cache is delivering an approximate 60% runtime saving. Of course this is only a point test, and benefits will vary -- though I hope that switching to LZ4 compression will improve these figures further. But even this one point challenges what seems to be a core PHP development dogma: there's no point in using a file cache, because it makes no material performance difference. Even this build *does* deliver material benefits , and I suggest that there is merit in moving to including MLC cached modes to accelerate CLI and GCI SAPI modes using this or a similar approach. From an internals -- rather than PECL -- viewpoint what this would mean is that non-cached incremental compile-and-go execution modes would now be the exception than the norm -- largely negating the disadvantages of any compile-intensive optimization options. So thank-you in anticipation for your feedback. I will do my utmost to respond constructively to all comments. :-) Regards Terry Ellison PS. Apologies in advance: I am up country at my cottage on an Island in the north Aegean with the nearest Wifi some walk away, so my Internet access is limited at the moment, and I might take some time to respond.
Re: [PHP-DEV] property de-referencing
Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Well, I don't disagree as such - there's any number of (mostly bad) ways
to work around missing language features...
On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha seva.lap...@gmail.com wrote:
BTW, I didn't propose to wrap any use of a property reference into a meta
object, in this case a certain distinguishable string format could
represent it with no extra handling.
On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Seva,
I understand that you can reference properties more consistently
using {fullClassName}::{fieldName} notation, but it's still a string, and
although it's now almost practically safe to assume that strings formatted
in that way are property-references, it still doesn't address the problem
in a way that is elegant or expressive.
I don't think the Symfony component could have done a much better job
under the circumstances, at least not without the sacrifice of readable
code - typing out new PropertyReference($object, 'User::$name') sure would
be clunky, and not even really safe, since you can't guarantee that the
class-name of $object is known, and in every property-reference, the User
class-reference is now embedded statically in every property-reference, in
the form of a string.
I think this is a good example of those times when PHP developers tend
to look far, far away from Java - as far away as possible - for solutions
that are elegant and a good fit for PHP.
new PropertyReference($object, 'User::$name') contains two static
references too many, to both PropertyReference and User.
As opposed to ^$user-name which contains the minimum amount of required
information - the object and property-name, nothing else.
On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha seva.lap...@gmail.comwrote:
Hi Rasmus,
I agree with you that strings are not the best way to refer to an
element sometimes. However, to me your Symfony2 example only demonstrates
the flaw of the component's design decision, not the limitation of the
language. Sometimes developers (not just Symfony, but other frameworks too)
don't hesitate to use contextless strings to refer to meta-data, because
they underestimate the importance of keeping static referability of static
entities. If they would use conventional full notation of references, e.g.
{fullClassName}::{fieldName} in a string, this would solve your initial
problem (and allow static analyzers which could be aware of the context of
the framework to do their job). This is how these kind of dilemmas are
solved in the world of Java for instance, where property references don't
exist too.
Regards,
Seva
On Tue, Apr 30, 2013 at 6:24 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Any PHP dev who works with a mainstream framework does this daily, but
the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public function getTask()
{
return $this-task;
}
public function setTask($task)
{
$this-task = $task;
}
public function getDueDate()
{
return $this-dueDate;
}
public function setDueDate(\DateTime $dueDate = null)
{
$this-dueDate = $dueDate;
}
}
$form = $this-createFormBuilder($task)
-add('task', 'text')
-add('dueDate', 'date')
-getForm();
In this example, 'task' and 'dueDate' are property-references - except
of
course that, no, they're not - they're obviously just strings...
rewriting
this example to use a (fictive) form builder API with static
property-references:
$form = $this-createFormBuilder()
-add(^$task-task, 'text')
-add(^$task-dueDate, 'date')
-getForm();
We now have static property-references, which means the codebase can be
proofed using static analysis, which also means better IDE support with
property auto-completion, inline documentation, and automatic
refactoring
for operations like renaming properties, etc.
Note that $task need not be passed to createFormBuilder() anymore -
instead, we can now use PropertyReference::getObject() inside the
form-builder to obtain the instance.
For that matter, we can now scrap the form-builder entirely and
introduce a
simple form-helper in the view instead:
Task name: ?= $form-textInput(^$task-task) ?
Due Date: ?= $form-dateInput(^$task-dueDate) ?
This is even better, because we now have the same level of IDE support
and
static analysis for textInput() and dateInput() which were
Re: [PHP-DEV] property de-referencing
And what do good developers do when the best ways have long since been
identified - and the limitations of the language prevents them from
implementing any new ideas?
I have hundreds of PHP experiments collected in a sandbox over the years -
a good way to build and handle web-forms is one of the last things I have
not found a satisfying solution to, and I am not happy with what anybody
else has come up with either. At some point, it's natural to start asking
why, comparing to other languages, etc. - short of inventing DSLs, I have
not seen much that really impresses me.
I don't know, maybe I should just let that one go and accept that it's
always going to be crap. Maybe the problem in the first place is trying to
drive the client-side from the server-side, and maybe client-side
frameworks is the right way to go - put the UI abstraction in the UI rather
than on the server. We'll always need a few web-forms, I think, but maybe
it's time to stop struggling for better server-side form handling and start
moving towards fully client-side UI...
(sorry if I'm going off on a tangent here - just sharing some of the
thoughts that lead me down this path to begin with...)
On Tue, May 7, 2013 at 9:41 AM, Seva Lapsha seva.lap...@gmail.com wrote:
Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Well, I don't disagree as such - there's any number of (mostly bad) ways
to work around missing language features...
On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha seva.lap...@gmail.comwrote:
BTW, I didn't propose to wrap any use of a property reference into a
meta object, in this case a certain distinguishable string format could
represent it with no extra handling.
On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Seva,
I understand that you can reference properties more consistently
using {fullClassName}::{fieldName} notation, but it's still a string, and
although it's now almost practically safe to assume that strings formatted
in that way are property-references, it still doesn't address the problem
in a way that is elegant or expressive.
I don't think the Symfony component could have done a much better job
under the circumstances, at least not without the sacrifice of readable
code - typing out new PropertyReference($object, 'User::$name') sure would
be clunky, and not even really safe, since you can't guarantee that the
class-name of $object is known, and in every property-reference, the User
class-reference is now embedded statically in every property-reference, in
the form of a string.
I think this is a good example of those times when PHP developers tend
to look far, far away from Java - as far away as possible - for solutions
that are elegant and a good fit for PHP.
new PropertyReference($object, 'User::$name') contains two static
references too many, to both PropertyReference and User.
As opposed to ^$user-name which contains the minimum amount of
required information - the object and property-name, nothing else.
On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha seva.lap...@gmail.comwrote:
Hi Rasmus,
I agree with you that strings are not the best way to refer to an
element sometimes. However, to me your Symfony2 example only demonstrates
the flaw of the component's design decision, not the limitation of the
language. Sometimes developers (not just Symfony, but other frameworks
too)
don't hesitate to use contextless strings to refer to meta-data, because
they underestimate the importance of keeping static referability of static
entities. If they would use conventional full notation of references, e.g.
{fullClassName}::{fieldName} in a string, this would solve your initial
problem (and allow static analyzers which could be aware of the context of
the framework to do their job). This is how these kind of dilemmas are
solved in the world of Java for instance, where property references don't
exist too.
Regards,
Seva
On Tue, Apr 30, 2013 at 6:24 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Any PHP dev who works with a mainstream framework does this daily,
but the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public function getTask()
{
return $this-task;
}
public function setTask($task)
{
$this-task = $task;
}
public function getDueDate()
{
return $this-dueDate;
}
public function setDueDate(\DateTime $dueDate = null)
{
$this-dueDate = $dueDate;
}
}
$form = $this-createFormBuilder($task)
-add('task',
Re: [PHP-DEV] property de-referencing
Maybe PHP is just not for you. There are other languages in the sea :)
On Tue, May 7, 2013 at 10:32 AM, Rasmus Schultz ras...@mindplay.dk wrote:
And what do good developers do when the best ways have long since been
identified - and the limitations of the language prevents them from
implementing any new ideas?
I have hundreds of PHP experiments collected in a sandbox over the years -
a good way to build and handle web-forms is one of the last things I have
not found a satisfying solution to, and I am not happy with what anybody
else has come up with either. At some point, it's natural to start asking
why, comparing to other languages, etc. - short of inventing DSLs, I have
not seen much that really impresses me.
I don't know, maybe I should just let that one go and accept that it's
always going to be crap. Maybe the problem in the first place is trying to
drive the client-side from the server-side, and maybe client-side
frameworks is the right way to go - put the UI abstraction in the UI rather
than on the server. We'll always need a few web-forms, I think, but maybe
it's time to stop struggling for better server-side form handling and start
moving towards fully client-side UI...
(sorry if I'm going off on a tangent here - just sharing some of the
thoughts that lead me down this path to begin with...)
On Tue, May 7, 2013 at 9:41 AM, Seva Lapsha seva.lap...@gmail.com wrote:
Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Well, I don't disagree as such - there's any number of (mostly bad) ways
to work around missing language features...
On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha seva.lap...@gmail.comwrote:
BTW, I didn't propose to wrap any use of a property reference into a
meta object, in this case a certain distinguishable string format could
represent it with no extra handling.
On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Seva,
I understand that you can reference properties more consistently
using {fullClassName}::{fieldName} notation, but it's still a string,
and
although it's now almost practically safe to assume that strings formatted
in that way are property-references, it still doesn't address the problem
in a way that is elegant or expressive.
I don't think the Symfony component could have done a much better job
under the circumstances, at least not without the sacrifice of readable
code - typing out new PropertyReference($object, 'User::$name') sure would
be clunky, and not even really safe, since you can't guarantee that the
class-name of $object is known, and in every property-reference, the User
class-reference is now embedded statically in every property-reference, in
the form of a string.
I think this is a good example of those times when PHP developers tend
to look far, far away from Java - as far away as possible - for solutions
that are elegant and a good fit for PHP.
new PropertyReference($object, 'User::$name') contains two static
references too many, to both PropertyReference and User.
As opposed to ^$user-name which contains the minimum amount of
required information - the object and property-name, nothing else.
On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha seva.lap...@gmail.comwrote:
Hi Rasmus,
I agree with you that strings are not the best way to refer to an
element sometimes. However, to me your Symfony2 example only demonstrates
the flaw of the component's design decision, not the limitation of the
language. Sometimes developers (not just Symfony, but other frameworks
too)
don't hesitate to use contextless strings to refer to meta-data, because
they underestimate the importance of keeping static referability of
static
entities. If they would use conventional full notation of references,
e.g.
{fullClassName}::{fieldName} in a string, this would solve your initial
problem (and allow static analyzers which could be aware of the context
of
the framework to do their job). This is how these kind of dilemmas are
solved in the world of Java for instance, where property references don't
exist too.
Regards,
Seva
On Tue, Apr 30, 2013 at 6:24 PM, Rasmus Schultz
ras...@mindplay.dkwrote:
Any PHP dev who works with a mainstream framework does this daily,
but the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public function getTask()
{
return $this-task;
}
public function setTask($task)
{
$this-task = $task;
}
public function getDueDate()
{
return $this-dueDate;
}
public function setDueDate(\DateTime
Re: [PHP-DEV] property de-referencing
I have tried tons of other languages, actively watching at least a few
others in the hopes they'll mature - but I keep coming back to PHP for some
reason.
It's an abusive relationship. Maybe I should seek counseling ;-)
On Tue, May 7, 2013 at 11:15 AM, Seva Lapsha seva.lap...@gmail.com wrote:
Maybe PHP is just not for you. There are other languages in the sea :)
On Tue, May 7, 2013 at 10:32 AM, Rasmus Schultz ras...@mindplay.dkwrote:
And what do good developers do when the best ways have long since been
identified - and the limitations of the language prevents them from
implementing any new ideas?
I have hundreds of PHP experiments collected in a sandbox over the years
- a good way to build and handle web-forms is one of the last things I have
not found a satisfying solution to, and I am not happy with what anybody
else has come up with either. At some point, it's natural to start asking
why, comparing to other languages, etc. - short of inventing DSLs, I have
not seen much that really impresses me.
I don't know, maybe I should just let that one go and accept that it's
always going to be crap. Maybe the problem in the first place is trying to
drive the client-side from the server-side, and maybe client-side
frameworks is the right way to go - put the UI abstraction in the UI rather
than on the server. We'll always need a few web-forms, I think, but maybe
it's time to stop struggling for better server-side form handling and start
moving towards fully client-side UI...
(sorry if I'm going off on a tangent here - just sharing some of the
thoughts that lead me down this path to begin with...)
On Tue, May 7, 2013 at 9:41 AM, Seva Lapsha seva.lap...@gmail.comwrote:
Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Well, I don't disagree as such - there's any number of (mostly bad)
ways to work around missing language features...
On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha seva.lap...@gmail.comwrote:
BTW, I didn't propose to wrap any use of a property reference into a
meta object, in this case a certain distinguishable string format could
represent it with no extra handling.
On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Seva,
I understand that you can reference properties more consistently
using {fullClassName}::{fieldName} notation, but it's still a string,
and
although it's now almost practically safe to assume that strings
formatted
in that way are property-references, it still doesn't address the problem
in a way that is elegant or expressive.
I don't think the Symfony component could have done a much better job
under the circumstances, at least not without the sacrifice of readable
code - typing out new PropertyReference($object, 'User::$name') sure
would
be clunky, and not even really safe, since you can't guarantee that the
class-name of $object is known, and in every property-reference, the User
class-reference is now embedded statically in every property-reference,
in
the form of a string.
I think this is a good example of those times when PHP developers
tend to look far, far away from Java - as far away as possible - for
solutions that are elegant and a good fit for PHP.
new PropertyReference($object, 'User::$name') contains two static
references too many, to both PropertyReference and User.
As opposed to ^$user-name which contains the minimum amount of
required information - the object and property-name, nothing else.
On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha
seva.lap...@gmail.comwrote:
Hi Rasmus,
I agree with you that strings are not the best way to refer to an
element sometimes. However, to me your Symfony2 example only
demonstrates
the flaw of the component's design decision, not the limitation of the
language. Sometimes developers (not just Symfony, but other frameworks
too)
don't hesitate to use contextless strings to refer to meta-data, because
they underestimate the importance of keeping static referability of
static
entities. If they would use conventional full notation of references,
e.g.
{fullClassName}::{fieldName} in a string, this would solve your
initial
problem (and allow static analyzers which could be aware of the context
of
the framework to do their job). This is how these kind of dilemmas are
solved in the world of Java for instance, where property references
don't
exist too.
Regards,
Seva
On Tue, Apr 30, 2013 at 6:24 PM, Rasmus Schultz
ras...@mindplay.dkwrote:
Any PHP dev who works with a mainstream framework does this daily,
but the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public function getTask()
{
Re: [PHP-DEV] property de-referencing
I am really surprised that there is so few people interested in such a
feature. IMO, it's an amazing idea, not just for forms, and not just for
properties.
Here is a quick list of use cases where one would use meta on its code:
- Forms generation (examples have already been given)
- ORM mapping (Doctrine for example)
- DTO mapping (mapping some objects to other objects/data structures)
- Dependency Injection configuration (defining dependencies)
- Routing (mapping routes to controller class methods)
- AOP
- …
Another example: the PropertyAccess component of Symfony
(http://symfony.com/blog/new-in-symfony-2-2-new-propertyaccess-component).
Here is what we can use today for doing some meta:
- string references (PHP strings, XML, YAML…)
- annotations
If you have worked with ZF, Symfony, Doctrine, … you know that working
with strings make refactoring, code completion and static analysis very
difficult!
In modern frameworks, there are more and more annotations and config
files, and that's a sign IMO: that's a sign that we do a lot of meta.
And having a language feature for doing that (as an alternative, not a
replacement for current solutions) would be amazing.
Here are some examples with some random syntax (probably problematic but
that's not the point) to illustrate:
// Property
$propertyReference = ^$article-name; // returns a PropertyReference
$propertyReflection = ^My\Article::name // returns a ReflectionProperty
// Method
$methodReference = ^$article-getName(); // returns a MethodReference
$methodReflection = ^My\Article::getName(); // returns a ReflectionMethod
// Form generation
$form-addInput(^$article-name);
// ORM mapping
$class-mapField(^Article::name, 'string');
// DTO mapping
$mapper-map(^$article-name, ^ArticleDTO::label);
// DI configuration
$container-bind(^My\ServiceInterface)
-to(^My\Service)
-withSetter(^My\Service::setFoo(), ^My\Foo);
// Routing
$app-get('/hello/{name}', ^$myController-helloAction());
// AOP
$aop-beforeMethod(^$myObject-someMethod(), function() {
echo Hello World!;
});
In all those examples, you can refactor your code, find usages of
properties, traverse call hierarchy, have 100% code completion, have
better code analysis…
PS: please please don't mind the syntax of the examples, let's keep the
discussion on the idea for now.
Le 07/05/2013 16:32, Rasmus Schultz a écrit :
And what do good developers do when the best ways have long since been
identified - and the limitations of the language prevents them from
implementing any new ideas?
I have hundreds of PHP experiments collected in a sandbox over the years -
a good way to build and handle web-forms is one of the last things I have
not found a satisfying solution to, and I am not happy with what anybody
else has come up with either. At some point, it's natural to start asking
why, comparing to other languages, etc. - short of inventing DSLs, I have
not seen much that really impresses me.
I don't know, maybe I should just let that one go and accept that it's
always going to be crap. Maybe the problem in the first place is trying to
drive the client-side from the server-side, and maybe client-side
frameworks is the right way to go - put the UI abstraction in the UI rather
than on the server. We'll always need a few web-forms, I think, but maybe
it's time to stop struggling for better server-side form handling and start
moving towards fully client-side UI...
(sorry if I'm going off on a tangent here - just sharing some of the
thoughts that lead me down this path to begin with...)
On Tue, May 7, 2013 at 9:41 AM, Seva Lapsha seva.lap...@gmail.com wrote:
Good developers research and find *best* ways to use the available tools
before inventing new ones.
On Mon, May 6, 2013 at 2:46 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Well, I don't disagree as such - there's any number of (mostly bad) ways
to work around missing language features...
On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha seva.lap...@gmail.comwrote:
BTW, I didn't propose to wrap any use of a property reference into a
meta object, in this case a certain distinguishable string format could
represent it with no extra handling.
On Mon, May 6, 2013 at 12:44 PM, Rasmus Schultz ras...@mindplay.dkwrote:
Seva,
I understand that you can reference properties more consistently
using {fullClassName}::{fieldName} notation, but it's still a string, and
although it's now almost practically safe to assume that strings formatted
in that way are property-references, it still doesn't address the problem
in a way that is elegant or expressive.
I don't think the Symfony component could have done a much better job
under the circumstances, at least not without the sacrifice of readable
code - typing out new PropertyReference($object, 'User::$name') sure would
be clunky, and not even really safe, since you can't guarantee that the
class-name of $object is known, and in every property-reference, the User
class-reference is
Re: [PHP-DEV] property de-referencing
I am really surprised that there is so few people interested in such a feature. IMO, it's an amazing idea, not just for forms, and not just for properties. It's not that the idea isn't useful; I just don't think I need a dedicated syntax for it. If we're going to be adding syntax I'd much rather see some other things done.
[PHP-DEV] idea: letting the line number and file name be set via user_error
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
[PHP-DEV] idea: implement a Comparable interface
It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain for
the execution.
I think that this is a sensible default, and allowing to fake that from the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] idea: implement a Comparable interface
It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. There is nothing stopping you from creating this in user-land. Also, I have spent a lot of time writing libraries in PHP and I now believe that this approach is not the best solution anyway.
Re: [PHP-DEV] idea: implement a Comparable interface
It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. There is nothing stopping you from creating this in user-land. Also, I have spent a lot of time writing libraries in PHP and I now believe that this approach is not the best solution anyway. Except for the magic that happens on the comparison, I mean. I really don't think PHP should go down that road at this point, if ever.
Re: [PHP-DEV] Continued try blocks
The feature exists in Python: http://stackoverflow.com/questions/574730/python-how-to-ignore-an-exception-and-proceed, in Ruby: http://stackoverflow.com/questions/5089802/which-is-the-shortest-way-to-silently-ignore-a-ruby-exception. Just saying. On Wed, May 1, 2013 at 4:46 AM, Patrick ALLAERT patrickalla...@php.netwrote: 2013/4/30 Pierre Joye pierre@gmail.com: hi, On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote: You may have a lib/object/chunk of code which raises exceptions, because its developer thought some error is not recoverable; but when you use it, you don't want to break your program's execution. That's why you have try/catch. Exactly, I cannot agree more here. This proposal brings yet again exceptions for control flow, which is really not what they are designed for (no matter the language, or almost all languages). An exception can be handled and the program can continue? Catch it, any other tricks bring control flow using exception and that's really a bad idea. I'm quite opposed to changing try/catch flow with this additions for the same reasons that Stas and Pierre mentioned. Especially since this can perfectly be achieved without it and a few more ifs/whiles/gotos. There no need to have a gentle/nice-to-have syntax to handle the cases of libraries abusing exceptions. Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain for
the execution.
I think that this is a sensible default, and allowing to fake that from the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates from.
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I think you should be able to track down the error source without manipulating
any library code in the best case (yeah, there exist Exceptions (there you can
add a backtrace) too, but you have to catch them, if not your script will
abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at [line:file]
and output the string myself (via fwrite to STDERR). I don't think that this is
the right way, this seems to me more like a temporary solution.
Please change there something that makes it easier to debug trigger_error's
notices. (But I don't know if only adding a third parameter to trigger_error is
enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Continued try blocks
Hi!
The feature exists in
Python:
http://stackoverflow.com/questions/574730/python-how-to-ignore-an-exception-and-proceed,
I don't think it does what is proposed - except/pass just catches an
exception and does nothing, it does not return in the place where
exception was thrown down the stack and continues execution.
Looks like Ruby is the same thing. In PHP you'd just do:
try {
dostuff();
} catch(Exception $e) {}
but that's not what was proposed.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: implement a Comparable interface
On 7 May 2013 09:17, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. I wrote https://wiki.php.net/rfc/comparable a couple of years ago — there's a patch there that would probably still apply without too much work to master. About the only difference was that I didn't double underscore the magic method (in line with both Java and PHP interfaces like Countable). I ended up withdrawing it because the response at the time was somewhere between meh and outright hostility; I didn't see much point devoting time to something that was going to fail a vote regardless. It could be dusted off and reproposed for 5.6 if there was enough interest, but my guess is that it'd still be an uphill battle (even though some internal classes, most notably DateTime, do exactly this). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: implement a Comparable interface
On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. Nikita
Re: [PHP-DEV] idea: implement a Comparable interface
Its kinda useless feature for PHP. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Nikita Popov nikita@gmail.com On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. Nikita
Re: [PHP-DEV] idea: implement a Comparable interface
Classes without the ability to overload the comparison operator could be considered kinda useless as well. On Tue, May 7, 2013 at 11:11 AM, Daniel Ribeiro drgom...@gmail.com wrote: Its kinda useless feature for PHP. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Nikita Popov nikita@gmail.com On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. Nikita
Re: [PHP-DEV] Scalar Type Casting Magic Methods
On Sat, May 4, 2013 at 5:31 PM, Oleku Konko oleku.ko...@yahoo.com wrote: Quick Observations : I had this issue ( http://stackoverflow.com/questions/16375331/increment-on-tostring ) and it kept me thinking why no error was returned, then i stumble up this RFC : https://wiki.php.net/rfc/object_cast_to_types The patch is basic , simple and working and it should be seriously considered in 5.5. I want to believe if https://github.com/php/php-src/pull/334 can make it to PHP 5.5 then we should give object_cast_to_types the same opportunity except they are string objections why it should not be so I don't think that this would be particularly useful and as such I don't think we need it. The idea of doing some meaningful operation when writing $obj + 1 is nice, but only if you have actual operator overloading and can compute the result of that expression yourself. If you don't have this possibility and only get to cast $a to an integer/float, then the whole thing becomes rather useless. The only thing it could be used for are thin wrappers around integers/floats and I don't see why one would want to do such a thing (especially as you get back a number and *not* a wrapper object). Thus, __toScalar(), __toInt(), __toFloat() seem pretty useless. The only thing that might have some merit is __toArray(). But there again, I'm not really sure what it gives us. After all we already have Traversable and ArrayAccess, so we can already make an object behave pretty much like an array. Nikita
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@gmail.com
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
Something I don't understand: You call test() in line 7 and line triggers
the error, so in fact it is _really_ line 3, that causes the message. So
why should it display line 7, when it is obvious the wrong line?
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com
wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie.
the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file
name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain
for
the execution.
I think that this is a sensible default, and allowing to fake that from
the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that
there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you
will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist
Exceptions (there you can add a backtrace) too, but you have to catch them,
if not your script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug
trigger_error's notices. (But I don't know if only adding a third parameter
to trigger_error is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] idea: implement a Comparable interface
I proposed something similar recently in the PHP-FIG group, but decided that without the language-level ability to overload comparison operators, standardizing comparables ony using methods was not very useful. If PHP could provide a magic method for comparison that involved being able to use comparison operators, I think this feature would be really useful. An example that comes to mind is a Money class: $pesos = new Money(200, Money::PESO); $dollars = new Money(100, Money::US_DOLLAR); var_dump($pesos $dollars); Then, the Money class could take care of normalizing and comparing the values. Food for thought... -- Jake On May 7, 2013, at 1:15 PM, Stuart Langley slang...@google.com wrote: Classes without the ability to overload the comparison operator could be considered kinda useless as well. On Tue, May 7, 2013 at 11:11 AM, Daniel Ribeiro drgom...@gmail.com wrote: Its kinda useless feature for PHP. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Nikita Popov nikita@gmail.com On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain for
the execution.
I think that this is a sensible default, and allowing to fake that from the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal
functions of the framework I don't want to know about, so that I cannot imagine
instantly what's going on?
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than with
xDebug. With gdb it's only setting a break into the trigger_error function and
then use zbacktrace... But for debugging on some production system because only
there something goes wrong for some reason, I wouldn't want to install xDebug
(which will be loaded at every request...).
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist Exceptions
(there you can add a backtrace) too, but you have to catch them, if not your
script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug trigger_error's
notices. (But I don't know if only adding a third parameter to trigger_error
is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Bob
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs krebs@gmail.com wrote:
2013/5/7 Thomas Anderson zeln...@gmail.com
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
Something I don't understand: You call test() in line 7 and line triggers
the error, so in fact it is _really_ line 3, that causes the message. So
why should it display line 7, when it is obvious the wrong line?
I thought half the point of OOP was to abstract away the internals and as
is the error messages don't make much sense unless you *do* consider the
internals.
Like let's say you have a bignum library and you're doing
$fifteen-divide($zero) on line 5 of test.php. Seems to me that it'd be
more useful to say error: division by zero on line 5 of test.php instead
of line line xx of file yy. It's like...
ooh - let me try to find where I'm doing division by zero. Let me to line
xx of file yy that I didn't even write and don't know a thing about. ok...
so it looks like that's in the private _helper_function(). And
_helper_function() is called by 15x other public functions. I give up!
As an end user of a library you shouldn't have to actually look into that
library if you're the one who's not properly handling something.
Re: [PHP-DEV] idea: implement a Comparable interface
On Tue, May 7, 2013 at 1:05 PM, Nikita Popov nikita@gmail.com wrote: On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. bignum PHP class: http://phpseclib.sourceforge.net/math/intro.html Per the benchmarks it's internal implementation (without OpenSSL) is faster than BCMath is in 5.4 lol. Not sure which OS the test was ran on. That's the only use case I can come up with off the top of my head but that's more than I can come up with for Iterator atm lol.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On 7 May 2013 12:24, Thomas Anderson zeln...@gmail.com wrote: I thought half the point of OOP was to abstract away the internals and as is the error messages don't make much sense unless you *do* consider the internals. Like let's say you have a bignum library and you're doing $fifteen-divide($zero) on line 5 of test.php. Seems to me that it'd be more useful to say error: division by zero on line 5 of test.php instead of line line xx of file yy. It's like... ooh - let me try to find where I'm doing division by zero. Let me to line xx of file yy that I didn't even write and don't know a thing about. ok... so it looks like that's in the private _helper_function(). And _helper_function() is called by 15x other public functions. I give up! Sure, but in practice, that's why most development environments provide backtraces on error or uncaught exception, whether through something like XDebug or via a call to debug_print_backtrace() in the error/exception handler. That gives you both the specific information you want (the last file and line of non-library code that called into the erroneous function(s)) and all the additional context you might need. As Ferenc said, I also don't understand how you'd get the fake file and line numbers for the trigger_error() call without guesswork or going back up through the backtrace anyway, which is something that doesn't belong in non-handler code, IMO. As an end user of a library you shouldn't have to actually look into that library if you're the one who's not properly handling something. I agree, but this is already a solved problem in PHP. All the tools needed are there. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@gmail.com
On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs krebs@gmail.comwrote:
2013/5/7 Thomas Anderson zeln...@gmail.com
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
Something I don't understand: You call test() in line 7 and line triggers
the error, so in fact it is _really_ line 3, that causes the message. So
why should it display line 7, when it is obvious the wrong line?
I thought half the point of OOP was to abstract away the internals and as
is the error messages don't make much sense unless you *do* consider the
internals.
Part of OOP are Exceptions.
Like let's say you have a bignum library and you're doing
$fifteen-divide($zero) on line 5 of test.php. Seems to me that it'd be
more useful to say error: division by zero on line 5 of test.php instead
of line line xx of file yy. It's like...
Somebody else already mentioned, that he wants to trigger notices at first,
but here the application is broken. So (see above) Exception is more
apropriate.
ooh - let me try to find where I'm doing division by zero. Let me to line
xx of file yy that I didn't even write and don't know a thing about. ok...
so it looks like that's in the private _helper_function(). And
_helper_function() is called by 15x other public functions. I give up!
You should have validated the input parameters before every of the 15 calls.
As an end user of a library you shouldn't have to actually look into that
library if you're the one who's not properly handling something.
In an ideal world you are propably right, but this is rarely
possible/useful.
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com
wrote:
If you do user_error('whatever') it'll show, as the line number for
that
error, the line number on which that user_error() call is made. It'd
be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie.
the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file
name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain
for
the execution.
I think that this is a sensible default, and allowing to fake that from
the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that
there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line
numbers.
You would either need to hardcode those in your application and make
sure
that the reference and the actual content of your file is in sync (you
will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal
functions of the framework I don't want to know about, so that I cannot
imagine instantly what's going on?
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than
with xDebug. With gdb it's only setting a break into the trigger_error
function and then use zbacktrace... But for debugging on some production
system because only there something goes wrong for some reason, I wouldn't
want to install xDebug (which will be loaded at every request...).
Yes, debugging by logs is hard and debugging on a production is not
ideal, thus you should try to reproduce the problem on your development
machine. Here you can have any extension you like :)
But to some my concerns up: I am unsure, if it is useful to let the error
message lie to you. It should tell you, where it appears, not where some
reason occured (or not), that might cause the call, that contains the line,
where the error occurs.
function foo1($a) {
foo2($a);
}
function foo2($a) {
foo3($a);
}
function foo3($a) {
foo4($a 0 ? 0 : $a);
}
function foo4($a) {
foo5($a);
}
function foo5($a) {
if ($a == 0) trigger_error('Foo');
}
foo1(42); // OK
foo1(0); // Error
foo1(-42); // Error, but the wrong value now comes from foo3()
So now which line should the error report? Note, that in foo3 is a
condition, which makes it non-trivial to find out, where the wrong value
were injected the first time.
btw: Ever considered assert() to find such situations during development?
(Of course you should disable them on production)
Regards,
Sebastian
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist
Exceptions (there you can add a backtrace) too, but you have to catch them,
if not your script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug
trigger_error's notices. (But I don't know if only adding a third parameter
to trigger_error is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Bob
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 2:49 PM, Sebastian Krebs krebs@gmail.com wrote:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com
wrote:
If you do user_error('whatever') it'll show, as the line number for
that
error, the line number on which that user_error() call is made. It'd
be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that
the
user_error is on) instead of Notice: whatever in ... on line 7 (ie.
the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file
name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the
callchain
for
the execution.
I think that this is a sensible default, and allowing to fake that
from
the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that
there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line
numbers.
You would either need to hardcode those in your application and make
sure
that the reference and the actual content of your file is in sync (you
will
screw yourself over sooner or later) or you would use __LINE__ +
offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error
originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal
functions of the framework I don't want to know about, so that I cannot
imagine instantly what's going on?
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than
with xDebug. With gdb it's only setting a break into the trigger_error
function and then use zbacktrace... But for debugging on some production
system because only there something goes wrong for some reason, I
wouldn't
want to install xDebug (which will be loaded at every request...).
Yes, debugging by logs is hard and debugging on a production is not
ideal, thus you should try to reproduce the problem on your development
machine. Here you can have any extension you like :)
But to some my concerns up: I am unsure, if it is useful to let the error
message lie to you. It should tell you, where it appears, not where some
reason occured (or not), that might cause the call, that contains the line,
where the error occurs.
function foo1($a) {
foo2($a);
}
function foo2($a) {
foo3($a);
}
function foo3($a) {
foo4($a 0 ? 0 : $a);
}
function foo4($a) {
foo5($a);
}
function foo5($a) {
if ($a == 0) trigger_error('Foo');
}
foo1(42); // OK
foo1(0); // Error
foo1(-42); // Error, but the wrong value now comes from foo3()
So now which line should the error report? Note, that in foo3 is a
condition, which makes it non-trivial to find out, where the wrong value
were injected the first time.
I'd say that's up to the developer. If foo2-5 aren't intended to be
publicly accessible to the initial foo1() call.
I'm not proposing that the behavior of existing trigger_error() calls
should be modified - rather that new parameters be added or something
whereby the line number / file name can be specified. If they're not then
PHP should show the line and file on which the trigger_error() call was
made.
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 21:49 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name
to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain for
the execution.
I think that this is a sensible default, and allowing to fake that from the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal
functions of the framework I don't want to know about, so that I cannot
imagine instantly what's going on?
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than with
xDebug. With gdb it's only setting a break into the trigger_error function
and then use zbacktrace... But for debugging on some production system
because only there something goes wrong for some reason, I wouldn't want to
install xDebug (which will be loaded at every request...).
Yes, debugging by logs is hard and debugging on a production is not
ideal, thus you should try to reproduce the problem on your development
machine. Here you can have any extension you like :)
But to some my concerns up: I am unsure, if it is useful to let the error
message lie to you. It should tell you, where it appears, not where some
reason occured (or not), that might cause the call, that contains the line,
where the error occurs.
function foo1($a) {
foo2($a);
}
function foo2($a) {
foo3($a);
}
function foo3($a) {
foo4($a 0 ? 0 : $a);
}
function foo4($a) {
foo5($a);
}
function foo5($a) {
if ($a == 0) trigger_error('Foo');
}
foo1(42); // OK
foo1(0); // Error
foo1(-42); // Error, but the wrong value now comes from foo3()
So now which line should the error report? Note, that in foo3 is a condition,
which makes it non-trivial to find out, where the wrong value were injected
the first time.
btw: Ever considered assert() to find such situations during development? (Of
course you should disable them on production)
Regards,
Sebastian
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist Exceptions
(there you can add a backtrace) too, but you have to catch them, if not your
script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug trigger_error's
notices. (But I don't know if only adding a third parameter to trigger_error
is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Bob
--
github.com/KingCrunch
My error messages look like:
Notice:
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Hi! And today we have the problem that we cannot use in any useful manner trigger_error in libraries, when we don't know where the error originates from. You debug today trigger_error's in libraries with putting a debug_print_backtrace behind the trigger_error. I think you Why not use a debugger to debug? Debuggers have backtrace tools. (there you can add a backtrace) too, but you have to catch them, if not your script will abort; but I only need a notice...) If you need additional information in the notice, you can always add it to the text of the notice. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Hi!
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
If you need additional information to accompany the error, why not add
it to the whatever string? This way you can control whatever is
displayed.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 3:14 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
If you need additional information to accompany the error, why not add
it to the whatever string? This way you can control whatever is
displayed.
So the error messages your library produces have the same consistent look
and feel to them that PHP's errors do?
Besides, keeping in mind the KISS keep it simple stupid principal
gratuitous information should probably be hidden away. I mean if it's not
going to help anyone then the only thing left for it to do is potentially
confuse people. And why risk that?
Re: [PHP-DEV] idea: implement a Comparable interface
Hi! Classes without the ability to overload the comparison operator could be considered kinda useless as well. That's demonstrably false - classes are very useful right now in PHP yet no overloading of operators exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: implement a Comparable interface
Hi! I wrote https://wiki.php.net/rfc/comparable a couple of years ago — there's a patch there that would probably still apply without too much work to master. About the only difference was that I didn't double underscore the magic method (in line with both Java and PHP interfaces like Countable). Overriding and isn't the biggest issue, even though BC issues with conversions may definitely be a surprise. Bug biggest one is ==, which may have a lot of very non-trivial effects if you make == return equals when other functions (such as searches, hashes, etc.) may treat them as not equal. It is quite a complex thing which is rife with unexpected side effects, so I think it would be better if it were explicit. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: implement a Comparable interface
To me, it sounds that those extremely specific cases ask for a extremely specific compareTo(stdClass) method. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Stas Malyshev smalys...@sugarcrm.com Hi! I wrote https://wiki.php.net/rfc/comparable a couple of years ago — there's a patch there that would probably still apply without too much work to master. About the only difference was that I didn't double underscore the magic method (in line with both Java and PHP interfaces like Countable). Overriding and isn't the biggest issue, even though BC issues with conversions may definitely be a surprise. Bug biggest one is ==, which may have a lot of very non-trivial effects if you make == return equals when other functions (such as searches, hashes, etc.) may treat them as not equal. It is quite a complex thing which is rife with unexpected side effects, so I think it would be better if it were explicit. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Hi! So the error messages your library produces have the same consistent look and feel to them that PHP's errors do? While it may be nice, I don't think it is worth changing the PHP API for. Error messages have very defined api, which has the place in the source where they were actually produced. Besides, keeping in mind the KISS keep it simple stupid principal gratuitous information should probably be hidden away. I mean if it's not going to help anyone then the only thing left for it to do is potentially confuse people. And why risk that? The place where the error is produced is definitely helpful. Now, it may not be *all* the information you need, but error messages are simple things, they are not meant to replace debugger with full backtrace and stack inspection. I don't think it needs added complications just to have some library messages look a little nicer. In any case, one can install custom error handler which would format messages for user errors differently, if desired. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 3:38 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! So the error messages your library produces have the same consistent look and feel to them that PHP's errors do? While it may be nice, I don't think it is worth changing the PHP API for. Error messages have very defined api, which has the place in the source where they were actually produced. So just redefine the API lol. ie. make it so trigger_error has this as its function definition: bool trigger_error ( string $error_msg [, int $error_type = E_USER_NOTICE [, string $errfile = __FILE__ [, int $errnum = __LINE__ ]]] ) Besides, keeping in mind the KISS keep it simple stupid principal gratuitous information should probably be hidden away. I mean if it's not going to help anyone then the only thing left for it to do is potentially confuse people. And why risk that? The place where the error is produced is definitely helpful. Now, it may not be *all* the information you need, but error messages are simple things, they are not meant to replace debugger with full backtrace and stack inspection. I don't think it needs added complications just to have some library messages look a little nicer. In any case, one can install custom error handler which would format messages for user errors differently, if desired. You shouldn't need to load up a debugger with a full backtrace and stack inspection to figure out (from my previous example) that you had a divide by 0 error. That said I will concede the look a little nicer point. I guess, in my mind, it's really just a matter of how many code changes would be required. If 10,000 lines of code in PHP would have to be changed... it's not worth it. If all you'd be modifying are two lines of code... doesn't seem like such a big deal to me. Besides, what if a program already has an error handler defined?
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@sugarcrm.com: Hi! And today we have the problem that we cannot use in any useful manner trigger_error in libraries, when we don't know where the error originates from. You debug today trigger_error's in libraries with putting a debug_print_backtrace behind the trigger_error. I think you Why not use a debugger to debug? Debuggers have backtrace tools. (there you can add a backtrace) too, but you have to catch them, if not your script will abort; but I only need a notice...) If you need additional information in the notice, you can always add it to the text of the notice. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php nothing against the debugger, but it'd be something really time saving to see the entry point instantly instead of having to use the debugger first... And yes, I can add it to the text (I can even add a function between which analyses the backtrace first), but I think we need more useful (= more information) error throwing in PHP? Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error
originates from. You debug today trigger_error's in libraries with
putting a debug_print_backtrace behind the trigger_error. I think you
Why not use a debugger to debug? Debuggers have backtrace tools.
(there you can add a backtrace) too, but you have to catch them, if
not your script will abort; but I only need a notice...)
If you need additional information in the notice, you can always add it
to the text of the notice.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nothing against the debugger, but it'd be something really time saving to
see the entry point instantly instead of having to use the debugger first...
And yes, I can add it to the text (I can even add a function between which
analyses the backtrace first), but I think we need more useful (= more
information) error throwing in PHP?
How do you want to find out, which call _initially_ set the invalid values?
Is this even (reliable) possible? I've given an example, that it isn't that
trivial.
So even if you have the two additional parameters, what will you set there
(except maybe something like __LINE__-4, which is as trivial as useless)?
With this in mind: How do you think the additional parameters _can_ help?
Another example
function foo() {
return 0;
}
function bar($a) {
div($a);
}
function div($a) {
if ($a == 0) trigger_error('');
}
div(bar(foo()));
Which line should the message report now:
- bar() because it calls div()?
- or foo() because it is the function, that returns the invalid value, that
is used later? But 0 is maybe a valid return value for foo()?
- or div(bar(foo()));, but how to find out, that foo() _really_ returned
the invalid value?
Like in my other example you can report any file and line you want and
which is maybe/probably involved, but in most if not all cases it doesn't
prevent you from debugging.
Regards,
Sebastian
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
On Tue, May 7, 2013 at 4:30 PM, Sebastian Krebs krebs@gmail.com wrote:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error
originates from. You debug today trigger_error's in libraries with
putting a debug_print_backtrace behind the trigger_error. I think you
Why not use a debugger to debug? Debuggers have backtrace tools.
(there you can add a backtrace) too, but you have to catch them, if
not your script will abort; but I only need a notice...)
If you need additional information in the notice, you can always add it
to the text of the notice.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nothing against the debugger, but it'd be something really time saving to
see the entry point instantly instead of having to use the debugger
first...
And yes, I can add it to the text (I can even add a function between
which
analyses the backtrace first), but I think we need more useful (= more
information) error throwing in PHP?
How do you want to find out, which call _initially_ set the invalid values?
Is this even (reliable) possible? I've given an example, that it isn't that
trivial.
So even if you have the two additional parameters, what will you set there
(except maybe something like __LINE__-4, which is as trivial as useless)?
With this in mind: How do you think the additional parameters _can_ help?
Another example
function foo() {
return 0;
}
function bar($a) {
div($a);
}
function div($a) {
if ($a == 0) trigger_error('');
}
div(bar(foo()));
Which line should the message report now:
- bar() because it calls div()?
- or foo() because it is the function, that returns the invalid value, that
is used later? But 0 is maybe a valid return value for foo()?
- or div(bar(foo()));, but how to find out, that foo() _really_ returned
the invalid value?
Like in my other example you can report any file and line you want and
which is maybe/probably involved, but in most if not all cases it doesn't
prevent you from debugging.
PHP wouldn't auto-magically be figuring it out - the person writing the PHP
code would be the one to figure it out.
If you wrote a bigint library and of those three functions the only one you
wrote was div() then presumably you - as the author of that bigint library
- would make it show the line number on which the div() was called. Maybe
bar() and foo() trigger errors as well.. who knows. Just because you have
everything on the same line doesn't mean you can't have multiple errors on
the same line. That's really the business of the end-user using the bigint
lib.
And if you, as a PHP developer, wrote all three functions - foo(), bar()
and div()... it's up to you which one shows up as being the call that
caused the error. PHP shouldn't be trying to auto-magically figure it out
nor was that my proposal.
It's like... if someone writes a callback function for preg_replace() the
person who wrote that function is going to be the one who decides what
subpattern - if any - that function is going to look at. I don't know why
anyone would expect PHP to auto-magically figure it out.
[PHP-DEV] [PATCH] faster and safer fpm config reading
commit edae18ccf5c51ae0bcc0e9655ead7540fd42dd9f
Author: Martin Pelikan peli...@storkhole.cz
Date: Wed May 8 02:06:09 2013 +0200
Faster and safer parsing of fpm configuration.
The current fpm config parser did a read(2) syscall per character,
which obfuscated debugging strace/ktrace output somewhat. This also
makes the 1024 characters per line limit more explicit, so the users
will know what were they hitting.
It might improve performance during php-fpm load (.03 vs .00 seconds
on my laptop) but primarily serves to help observing fpm system call
traces during deployment (in chroot for example).
Signed-off-by: Martin Pelikan martin.peli...@gmail.com
diff --git a/sapi/fpm/fpm/fpm_conf.c b/sapi/fpm/fpm/fpm_conf.c
index 0a8a0e3..e004934 100644
--- a/sapi/fpm/fpm/fpm_conf.c
+++ b/sapi/fpm/fpm/fpm_conf.c
@@ -1447,11 +1447,11 @@ static void fpm_conf_ini_parser(zval *arg1, zval *arg2,
zval *arg3, int callback
int fpm_conf_load_ini_file(char *filename TSRMLS_DC) /* {{{ */
{
+ const int bufsize = 1024;
int error = 0;
- char buf[1024+1];
- int fd, n;
+ char buf[bufsize], *newl;
+ int fd, pos = 0;
int nb_read = 1;
- char c = '*';
int ret = 1;
@@ -1473,36 +1473,48 @@ int fpm_conf_load_ini_file(char *filename TSRMLS_DC) /*
{{{ */
}
ini_lineno = 0;
+ memset(buf, 0, sizeof buf);
while (nb_read 0) {
int tmp;
- memset(buf, 0, sizeof(char) * (1024 + 1));
- for (n = 0; n 1024 (nb_read = read(fd, c, sizeof(char)))
== sizeof(char) c != '\n'; n++) {
- buf[n] = c;
- }
- buf[n++] = '\n';
- ini_lineno++;
- ini_filename = filename;
- tmp = zend_parse_ini_string(buf, 1, ZEND_INI_SCANNER_NORMAL,
(zend_ini_parser_cb_t)fpm_conf_ini_parser, error TSRMLS_CC);
- ini_filename = filename;
- if (error || tmp == FAILURE) {
- if (ini_include) free(ini_include);
- ini_recursion--;
- close(fd);
- return -1;
- }
- if (ini_include) {
- char *tmp = ini_include;
- ini_include = NULL;
- fpm_evaluate_full_path(tmp, NULL, NULL, 0);
- fpm_conf_ini_parser_include(tmp, error TSRMLS_CC);
- if (error) {
- free(tmp);
+
+ nb_read = read(fd, buf + pos, sizeof buf - pos);
+ pos = 0;
+
+ while ((newl = strchr(buf + pos, '\n')) != NULL) {
+ newl[0] = '\0';
+ ini_lineno++;
+ ini_filename = filename;
+ tmp = zend_parse_ini_string(buf + pos, 1,
ZEND_INI_SCANNER_NORMAL, (zend_ini_parser_cb_t)fpm_conf_ini_parser, error
TSRMLS_CC);
+ ini_filename = filename;
+ if (error || tmp == FAILURE) {
+ if (ini_include) free(ini_include);
ini_recursion--;
close(fd);
return -1;
}
- free(tmp);
+ if (ini_include) {
+ char *tmp = ini_include;
+ ini_include = NULL;
+ fpm_evaluate_full_path(tmp, NULL, NULL, 0);
+ fpm_conf_ini_parser_include(tmp, error
TSRMLS_CC);
+ if (error) {
+ free(tmp);
+ ini_recursion--;
+ close(fd);
+ return -1;
+ }
+ free(tmp);
+ }
+
+ pos = newl - buf + 1;
+ }
+ if (nb_read 0 pos == 0) {
+ zlog(ZLOG_ERROR, line %u too long, ini_lineno + 1);
+ close(fd);
+ return -1;
}
+ memmove(buf, buf + pos, sizeof buf - pos);
+ pos = sizeof buf - pos;
}
ini_recursion--;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Casting Magic Methods
The __toArray can be useful if you want to perform array functions on the object (E.G array_filter), otherwise I think it would be very useful if the array functions can accept an object implementing ArrayAccess as well instead of just an array On May 7, 2013 8:40 PM, Nikita Popov nikita@gmail.com wrote: On Sat, May 4, 2013 at 5:31 PM, Oleku Konko oleku.ko...@yahoo.com wrote: Quick Observations : I had this issue ( http://stackoverflow.com/questions/16375331/increment-on-tostring ) and it kept me thinking why no error was returned, then i stumble up this RFC : https://wiki.php.net/rfc/object_cast_to_types The patch is basic , simple and working and it should be seriously considered in 5.5. I want to believe if https://github.com/php/php-src/pull/334 can make it to PHP 5.5 then we should give object_cast_to_types the same opportunity except they are string objections why it should not be so I don't think that this would be particularly useful and as such I don't think we need it. The idea of doing some meaningful operation when writing $obj + 1 is nice, but only if you have actual operator overloading and can compute the result of that expression yourself. If you don't have this possibility and only get to cast $a to an integer/float, then the whole thing becomes rather useless. The only thing it could be used for are thin wrappers around integers/floats and I don't see why one would want to do such a thing (especially as you get back a number and *not* a wrapper object). Thus, __toScalar(), __toInt(), __toFloat() seem pretty useless. The only thing that might have some merit is __toArray(). But there again, I'm not really sure what it gives us. After all we already have Traversable and ArrayAccess, so we can already make an object behave pretty much like an array. Nikita
