On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei wrote:
> So currently preferred over my patch are two solutions:
>
> 1. Just create a DateTimeValue object that is immutable, not optimizing PHP
> to handle it with efficient garbage collection.
> 2. One step further, add a "static class DateTimeVa
> > > $result = new ResultMaker()->getIt();
Isn't this issue just a matter of defining one thing as being correct
and then get on with it? There are lots of ambiguities in php's
grammar already.
--
troels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
Hi
On Thu, Mar 25, 2010 at 4:00 PM, Lukas Kahwe Smith wrote:
> On 25.03.2010, at 14:48, David Soria Parra wrote:
>> Stefan what do you think about "stackable traits" ?
>
>
> Woha .. that code really scares me.
>
While I like features like this in other languages, I think it would
be a big break
Hi Stan.
On Tue, Mar 23, 2010 at 8:47 AM, Stan Vassilev wrote:
> Thanks for your patch, but you're going to affect a whole group of users who
> do advanced logging and recovery in the shutdown phase. This is why these
> things have to be considered when they're first added.
How would they be aff
With the help of Scotts last suggestion, I made some changes. It seems
to work, but then I don't really know how to test it properly. I can
verify that A) it allows userland code the grace period of 1 second
for shutting down and B) shuts down regardless of the userland error
handler returning or n
On Mon, Mar 22, 2010 at 7:10 PM, Scott MacVicar wrote:
>
> Statics are bad, if its in multithreaded mode and two timeouts happen at once
> you'll get some funny behaviour. You need to store this in the thread local
> storage so the flag is per thread.
>
Thanks. My C is severely rusty; Would it
On Mon, Mar 22, 2010 at 4:55 PM, troels knak-nielsen wrote:
> On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke wrote:
>>> What do you mean by "no option"? Otherwise yes, that's what it does.
>> Using sleep there is not a good practice. Since the custom error
>
On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke wrote:
>> What do you mean by "no option"? Otherwise yes, that's what it does.
> Using sleep there is not a good practice. Since the custom error
> handler is triggered, there is no need for the sleep call anyways.
So control isn't returned to the C
2010/3/22 Johannes Schlüter :
> A one second delay is no option there. And what actually happens is that
> the warning triggers your custom error handler. After that it sleeps
> then it dies.
What do you mean by "no option"? Otherwise yes, that's what it does.
> This also creates a "nice" way to
Hi list.
We log all errors that happens in our production environment, but as
fatal errors can't be handled from within php, we end up with little
information to go on for further debugging. I'm not very familiar with
the php internals code, but I managed to throw in a hack that appears
to work. I
On Mon, Feb 8, 2010 at 2:38 PM, mathieu.suen wrote:
> Hi,
>
> I am wondering if there is some effort for having continuation in php.
> Or is there already some construction for continuation?
phaux (http://code.google.com/p/phaux/) is an attempt at creating a
continuation-based framework for php.
Here's another extension for the same. Generates nice graphs too.
http://www.bytekit.org/
--
troels
On Thu, Dec 3, 2009 at 4:53 PM, Graham Kelly wrote:
> Hi,
>
> It sounds like what you want is VLD. http://pecl.php.net/package/vld
>
> - Graham Kelly
>
> On Thu, Dec 3, 2009 at 10:51 AM, Mat
On Mon, Oct 26, 2009 at 3:25 PM, Mathieu Suen
wrote:
> Yes that the same but only for PHP <= 5.3.
> I am more asking about performance.
You mean PHP < 5.3 ?
In that case, I would strongly suggest that you use a procedural
style. create_function is slow, leaks memory and offers no
compile-time va
On Fri, Sep 18, 2009 at 1:05 PM, Ford, Mike wrote:
> Well, that sounds like a pretty good definition of a "magic" constant, so
> maybe __CALLER__ might be appropriate as well?
It's not a constant, is it now?
__FILE__, __LINE__, __CLASS__ etc. can be resolved at compile-time.
The caller will onl
On Fri, Jul 24, 2009 at 3:23 PM, wrote:
> I published a (work in progress) RFC today about replacing certain
> errors with exceptions. I know that there already was something similiar
> on the php6dev blog, but this is not completly the same, so awating your
> comments:
>
> http://wiki.php.net/rfc
-- Forwarded message --
From: troels knak-nielsen
Date: Fri, Jul 10, 2009 at 2:12 PM
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
To: Lukas Kahwe Smith
On Fri, Jul 10, 2009 at 1:40 PM, Lukas Kahwe Smith wrote:
> right .. lets not forget the original goal (tho
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompson wrote:
> troels knak-nielsen wrote:
> - How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same n
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature of
On Thu, Jul 9, 2009 at 2:15 AM, Mark wrote:
> I personally would be highly in favor of adding type hinting/casting
> BUT with the benifit that php actually becomes faster if you do things
> like that. Afterall you can use way more effective c code if you know
> what you expect right? As for the ver
On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yang wrote:
> Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
>> I would have expected the second call to __construct() to yield an error.
>
> Why should it? Especially since this is idiomatic code:
>
> class A {
> public fun
I just realised that the following is valid php code:
class Foo {
function __construct() {
echo "constructor called\n";
}
}
$f = new Foo();
$f->__construct();
Output:
constructor called
constructor called
I would have expected the second call to __con
In a recent mail, some kind of issue regarding queryparams was
mentioned (Possibly related to namespaces). Could anybody explain what
the issue is, or point to where it's discussed?
On Mon, Jan 12, 2009 at 11:56 AM, Lukas Kahwe Smith wrote:
> - I guess we are not going to deal with "foo.php?a.b.c
On Sun, Jan 4, 2009 at 10:05 PM, Larry Garfield wrote:
> $f = function($a, &$b) use ($y, &$z) global ($x, &$w) {
It would still leave the "static" keyword as an outlier. It wouldn't
make sense to declare a static by-ref.
Another problem with this, is that "use" and "global" doesn't match
concept
On Fri, Dec 19, 2008 at 3:31 PM, Nathan Rixham wrote:
> type hints are all ready there so adding primitives /should/ be possible
> without any bc issues
PHP is loosely typed. Adding typehints to primitives would change
this. The only reason that it is working with object types, is because
you can
On Tue, Dec 16, 2008 at 3:06 PM, Richard Quadling
wrote:
> Would it be at all possible to have an ini setting json.strict_encode = On
>
> So, my code doesn't change, but I can activate it globally.
> Essentially I don't want to shoot myself. I don't want to take the
> safety off.
I think we have
On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar wrote:
> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
> parameter to the options flag. So you can use
>
> json_encode($var, JSON_STRICT_ENCODE);
>
I'm really not a fan of named constants to change the semantics of a
function lik
On Mon, Dec 15, 2008 at 10:02 PM, mike wrote:
> I'd like to see it "do the right thing" in PHP 6, and perhaps if
I think everybody agrees to that. The question at hand, is what the
right thing is.
I, for one, think that the only sane choices are 1 or 2. The third
option is way too magic, and wil
On Thu, Nov 6, 2008 at 10:35 AM, Dan <[EMAIL PROTECTED]> wrote:
> What if you want to provide a set of helper/wrapper classes, appropriately
> namespaced, something along the lines of:
> MyFramework\Helpers\Array
> MyFramework\Helpers\Database
> MyFramework\Helpers\Session
> etc.
>
> If I want to u
On Tue, Nov 4, 2008 at 10:11 AM, Ionut Gabriel Stan
<[EMAIL PROTECTED]> wrote:
> Anyway, I see there's nobody else that would like this but it's ok, at least
> now we have namespaces so that
> I don't have to come up with ugly names like my_map() for these kind of
> helper functions.
I like the pr
I just realised that his is valid PHP:
42,
'foo' => 53));
Producing the following output:
array(1) {
["foo"]=>
int(53)
}
I can anticipate that there may be practical reasons for this
"feature", but I can't think up any scenario, where it wouldn't be a
programming error to statically dec
On Fri, Sep 19, 2008 at 10:50 AM, Hannes Magnusson
<[EMAIL PROTECTED]> wrote:
> I totally agree. Its really annoying needing to type $ all the time,
> not to mention how hard it is on Norwegian keyboards. Lets replace it
> with £ !
> There is even a "patch" available:
> http://php.markmail.org/mess
On Thu, Sep 18, 2008 at 9:09 PM, Arvids Godjuks
<[EMAIL PROTECTED]> wrote:
> Well, you can do that right now, PHP supports that for ages.
>
> $myVar = 'print';
> $myVar('Hello!'); // Outputs hello
> ?>
Partly because I can't resist being smug, partly because it might
confuse someone, I have to po
On Tue, Jul 29, 2008 at 2:58 PM, Moriyoshi Koizumi
<[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I created a library that may draw some attention. Boost.PHP is a set of
> macros and C++ classes that wrap around common Zend Engine structs that
Is Boost.PHP affiliated with boost.org ?
--
troels
--
P
First, apologies if this has been discussed before. I couldn't find
any evidence to suggest that it has, but it kind of surprises me.
As strings aren't objects in PHP, __toString is quite a useful
construct, but it begs the question as to why there aren't
__to for each of the primitive types in PH
On Mon, Jun 30, 2008 at 12:41 AM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> Hi Stas,
>
> Am Sonntag, den 29.06.2008, 15:20 -0700 schrieb Stanislav Malyshev:
> [...]
>> If we use this syntax, and $view->escape is not defined, should we
>> call __call or __get?
>
> That's indeed a good question. Call
On Tue, Jun 24, 2008 at 9:19 AM, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
> Another subject I would like to see now the closures has been brought up
> again
> is, how about adding type hinting in method/function prototypes:
>
> function call(function $callback)
> {
>$callback();
> }
On Fri, Jun 20, 2008 at 9:36 PM, Markus Fischer <[EMAIL PROTECTED]> wrote:
> Since some raised issues with the word "lexical", what do people think to
> just re-use the (afaik deprecated) "var" keyword, so we won't need a new
> keyword in the chain.
What exactly is the problem with "lexical"? I fi
On Thu, Jun 19, 2008 at 4:37 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> I don't like "lexical" keyword, because it can be used anywhere in function
> (e.q. inside "if" or loop statement), however lexical variables must be the
That does sound wtf-y, indeed. Is that allowed with the global
keyw
On Thu, Jun 19, 2008 at 8:44 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>> >> - In PHP 5, object storage is resources done right. I don't think
>> >> we should be using the resource infrastructure for this
>> >> implementation and would prefer to use the object one. It's better.
>> >> I suggest to
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena <[EMAIL PROTECTED]> wrote:
> class test {
>static public function +Itest testing($instance) {
>return $instance;
>}
> }
A more sane syntax, might be something like:
class test {
static function testing($instance) :
On Feb 19, 2008 11:45 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> I think also for
> the sake of conceptual integrity separating interfaces clearly from
> traits is a good idea: interfaces define structure while traits are
> function buckets. A class may use traits, may implement interfaces and
>
On Feb 19, 2008 9:54 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> how about 'possesses' or 'exhibits' - both these words are closer to the
> natural language usage of 'trait' with regard to a subject.
>
> John exhibits a trait
> Jack possesses a trait
I prefer ``without`` over ``except``
On Feb 19, 2008 10:51 PM, Evert | Rooftop <[EMAIL PROTECTED]> wrote:
> Aliasing doesn't make a lot of sense, as you can always :
>
> function newMethod() {
>
>return $this->oldMethod();
>
> }
>
> just seems like unneeded complexity, without a clear benefit..
I believe the idea was to resolve n
On Feb 18, 2008 8:27 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> during last six months I've studied a language construct called Traits.
> It is a construct to allow fine-grained code reuse and in my opinon
> this would be a nice feature for PHP, which I did like to propose here.
> The following RFC
One problem, I have with this proposal is, that it isn't much like
javascript anyway. In javascript, there is a distinction between array
and hashmap, with different syntaxes. If anything, the syntax should
probably be {'foo' => 1, 'bar' => 2}.
I don't think the added noise is worth it though, sinc
On Dec 23, 2007 2:23 AM, Christian Seiler <[EMAIL PROTECTED]> wrote:
> First of all: I don't quite understand what you mean when you want to
> serialize a function (closure or not)? The opcodes? Ok, sure, with the
> current PHP implementation you can serialize the variable used to CALL
> the functi
I have another observation about names.
Instead of using an arbitrary name, as the name of the function,
wouldn't it be possible to let the name be derived from the
function-body. Eg., if you took the function-body's tokens and created
a hash from them. This would have two implications: 1) Multiple
On Dec 20, 2007 7:02 PM, Sean Coates <[EMAIL PROTECTED]> wrote:
> Apart from saving a few keystrokes, the above could easily be changed
> to the following, which is much more clear, DOES compile at compile-
> time, and works without adding a new construct that looks like a
> closure, but is not ind
(Sorry if you get this twice, Antony. I didn't hit 'Reply to all' the
first time)
On Dec 20, 2007 10:19 AM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 20.12.2007 11:18, Alexey Zakhlestin wrote:
> > On 12/20/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> >> On 20.12.2007 09:57, Alexey Zakhlestin
On Dec 20, 2007 1:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Well, the whole functional programming thing.
>
> But PHP is not an FP language and wasn't built to be one. If one needs
> an FP language, why not look into languages built with that purpose?
We can change it then. PHP wasn
On Dec 20, 2007 12:44 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > I think we need it. In the current incarnation, anonymous functions
> > are so impractical to use, that it's a barrier. I think that is
> > unfortunate, because it could be an interesting and useful direction
> > to take fo
On Dec 19, 2007 11:21 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > So how big a part of PHP's userbase is that? I'm guessing, it's small.
>
> If it's small, we don't need it in the language anyway.
I think we need it. In the current incarnation, anonymous functions
are so impractical to u
On Dec 18, 2007 12:41 AM, Jeff Moore <[EMAIL PROTECTED]> wrote:
> Reading the prior discussion, I think either $_SCOPE['x'] or the
> lexical $x syntax is fine for accessing local variables in the
> enclosing scope. But closures also should also support $this and
> static:: when the closure is def
On Dec 17, 2007 6:09 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Don't have time right now but we should go back and re-read those
> discussions before opening a new one. I can probably do it over the next
> couple of days. I am not necessary against supporting such a solution
> but we need to ma
On Dec 16, 2007 8:56 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> I don't see how it'd help anything in debugging.
Presumably, a stack trace would now contain file and line number.
> That's not binding. But the problem is, seeing this, one expects
> closure. And it's no closure.
One might
roels
On Dec 16, 2007 7:57 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> I think the problem there is that this syntax wouldn't support external
> variables, and without them there's not much difference between that and
> create_function.
>
>
> troels knak-nie
What was the conclusion on Wez' patch from march [1]? The discussion
seemed to steer a bit off, on the discussion of scoping rules, but is
there any reason _not_ to implement Wez' patch in HEAD?
Even if it doesn't entirely replace create_function, it would be nice
to have as a compile-time alternat
If taint-mode is intended for testing only, it would never be
something, which was turned on per default. Then maybe a tool such as
php-sat ( http://www.program-transformation.org/PHP/PhpSat ) is a
better solution? It seems to me like there is a rather big overlap
between the projects.
--
troels
On 9/27/07, drysler <[EMAIL PROTECTED]> wrote:
> Hello,
>
> i am practising with charsets at the moment and so i thought:
>
> -> How does PHP know the charset i use in my source-code?
> -> Are php-sources limited to specific charsets?
> -> In which areas you have to be aware of the source-code-char
On 7/18/07, David Duong <[EMAIL PROTECTED]> wrote:
Since there isn't any comments on this, should I have posted this
elsewhere? or is it just that no one is interested?
It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decisio
60 matches
Mail list logo
