Re: [PHP] Binding object instances to static closures
This will not work.
As stated in the PHP documentation Static closures cannot have any bound
object
A static Closure has no context of this just as with any other static
object.
A workaround is to pass in the Closure as a parameter to achieve a similar
result.
class TestClass {
public static function testMethod($function) {
$testInstance = new TestClass();
$function = $function-bindTo($testInstance);
call_user_func_array($function, [$testInstance]);
// should be true
}
}
TestClass::testMethod(function($param){
var_dump($this === $param);
});
On Fri, May 31, 2013 at 2:32 PM, Nathaniel Higgins n...@nath.is wrote:
I'm talking about PHP 5.4. `bindTo` is a Closure method in PHP 5.4, and
allows you to set the `$this` variable inside of a Closure. However,
apparently you can't use it on Closures created inside static methods.
I knew that you could create another function which would return the
Closure, however, that isn't what I asked. I wanted to either use the
`bindTo` method on a static Closure, or create a non-static Closure in a
static method.
On 31 May 2013 19:25, David Harkness davi...@highgearmedia.com wrote:
On Fri, May 31, 2013 at 10:54 AM, Nathaniel Higgins n...@nath.is wrote:
Is it possible to bind an instance to a static closure, or to create a
non-static closure inside of a static class method?
PHP doesn't have a method to do this. In JavaScript you can use jQuery's
var func = $.proxy(function () { ... }, object);
In fact, you cannot use $this inside a closure at all (unless 5.4 has
added a way that I haven't seen yet). You can get around that by
declaring
a local variable to hold a reference to the instance to use with use.
It
looks strange here because you're also passing in $testInstance for the
comparison.
?php
class TestClass {
public static function testMethod() {
$testInstance = new TestClass();
$closure = $testInstance-createClosure($testInstance);
call_user_func($closure);
// should be true
}
private function createClosure($testInstance) {
$self = $this;
return function() use ($self, $testInstance) {
return $self === $testInstance;
}
}
}
TestClass::testMethod();
Peace,
David
--
Thanks,
http://nath.is
@NatIsGleek http://twitter.com/natisgleek
-- --
Unless otherwise specified, this conversation can be classed as
confidential, and you have no permission to share all, part, or even the
gist of this conversation with anyone not part of the original
conversation. If in doubt, please contact be with the above links, or on my
UK phone number - *07427558947*. Please be thoughtful of what time it is in
the UK at your time of calling.
--
Nickolas Whiting
Lead Developer
X Studios
321-281-1708x107
Re: [PHP] Having a problem with clone.
Do you have a backtace for this? What is the gender class doing? Have u done a global search for keyword clone? On Friday, May 10, 2013, Richard Quadling wrote: Hi. I'm having an issue where I get ... Fatal error: Trying to clone an uncloneable object of class Smarty_Variable in xx/trunk.newbuild/includes/frontend/site_includes/classes/smarty-3.10/sysplugins/smarty_internal_template.php on line 269 This issue happens consistently on our live server and on our test server, but not on my dev setup. The issue doesn't happen if I comment out 1 line of completely unrelated code ... $o_Gender = new Gender\Gender; If I immediately follow that with ... unset($o_Gender); and have no other access to $o_Gender, I still get the error. Comment out the code, no problems. The extension is used in other parts of the system with seemingly no problem. That is, the code behaves as expected and I get no errors, but those elements don't use Smarty. The error being reported is clearly wrong. And the extension (as far as I can see) has no interaction with global elements in any way (I have to use the Gender namespace to access anything in it - which I think is correct). I've var_dump()'d a debug_backtrace() at the point of failure in the Smarty code, with and without the $o_Gender variable being defined (it isn't used in the Smarty template - so Smarty is never touching it). When I compare the 2 dumps, the only differences is in the datetime stamp elements and the object count values (there's 1 more when $o_Gender exists). My setup is on a CentOS VM running PHP V5.4.14 The live setup is on a remote CentOS server running PHP V5.3.21 The test server is on CentOS server running PHP V5.3.3 I don't know CentOS well enough to just swap out a new version of PHP. But I will be getting some help on that. Where do I start to find the problem? I have full root access to the command line test server, so I can, within reason, follow instructions to run/wrap the code in any way needed. Any help would be GREATLY appreciated!!! Thanks in advance, Richard. -- Richard Quadling Twitter : @RQuadling -- Nickolas Whiting Lead Developer X Studios 321-281-1708x107
[PHP] Introduction ... !
Hello PHP'ers! Just thought I would introduce myself to the mailing list since I've worked with PHP for almost 10 years now and yet haven't really been community active ... I've developed quite a few open-source projects over the years that I hope someone here will find as useful as I have ... they are all hosted on Github @prggmr. XPSPL - Signal Processor in PHP docpx - PHP Documentation Generator for Sphinx Again Hello Everyone! Cheers! -- Nickolas Whiting - prggmr.org - Remember to write less code that does more faster -
Re: [PHP] Holding datetimes in a DB.
On Fri, Mar 1, 2013 at 7:04 PM, Sebastian Krebs krebs@gmail.com wrote: 2013/3/2 tamouse mailing lists tamouse.li...@gmail.com On Fri, Mar 1, 2013 at 11:53 AM, Matijn Woudt tijn...@gmail.com wrote: On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling rquadl...@gmail.com wrote: Hi. My heads trying to remember something I may or may not have known to start with. If I hold datetimes in a DB in UTC and can represent a date to a user based upon a user preference Timezone (not an offset, but a real timezone : Europe/Berlin, etc.) am I missing anything? Richard. I would only use this if you're planning to have servers all around the world in different timezones, then it would be easier to interchange data. Otherwise, stick with ur local timezone and it will save you a lot of unneeded timezone conversions probably. - Matijn This may be just me, but I've always preferred my servers, database, and such to run UTC, and let users select their own time zone they'd like to see. Well, imo it depends ;) There are cases, where it is interesting to know, when from the users point of view they have created the entity (like a blog post, a comment, or something like that). The TZ is part of the data and converting it silently to UTC is always data-loss. So in most cases it is OK, but not in every :) You can still convert from entity-TZ to UTC to user-TZ later. Its just one additional step. Regards, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch I have found that it's always best to stick to UTC ... regardless of anything else ... since saving the users local and going to and from can easily be wrapped into a single entry/exit function and I've had to many instances where it was saved as local and it came back to bite simply to save a few minutes. That said this is something I feel should be documented since for many newcomers they usually don't think about timezones until it becomes a problem ... Cheers! -- Nickolas Whiting - prggmr.org - Remember to write less code that does more faster -
Re: [PHP] Introduction ... !
On Fri, Mar 1, 2013 at 6:32 PM, tamouse mailing lists tamouse.li...@gmail.com wrote: On Fri, Mar 1, 2013 at 11:56 AM, Daniel Brown danbr...@php.net wrote: On Fri, Mar 1, 2013 at 12:54 PM, Jim Giner jim.gi...@albanyhandball.com wrote: What gives you such optimism? I recently saw a list of languages in use and PHP has dropped quite a bit over the last 5 or more years. Being a relative newbie myself, I'm happy that PHP exists and is so readily available to us hobbyists, etc. Certainly am in favor of your optimism, but curious (hey it's Friday!) about your prediction. Just knowing how the patterns go. It's always the same, and it will likely be the same again. No guarantees, but all it takes is a bit of fostering of the community to return it to a decently-vibrant forum. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Things come, things go, ebb and flow. PHP is easy for people to pick on, for some good and not so good reasons. It, to me, is still the easiest programming language for someone to learn, in *NO* small reason because of all the excellent documentation and community contributed comments. And places like this list. I've been working in Rails for the past several months, and although I much prefer Ruby as a language, the documentation on libraries, extensions, packages, and frameworks is rather lacking. The ruby doc website has the space for users to add comments, but there's hardly any. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- http://www.php.net/unsub.php Nickolas Whiting - http://www.php.net/unsub.phpprggmr.org - Remember to write less code that does more faster - One would think with such a widely used language the mailing list would be crazy ... then again sites such as SO seem to be taking the internet world by storm and moving what some would call *old school* forums such as this into the dark. That said ... it never occurred to me until just recently to get into this forum, in-fact for a number of years I simply didn't know this forum existed.
