RE: [PHP-DEV] idea: implement a Comparable interface

[Christian Stoller]

 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

I would like to see this feature in PHP! I often thought it would be very 
helpful. In days of PHP 5.2 I wrote a Date-Class similar to DateTime but with 
another API which should be the same as in C#. Comparing dates with 
``$date-compareTo($date2)  0`` is always hard to read and error-prone.

Another example: You have one database entity and a collection and you want to 
check if it is in the collection.

$dbEntity = ...;
$dbCollection = ...;

foreach ($dbCollection as $tmpEntity) {
if ($dbEntity-getId() == $tmpEntity-getId()) {
// ...
}
}

Instead you could write ``$dbEntity == $tmpEntity``. I think this is easier to 
read.

Of course you can say just syntetic sugar, but better readability of code 
helps developers a lot!

Best regards
Christian

Re: [PHP-DEV] Scalar Type Casting Magic Methods

[Ferenc Kovacs]

2013.05.08. 7:38, Pierre du Plessis pie...@pcservice.co.za ezt írta:

 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

yeah, I also think that ArrayObjects should be accepted where array is
expected.

[PHP-DEV] Re: Multi-level Caching Fork of OPcache -- update

[Terry Ellison]

Dmitry,

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.


Hi and thanks for this.  I won't have the full functionality in place 
for another month or so, though my pushes to my github repository should 
be fully functional on the main path and subject to caveats in the TODO, 
etc., so it's just more general guidance when you get time, e.g I would 
be happier if you approached X this way, or don't forget to address 
issue Y which we've been burnt on in the past...


Also have a scan through the wiki pages for B/G design info.  If you 
guys want, I could also do the equivalent for standard OPcache down the 
line, since I know have a pretty intimate knowledge of how it works; I 
would just need to know the target audience that you would like to address.


Regards
Terry



On Sat, May 4, 2013 at 5:29 PM, Terry Ellison te...@ellisons.org.uk 
mailto: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 fork of OPcache and
specifically on the dev-filecache branch.  The most appropriate
channel is probably https://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-details and 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.