[PHP-DEV] Bugs with APC

[steve]

Is this a proper place to discuss bugs in APC? I know of bug that was
also in ZPS (still is actually, but was fixed in Zend Platform's
accelerator).

I can't for the life of my figure out a one file example, but I can if
you had PRADO installed already. It has something to do with how they
do automatic calling of a getter if you try and access a property by
the same (well, similar) name. Like $this-Page use __get() somewhere
in the framework to call $this-getPage(). With APC on it fails (null
value) where with APC off or using Zend Platform, it works fine.

I tried writing a single file based on what I know is happening, but I
don't see the error in that case. There is something non-obvious going
on. However, I can give one file (or tell how to change one line in a
sample file) if PRADO was already loaded up.

-s

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Named arguments revisited

[steve]

On 1/15/06, Zeev Suraski [EMAIL PROTECTED] wrote:
 In those rare occurrences where named parameters have true benefits,
 please live with the drawbacks of using array().

I do, though code completion, type hinting, etc. would be nice. It
would nice if it was consistenly added so that built-in functions had
that behavior, since no one can use the array hack for those. But lots
of things would be nice, so I don't really care. Seems like too much
work for the benefit. And there are downsides not even mentioned in
this thread (parameter names are now seen (which is obvious, until you
really think about it), they gain longevity, language issues, etc.).

Not to mention, we might be tempted to go back and rewrite stuff and
that would not be an effecient use of our time.

But rare occurrences? That was pretty funny! Sadly...

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Named arguments revisited

[Jeremy Johnstone]

Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:

(using pseudo example from above)

function db_connect($params) {
$host = 'localhost';
$user = 'root';
$password = '';
$port = 3301;
extract($params, EXTR_OVERWRITE);
// ... more code here
}

This covers the default parameters in a clean fashion which is easy to
understand and should be readable to anyone who knows PHP in even the
slightest fashion. Now to the issue of type hinting, it's as simple as
doing something like the following:

if(!($obj instanceOf ClassName)) {
   throw new Exception();
}

Then you have complete control of how the error is handled (be it
exceptions, trigger_error(), etc). To me, it seems the options are a
LOT more flexible using array syntax than using actual named
parameters, but maybe that's just me. To each their own, but if it
were me, it seems the above not only is easier to use / read, but also
guaranteed to work on almost all versions of PHP (at least in the case
of the first code snippet).


--
---
Jeremy Johnstone
http://www.jeremyjohnstone.com
[EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Naming Arguments

[Sara Golemon]

That's Naming not Named.

From the perspective of providing reflection in general and giving something 
for editors with code completion to use in specific, would there be an 
interrest in backfilling the arg_info structs for internal functions (both 
core and otherwise) with argument naming and type hinting even where it's 
not technically needed?


On the con side, this does add memory usage and processing time for no 
direct production benefit.  Any utility which wanted this degree of 
introspection *could* parse the XML protos in phpdoc and get the same (or 
better) information, so it doesn't really gain that much for what it costs.


Do please forget about the work required to fill in this information.  There 
are more than enough volunteers to do the grunge work(and frankly it'd be 
tough for 'em to get it horribly wrong), this is just a question of: Would 
there be an interrest in folding this data into the core? and secondly: 
Should new extension writers be encouraged to fill this information in?.


-Sara 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php