Re: [PHP-DEV] Adding numeric type hint
This has been a big issue that I have ran into many times in the past for
large framework projects, instead of building it out with strict types
like: int, float, string, exc... It makes more sense to allow a user to
define a psudo-type themselves which PHP will pass the arguments into to be
cleaned by the user then let the function deal with the arguments.
For example:
function force_int($value){
return (int) $value;
}
function must_be_string($v){
if(!is_string($v)){
throw new Exception(Not String);
}
return (string) $v;
}
function foo(*force_int $val, *must_be_string $str){
// $val will always be an int if it ever gets here
// $str will always be a string if it gets here
echo $val, , $str;
}
foo(foo, bar); // returns '0 bar'
foo(1, 2); // returns '1 2'
foo(1, 2); // fatal error because second argument threw exception
foo(1, 2) // returns '1 2'
foo(hi, 2) // fatal error because second argument threw exception
foo(hi, 2) // returns '0 2';
On Wed, Apr 29, 2015 at 2:39 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Christoph,
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de
wrote:
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com
wrote:
I agree with Stanislav here, if you want to accept any type of number,
its
easy enough to add your own checking to do that with the wonderful
is_numeric. And for simplicity, make an invalidArgument method that
you
can
call after manually checking if arguments are wrong: *
http://3v4l.org/r0qO0
http://3v4l.org/r0qO0* Works for all versions this tool runs as
well.
The issue is that weak mode type hint is *not* weak at all. It forces
to
have
machine native type rather than it's data form.
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn. It's too late for PHP 7.0 to re-open it,
but it might be reasonable to to so for PHP 7.1.
I don't think breaking a lot of code under 32 bit machines with PHP 7.0
is not good thing to do.
In addition, current code does not even allow GMP object as int.
http://3v4l.org/GiklL
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
Hi! This makes an opportunity to replace the old API with object oriented one preventing any kind of BC break. But instead of using this as an extension because of some limitations like “string”-startsWith(‘s’); the API should be bundled with the engine (not written in PHP). This is the problem with all these proposals. Instead of taking the gradual road of making a beautiful API in extension, having it accepted (I'm taking the optimistic scenario), popular and then merged into the engine, it's always let's redo the whole engine from scratch. That's why these things haven't gone beyond talk for years. I didn't say that you should redo the whole engine from scratch this is not possible of course taking the FIRST step would be great when i talked about 'extension' i mentioned the limitations. but i meant the API shouldn't be written in user land code that's all it can start as an extension and gradually support these limitations when more people start to use it. This will make the opportunity to also remove any inconsistencies in the API behavior as well. You write remove inconsistencies, I read break all existing code. you didn't get my point. i mean't the new API shouldn't behave the same as the old one there are some behavioural inconsistencies shouldn't be introduced in the new one. the old API won't be touched at all. no breaking for existing code. that's the point of this proposal I’ve seen many articles encouraging new comers to learn languages like Python or Ruby, and highly discourage them from using PHP. Also many new projects are using languages different than PHP. (don’t tell me you haven’t seen this) I've seen a lot of silly stuff on the Internet, so what? It's a free medium, anyone can write anything. That doesn't mean it carries any weight by the fact of writing. When the vast majority agree that's a problem (it carries weight). it's just too common. famous articles written about it like PHP fractal of bad design and php sadness a lot more i highly doubt that you didn't read one of these. i like PHP i care about it. it's future is important you the internals will decide what will happen many years from now. and you have a good opportunity to get this right. even if someone managed to do all of these things and submit an RFC you will vote on it. only you can decide i hope you chose the right thing. The old API should be deprecated in PHP 8.0 and removed completely in PHP 9.0 (finally) Which means no code written in PHP would work in PHP 9.0. Why then call it PHP? Call it something else. You just agreed on disagreeing :) this is 20 years until PHP 9 comes out. PHP 7 is not yet released. you can argue about it when we get to this point in time. maybe the need for removal can be predicted by the adoption of the new API. the old mysql extension was also used everywhere. BTW, if you look at Java, some methods deprecated in Java 2 are still around in Java 8. Java didn't die from it. Why people are so zealous to break things that work? i didn't mention any break or things. also many languages are different from they were 20 years from now. languages keep evolving. you may not see this as a breaking change 20 years from now imo Thanks for taking the time replying to this Regards
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
i didn't mention any break or things. also many languages are different Yes you did. You just proposed removing large part of PHP API. That would break things, there can be no confusion about it. I just agree with you. we shouldn't :) the old API will stay no one will ever remove it. If you propose *additional* API, that's fine - but before there's any talk about removing stuff, you should have the existing already overwhelmingly popular API in your hand. exactly i propose *additional* Object oriented API (not touching BC, no breaking) i suppose you agree with this and that's excellent. (i'm ready to help if you like) but you have much more experience with the engine and i hope you folks do it in the near future. this will be very important for the future of PHP. i am just waiting the YES it will happen. and that's enough for me. Thank you for taking the time replying to this. it's highly appreciated. Best Regards
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
This shouldn't be for PHP 7.0 ofcourse it's too late. it takes a lot of work and we don't want to get it wrong the second time :) but in any release before PHP 8 On Sat, Mar 21, 2015 at 10:25 AM, Pierre Joye pierre@gmail.com wrote: On Mar 21, 2015 2:15 PM, Levi Morrison le...@php.net wrote: I know that many people here will say that it’s not that important developers get used to this API and many tutorials based on it. As you guessed, I don't think this is so important that we should create a new fake object syntax for scalar. That's shooting a mouse with an elephant gun. I strongly disagree here. Plenty of discussions prove both the needs and the users willing to have such things. However it is too late for 7.0 ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
How you don't think this is so important ? i stated this because it's so predictable that someone will say it. Firstly why it's fake ? i prefer elegant maybe not the PERFECT solution ? i suggest that you compare the two choices. and what would you chose if you're a new comer. Secondly this is extremely important to the future of the language not only for the existing developers (if you read the email carefully i stated why)
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
I think that, while attractive, using the same syntax for object methods and scalar 'pseudo-'methods is too ambiguous. We just need to solve two issues : intuitive order of arguments and nested call readability. We don't need to implement the whole OO stuff for scalars. Except this detail, no limitation IMO. if you're going to write API for string manipulation for example you want it either Object Oriented or procedural style. because the API should be fluent method chaining etc. you don't want to stop the chain and wrap it with a function call. (just my opinion) these things needs to be discussed if the internals are willing to do it. it will happen ! i'm completely sure the many developers will support the new API and all of them are willing to help. i wrote some code imagining that we have the new API. PHP will just be so beautiful it will be a HUGE success. Regards
[PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
I know that many people talked about this over and over. Why it’s not possible to change the old PHP API ? The answer is always because it will make HUGE BC breaks I’ve seen this wonderful idea about scalar objects authored by nikic github https://github.com/nikic/scalar_objects. This will become even more possible when PHP 7 is introduced because of scalar types and many great features making the idea more reliable. This makes an opportunity to replace the old API with object oriented one preventing any kind of BC break. But instead of using this as an extension because of some limitations like “string”-startsWith(‘s’); the API should be bundled with the engine (not written in PHP). This will make the opportunity to also remove any inconsistencies in the API behavior as well. I know that many people here will say that it’s not that important developers get used to this API and many tutorials based on it. But it’s actually really important for the future of the language may be not so much for the existing developers (I disagree it’s). but this will also encourage new comers to use PHP. I’ve seen many articles encouraging new comers to learn languages like Python or Ruby, and highly discourage them from using PHP. Also many new projects are using languages different than PHP. (don’t tell me you haven’t seen this) This will be an issue the number of language users will drop significantly over the years causing the death of the language. I know that this is not an easy task. But this is a wonderful opportunity to do this without BC breaks. I’m not suggesting that this should be for PHP 7.0 because it will take a lot of work may be for any release in PHP 7.* PHP internals around 40 people ? not really sure but I know you are very busy with fixing bugs and you have a lot of work already if you think this is a huge task it can be assigned to a good group of people similar to how the amazing PHP Framework Interop Group has accomplished, for Designing the new Object Oriented API. PHP internals will vote on the design and implement it. The old API should be deprecated in PHP 8.0 and removed completely in PHP 9.0 (finally) I hope that you take this seriously and tell me if there are any limitations that prevents this from happening.
Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
I suppose calling it statically a user would probably want to recycle the same function/closure, so binding/calling it real time would have little impact if done properly. On Wed, Aug 20, 2014 at 2:30 PM, Levi Morrison le...@php.net wrote: On Wed, Aug 20, 2014 at 11:51 AM, Nathan nathan.br...@starin.biz wrote: The only thing I'd suggest is like I said in the last email is to make the syntax more like Closure::bind(Closure $closure, object $newThis, [mixed $newScope = 'static']) and make it Closure::apply(mixed $newObjectOrScope [, mixed ... $parameters]) $newObjectOrScope would then allow a user to supply a class name or an object. If class name is passed you have access to static::, self::, and parent:: inside the function everything else works as described in the RFC. Give the ability to call a closure as a static method of a class or a normal method of an object. Right now the only way to do it is doing binding and creating new closures and calling those closures then destroying them. I think you are confused. This proposal basically binds the closure to the new object and invokes it immediately. I genuinely don't see how it being statically bound to the object will make a difference. Please elaborate.
Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
The only thing I'd suggest is like I said in the last email is to make the syntax more like Closure::bind(Closure $closure, object $newThis, [mixed $newScope = 'static']) and make it Closure::apply(mixed $newObjectOrScope [, mixed ... $parameters]) $newObjectOrScope would then allow a user to supply a class name or an object. If class name is passed you have access to static::, self::, and parent:: inside the function everything else works as described in the RFC. Give the ability to call a closure as a static method of a class or a normal method of an object. Right now the only way to do it is doing binding and creating new closures and calling those closures then destroying them. On Wed, Aug 20, 2014 at 7:50 AM, Andrea Faulds a...@ajf.me wrote: Good afternoon, I’m putting this RFC to a vote again as I haven’t heard any objections in the past three days, and in the event something’s been missed, one week would be long enough to spot it. Vote is here: https://wiki.php.net/rfc/closure_apply#vote It ends 2014-08-27. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Closure::call()
I will +1 this as I have had to deal with some of these struggles, as a suggestion though: Like the bind(To) methods, a static class cannot be bound (using →call will fail) I would like to see this function work like Closure::bind()/Closure::bindTo() and give the option for the $newScope option. why would you need a closure that is not static, but is not bound to any object? I think I can answer this, I wrote a project which allows for hooks to be installed in areas of the code. I made it so each [static] method has a before and after which may be tied to it. This allows for things like: beforeUpdate() or afterUpdate or afterCreate exc... The framework handled the installation and execution of all hooks that a dev may have wished to install. If a method like this was available it would use much less resources and be faster in theory because the PHP engine would not need to create an entirely new object/closure every time I wished to execute the method. Simple example of what I spoke of above: https://gist.github.com/allada/b7e880104e3a7eb13a63 Notice how you don't need to create an entirely new object just to call a method inside a scope. This allows a dev to make their closure have access to $this just as if it was installed inside the function it's hooking into. On Mon, Aug 18, 2014 at 7:04 PM, Andrea Faulds a...@ajf.me wrote: On 18 Aug 2014, at 00:40, Levi Morrison le...@php.net wrote: On Sun, Aug 17, 2014 at 5:13 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! It does, but maybe you missed it. Under the Proposal section: To solve this, we relax the current invariant of scoped closures having to be bound, and add a new parameter to bind(To) to produce an unbound, scoped closure, like so: Indeed, I missed it - I was looking for bindTo. I think it should be made more prominent, and I'm not sure what closure that is not static, but does not have a bound object, means. What happens if you call it? It sounds a bit strange concept - why would you need a closure that is not static, but is not bound to any object? Hence the vote was cancelled while it is reworked. To clarify: The RFC has been reworked now, I actually changed the RFC and patch just before I cancelled the vote. Review appreciated before vote is reopened. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Method check - Can someone create a RFC for it?
Hi,
I'd like to suggest a new functionality for PHP. I don't know the
internals, and i can't create a patch implementing this. I'm writing here in
case someone likes this idea and write a RFC.
We've had a problem recently where one of our developers forgot an if.
So instead of writing
if ($obj-image) {
echo $obj-image-getUrl();
}
He wrote:
echo $obj-image-getUrl();
Here, locally, it was working cause we had the image. But when we updated
the online version we got a Fatal error: Call to a member function getUrl()
on a non-object cause someone didn't upload the image in one of the records
that we're on the home page.
Fatal errors like this can't be catched by a try/catch. And since this
getUrl() was not essential for the page, we'd better output an empty
string then having the site offline.
One might say: you guys should have tested it better, or The image
field should be mandatory in the back end.
And it's true, he should have written that extra if {}.
Examining this problem we happened to stumble open Ruby's and
Coffescript's method check.
Something like this:
$obj-image?-getUrl()?;
So my suggestion is:
Create something like $foo-bar?() or $foo-bar()?, where you don't care
whether the function exists, or if $foo is an object. If it doesn't exist
you just return null.
I guess there are plenty of systems out there where it's better to output
an empty string than having your site offline, just cause the programmer
couldn't test it completely.
Thanks for reading it.
Carlos Rodrigues
I do not like this idea. The error message Fatal error: Call to a member
function getUrl() on a non-object is very straight forward, it should tell
you the line the problem is on and everything and a quick glance should spot
the problem quickly. Granted Yes there are cases were it'd be nice to have
an easy work around, but then you run into the problem similar to what the @
has caused for many people, which libraries and general developers start
using it in many places to keep errors form being thrown and you end up with
code that is even harder to debug because no errors are shown. Another
solution that you could have used is to set $obj-image to a singleton
object that is a placeholder for methods like this which might be set...
something like: http://3v4l.org/utBWP
see: http://www.php.net/manual/en/language.oop5.overloading.php#object.call
But even that is a terrible solution, by showing the error fixed a bug...
bugs need to be fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Could we kill call_user_func?
Angel, On 18/03/13 14:04, Julien Pauli wrote: Also, AFAIR, call_user_func() doesn't work with functions using references in args. Julien.Pauli AFAIK it does. Do you have an example where it doesn't? It definitely does not: http://3v4l.org/C8Kme And if you try call-time-pass-by-reference, it gets worse: http://3v4l.org/pI89l Anthony Although it does not work with call_user_func() it does work with call_user_func_array() see: http://3v4l.org/GdUmM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory warning hook
As PHP applications are turning into large frameworks one of the issues arriving is memory management. One of the issues is that many frameworks use sophisticated caching techniques to make accessing the same data quickly, this improves speed it is at the cost of memory. Often the developer knows these areas that cache and often times already have functions in place to clear out the cache, however in the case where PHP is approaching or exceeds memory limits PHP runs the GC then dies if it cannot allocate enough memory. If we implemented memory warning triggers or user function that will be called before the GC is executed which allows the user to try and free up some memory on their own. This hopefully would give more flexibility to allowing these advanced caching techniques but at the same time allow the cache to be cleared out in case memory is getting low. Thoughts? Thanks, Software Developer Nathan Bruer
RE: [PHP-DEV] Memory warning hook
This is not the same at all. When are you going to run this code? Memory allocations happen all the time. What Nathan asked for is an event that is triggered when the memory consumption reaches a threshold. However, there is a different solution, which is better IMHO in the case of caches: weak references. A weak reference automatically frees the memory of the object, when the memory is needed. http://php.net/manual/en/book.weakref.php. Having said that, none of these solutions scale up to multiple servers. This is why shared cache systems like memcached are recommended. I agree this probably is a good solution and I personally do use it along with shared memory tools, however there may be cases where the dev may gain more benefit from having a memory-warning installable trigger in place. This would allow things like allowing the dev to release certain cache objects before others or something completely different that I have not thought of yet. Running the GC is most likely faster than most cleanup routines a user could run, also usually there is not that much stuff cached in PHP scripts. If a PHP script has tons of data, which it can easily throw away, in memory this sounds like a smell of an bad architecture. Cache cache-worthy stuff in memcache or such and fetch only the data you need. Also: What should happen if the system runs out of memory while doing the cleanup? Anything sane doesn't sound good either. Yes running the GC is much faster except they are two completely different processes... in my example the dev is keeping references to data for possible future use later on however it's not possible to know when to release these references so php's GC can collect them if the user does not implement something quite juristic like ticks or frequent function calls throughout a code base. You can use ticks :) http://php.net/control-structures.declare#control-structures.declare.ticks Yes Ticks are something useable (like said above) however I have found ticks are clunky, frequently shunned, and you'd be ticking for no reason most of the time. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [Reflection] Improve logic of ReflectionMethod-invokeArgs() for static methods
Maybe I can help explain a good example on were this is useful as I also
suggested this improvement and created the patch for it:
(http://bugs.php.net/bug.php?id=62113)
This is actually something I am using in one of my primary projects as a
framework (this example shows the concept not the actual code I am using). This
allows you to create new Models and extend (using traits) the specific
functions you'd like to attach to each extended model class.
/* Was a bit large so I posted here */
https://gist.github.com/4685694
There is a workaround so it was not super important for me to push for it to be
implemented (see commented code from line: 13-24).
Full breakdown of what it does:
There is a primary Model abstract class which pre-defines and forces certain
functions and variables to be set. There are various traits set which a user
may define themselves that allow certain parts of the code to be hooked into
and modify it's behavior without having to re-declare the entire function. The
advantages to this is that it allows new Models to be added and extended
without having to worry about replacing an entire function and losing any
potential updates to the original function and gives the ability for multiple
traits to hook themselves into specific functions. In this example I have 2
traits, Check_Permissions and Log_Changes which both do a dummed down
version of their job... If a certain Model needs to be logged for when changes
happen it can just add the trait Log_Changes to it and it will auto-hook into
the update and create functions. If a certain model needs permission checks to
update or insert it can extend the Check_Permissions trait. (although in my
example one extends the after function hook and the other extends the
before function hook, the idea of why it'd be useful is good enough).
Although yes there is a workaround, the workaround requires a new closure to be
created for each function being executed every time. but if the
ReflectionMethod::invokeArgs() function would allow the first argument to be
a string of class or the object itself it wants to bind too it would save a new
closure from having to be created for every hook being executed.
(Sorry for the long code, but I wanted to make sure I got my point across on
why it'd be useful)
Software Developer
Nathan Bruer
-Original Message-
From: Alexander Lissachenko [mailto:lisachenko...@gmail.com]
Sent: Monday, January 14, 2013 2:16 PM
To: Sebastian Krebs
Cc: PHP internals list
Subject: Re: [PHP-DEV] [Reflection] Improve logic of
ReflectionMethod-invokeArgs() for static methods
Probably, it will be better to give a link to the one of examples of AOP
integration for laravel framework (requires 5.4.10 to work):
https://github.com/lisachenko/laravel-aspect (just clone, install dependencies
and look at result)
I need to perform weaving of aspects into the original methods, so here is an
example of generated source code:
?php namespace Illuminate\Foundation;
class AliasLoader__AopProxied {
// .. source code here
/**
* Get or create the singleton alias loader instance.
*
* @param array $aliases
* @return Illuminate\Foundation\AliasLoader
*/
public static function getInstance(array $aliases = array())
{
if (is_null(static::$instance)) static::$instance = new
static($aliases);
$aliases = array_merge(static::$instance-getAliases(),
$aliases);
static::$instance-setAliases($aliases);
return static::$instance;
}
/**
* Load a class alias if it is registered.
*
* @param string $alias
* @return void
*/
public function load($alias)
{
if (isset($this-aliases[$alias]))
{
return class_alias($this-aliases[$alias], $alias);
}
}
// more source code here
}
class AliasLoader extends AliasLoader__AopProxied {
/**
*Property was created automatically, do not change it manually
*/
private static $__joinPoints = array();
// some source code here
/**
* Get or create the singleton alias loader instance.
*
* @param array $aliases
* @return Illuminate\Foundation\AliasLoader
*/
public static function getInstance(array $aliases = array())
{
return
self::$__joinPoints['static:getInstance']-__invoke(get_called_class(),
array($aliases));
}
/**
* Load a class alias if it is registered.
*
* @param string $alias
* @return void
*/
public function load($alias)
{
return self::$__joinPoints['method:load']-__invoke($this,
array($alias));
}
// some source code here
}
You can notice, that original class name is pointing to the decorator class
after weaving. Source code still use
RE: [PHP-DEV] C# properties vs. accessors RFC
Personally, I don't see why 'default' can't be used:
class Foo {
public $bar { get; set; default 5; } }
This solves the var_dump() problem, and if people want dynamic get
returning something other than the property/field value, so be it.
C# does indeed have an internal field per property though, even if it is an
anonymous backing field.
Is there a reason we cannot just have var_dump/print_r show it more like
this?
object(Time)#1 (2) {
[seconds]=
int(16200)
[hours]=
NULL
[hours:getter]=
float(4.5)
}
(Although I am against the idea of having a *hidden* value accessible inside
the getter/setter)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] __init magic method
I am actually going to +1 this idea I thought about discussing it, but opted
out of it because classes are most often in their own file and if you need to
do some static binding you can do it at the end of the file after the class
definition. However, I do believe this idea would make it easier to extend
classes and make the code look much cleaner.
@Johannes In your example I'd say it would be ADBCE because I would say it
should work like as if you had each one in it's own file autoloading them.
(also I believe the function would be static)
One of the potential problems I can see is the visibility
(public/private/protected) of the function as it'd likely need to be public
because it could never be auto-executed if anything else.
Software Developer
Nathan Bruer
-Original Message-
From: Johannes Schlüter [mailto:johan...@php.net]
Sent: Tuesday, January 22, 2013 7:04 AM
To: Pete Boere
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] __init magic method
Hi,
On Tue, 2013-01-22 at 12:29 +, Pete Boere wrote:
Has there ever been any discussion on an __init magic method for
bootstraping static properties on class load?
Adding an __init method as you wish will just add complexity and gain very
little. What complexity am I talking about? Well look at this single file:
?php
class A {
public function __init() { echo __CLASS__; }
}
class B extends D {
public function __init() { echo __CLASS__; }
}
class C {
public function __init() { echo __CLASS__; }
}
class D {
public function __init() { echo __CLASS__; }
}
class E {
public function __init() { echo __CLASS__; }
}
?
What should this print? ABCDE? Then the derived class B is initialized before
the base class D, which might have strange effects and make debugging hard. So
maybe it is ACDEB? This makes the resolution quite complicated.
On the other hand: You are showing a goos solution, which is clear and works
well. PHP has the global scope, we don't force everything into classes and then
create Java-style static{}-madness.
johannes
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new Class ReflectionZVal
I wanted some thought from you guys about the idea of giving PHP scripts the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
Class ReflectionZVal {
// Retains info about the variable referenced
function __construct($variable);
// Returns if the referenced variable
function valueExists();
// Returns a ref to the variable or throws error if value is gone.
function getValue();
// Returns the reference count of the variable
function getRefCount();
// Returns the current type associated with the referenced variable
function getType();
// Returns bool of if getValueReflection() is callable. (see note below)
function isValueReflectable();
// Returns a new instance of ReflectionZVal for the value of variable
passed in construct. (returns null and throws error if value is not a ref of
a variable)
function getValueReflection();
}
The idea of this class would give PHP the ability to read reference count
info and have read-only access to values stored in variables without causing
PHP to not be able to use the internal garbage collector. An example of how
this could be useful would be if you had a class structure that matched a
database table structure. Every time a new record of the table was returned
it constructed a new object. It is more practical to have the class store
each object that was constructed into a static variable attached to each
class structure and when a new record is requested it first checks to see if
the object with the same row has already been constructed and use/update
that object instead of making (possibly) many duplicates. This gives the
code structure the ability that if the same record was requested then later
in the execution the same row was requested again and modified it would also
modify it everywhere that object/row was already requested. The issue with
this structure is that php's garbage collector will never clean up those
constructed objects because the class needs a reference to them and cannot
know if other places in the code has references to them.
If a reflection like this one was available it would give the ability to
contain a reference to variables/pointers without increasing the reference
count. It would allow a class structure (like stated above) to call it's own
garbage collector every once in a while to clean up those ReflectionZVal
objects by checking the result of ReflectionZVal:: valueExists ().
Is there anything obvious (limitation wise) that I am missing or is this
RFC'able?
Software Developer
Nathan Bruer
RE: [PHP-DEV] new Class ReflectionZVal
From: Derick Rethans [mailto:der...@php.net] Sent: Monday, January 07, 2013 11:22 AM To: nat...@starin.biz Cc: internals@lists.php.net Subject: Re: [PHP-DEV] new Class ReflectionZVal On Mon, 7 Jan 2013, nat...@starin.biz wrote: function __construct($variable); That's inherently flawed, as passing a variable in can modify it's refcount and is_ref states. This is why Xdebug's equivalent wants a string with the variable name instead: http://xdebug.org/docs/all_functions#xdebug_debug_zval I am quite familiar with this issue. The idea I was thinking to solve that issue is to maybe pass by-reference to the __construct. When I was drafting this first email I had it by-ref, but opted out of it because I didn't have a way to get the value of the reference, but reviewing I added the function getValueReflection(); functions which should make it possible to use by-reference now and obtain the info to the reference of the reference. function valueExists(); What's a referenced variable here? If you pass in something, it will exist. The idea is that the value may not exist. This function would confirm that the value of the reflected zval still exists. My first draft of this email only had function getValue(); but I think it would create problems if it stated something like, Returns null if value does not exist because what if the value does exist (ie variable reference is still alive) but the value is null? This function (ReflectionZVal::valueExists()) would return false if the zval is gone (garbage collected). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object comparison
On Fri, Nov 9, 2012 at 2:00 PM, jpauli jpa...@php.net wrote:
On Fri, Nov 9, 2012 at 2:18 PM, Christian Stoller stol...@leonex.de
wrote:
I would like to place a suggestion for comparing objects (I hope it is
no problem, because this does not have anything to do with Sara's question
- but it came to my mind when I read her mail). It would be a great feature
if objects could be compared to other objects with , and the other
operators, like it is suggested in RFC https://wiki.php.net/rfc/comparable
The DateTime class offers this feature - it would be nice if this could
be made usable for userland classes/objects, too.
I really like that idea, and the patch looks pretty good and looks
backward compatible.
I'm +1 with it
I'm also +1 with patching the doc to describe the full default compare
behavior.
Another spot in the docs I would enjoy discussion about ,,=,= comparing
two objects:
http://php.net/manual/en/language.oop5.object-comparison.php
I notice this behavior is suggested in a comment for use in an
array_uintersect callback:
http://php.tonnikala.org/manual/el/function.array-uintersect.php#72841
Indeed, trying to intersect two arrays of objects with a user callback
'works' with the comparison operator, but maybe this is just luck, or
subject to BC break later?
?php
class myclass { function __construct($name) { $this-name = $name; } }
$o1 = new myclass('o1');
$o2 = new myclass('o2');
$o3 = new myclass('o3');
$o4 = new myclass('o4');
$a1 = array($o1, $o2, $o3);
$a2 = array($o3, $o2, $o4);
var_dump(array_uintersect($a1, $a2, function($v1, $v2) {
if($v1 === $v2)
return 0;
if($v1 $v2)
return 1;
return -1;
}));
I'd expect the comparison there to be roughly equivalent
to if(spl_object_hash($v1) spl_object_hash($v2)), no? Info on the
default behavior here would be nice.
-nathan
RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Is there a reason why we cannot implement this using PHP's already widely used
function syntax:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
public function get() { return $this-Seconds / 3600; }
private function set($value) { $this-Seconds = $value; }
/*public implied */function isset(){ return isset ($this-Seconds); }
private function unset() { unset ($this-Seconds); }
}
}
This would be much less confusing as it follows other PHP standards for
creating functions and such. I know C# has a similar syntax to what is
proposed, but we are not developing for C# we are developing for PHP which has
its own syntax rules that differ from C#'s and my vote is to follow PHP's
already in existent syntax format.
---
-Nathan Bruer
-Original Message-
From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of Etienne Kneuss
Sent: Tuesday, October 09, 2012 8:15 AM
To: Nikita Popov
Cc: Clint Priest; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi,
On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest cpri...@zerocue.com wrote:
It's been a while since I posted any updates about this, a few individuals
have been asking about it privately and wanting me to get it out the door
for PHP 5.5 release. It's come a long way since the last time I posted
about it.
RFC Document:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Example Usage:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
get { return $this-Seconds / 3600; }
set { $this-Seconds = $value; }
issethttp://www.php.net/isset { return
issethttp://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/unset($this-Seconds); }
}
}
Changes / Updates
* isset/unset accessor functions now implemented (object static
context, auto implementations, etc)
* static accessor now fully functional
* Reference functionality validated, tests written
* All operators have been tested, tests written
* read-only and write-only keywords: Added explanation of reasons
for inclusion at the top of the appropriate RFC section
* Tested for speed, approaches or meets __get() speed.
Internally things have changed quite a bit
* cleaned up and simplified
* had been using 4 to 5 additional fn_flag slots, now down to two
(READ_ONLY and WRITE_ONLY)
* the automatic implementations now compiled internal php code, this
greatly simplified that part of the code and future proofed it.
The code is available at the url below and is up to date with master, all
tests pass.
https://github.com/cpriest/php-src
I'd like to get this project wrapped up in time to make it to the 5.5
release, only a few things remain to be completed/updated:
* Check on reflection code written prior to major changes (tests
still pass)
* Add a few more reflection functions that were requested
In total there are 79 tests for this new functionality, if there are any
others that I have missed, please let me know.
What concerns me with the current implementation is that it leaks many
implementation details, in particular the fact that the accessors are
implemented as *real* __getXYZ methods and automatic implementations
also use *real* $__XYZ properties.
A few examples:
## 1 - __getProperty() method directly callable
class Test {
public $property {
get { return 123; }
}
}
$test = new Test;
var_dump($test-property); // int(123)
var_dump($test-__getProperty()); // int(123)
## 2 - __getProperty() method exposed via exception
class Test {
public $throwingProperty {
get { throw new Exception; }
}
}
(new Test)-throwingProperty;
exception 'Exception' in /home/nikic/dev/php-src/t29.php:9 Stack
trace:
#0 /home/nikic/dev/php-src/t29.php(31): Test-__getthrowingProperty()
#1 {main}
## 3 - Can directly access $__automaticProperty and even unset it
(causing notices in the internal code)
class Test {
public $automaticProperty {
get; set;
}
public function getAutomaticProperty() {
return $this-__automaticProperty;
}
public function unsetAutomaticProperty() {
unset($this-__automaticProperty);
}
}
$test-automaticProperty = 'foo';
var_dump($test-getAutomaticProperty());
$test-unsetAutomaticProperty();
var_dump($test-automaticProperty);
string(3) foo
Notice: Undefined property: Test::$__automaticProperty in
/home/nikic/dev/php-src/t29.php on line 13 NULL
=
I feel like this approach to the implementation will be a big can of
worms. Sure, it works, but it is rather fragile and the enduser ends
up dealing with internal stuff which he ought not care about. I think
Re: [PHP-DEV] Revisit: zend_call_method() - n number of arguments
On Sun, Oct 23, 2011 at 12:50 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! On 10/22/11 2:36 AM, Nathan Nobbe wrote: Hi, Another old issue I'd like to rehash with the upcoming release around the corner [1]. I patched 5.4 alpha2 for review [2]. I think better idea would be to add another API function (zend_call_method_ex?), that implements arbitrary argument count (either via array or via varargs) and make zend_call_method be a case of it, maybe. This way you don't have to break existing API and also don't have to stop at 4. Hi Stas, That's what this patch does, there is a new function zend_call_method_multi, which takes an array, and I've revised zend_call method to use it. I could change it to varargs if that is preferred. thanks, -nathan
[PHP-DEV] Revisit: Traits requiring composing class to implement interface
Hi folks, With a 5.4 release right around the corner I'd like a moment of your time to reconsider this issue [1]. I've read through the original conversation [2] and would summarize the points as follows: . several folks see value in the feature . the feature would not be an impedance for people who did not wish to use it . there was only one objection which was largely subdued The common use case of pairing traits with interfaces is the case where the feature adds value. Just curious why it died on the table if several folks saw value in it, including Stephan who I gather is the primary architect of traits. The dispute regarding the feature was the merit of a 'compile time' check vs placing the burden on the developer to ensure all methods in a trait are provided by the class in which it is used. In an earlier conversation about traits Stefan said this: Yes, Traits are meant to be compile-time only, they are not used to introduce typing relationships. Which makes me even more comfortable about the merit of another compile time check. As I argued in the original thread, the feature is merely an embellishment atop the already supported use of the 'abstract' keyword as it pertains to traits. And what if nothing else are features like PPP, abstract, interfaces etc than syntactic sugar? Plus it will save folks some typing :) [1] https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface [2] http://marc.info/?l=php-internalsm=129188077704898 thanks, -nathan
[PHP-DEV] Revisit: zend_call_method() - n number of arguments
Hi, Another old issue I'd like to rehash with the upcoming release around the corner [1]. I patched 5.4 alpha2 for review [2]. Seems like the most appropriate time for a patch of this nature is during a major release, per the previous conversation. According to Marcus the patch is reasonable: I explained to him the exact terms under which he can add the function. And his patch actually followed these terms as far as I could see. Would definitely help keep my PureMVC extension a little cleaner, if I ever get around to finishing it :) [1] http://marc.info/?l=php-internalsm=123493017101177w=2 [2] http://pastebin.com/zygKe9Y5 thanks, -nathan
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
I'm sure it will be a matter of time until those tools cook up a silly annotation to support it... Some of that is design choice, but I think we need to realize that there are a lot of people who have thought about these problems before in other areas of CS. What do other languages do? Can you name one mainstream language that implements traits/mixins as a first class citizen where they can implement an interface or can be type-hinted against? In fact, the original paper the RFC references (http://scg.unibe.ch/archive/papers/Duca06bTOPLASTraits.pdf) explicitly recommends separating the specification (interface) from the trait: A quote from that paper: We solved these problems by creating traits for the different collection properties and combining them to build the required collection classes. To achieve maximum flexibility, we separated the properties specifying the implementation of a collection from the properties specifying the interface. This allowed us to freely combine different interfaces (e.g., “sorted-extensible interface” and “sorted-extensible-immutable interface”) with any of the suitable implementations (e.g., “linked-list implementation” and “array-based implementation”). So in all, I feel it would be a significant mistake to allow traits (mixins) to implement interfaces or be type-hinted against. It goes against the principles that they were designed with and destroys some of their key benefits... A couple thoughts here. 1. I looked around in other language specs before re-hashing this topic and from what I can tell these other languages don't have a concept of interfaces as PHP does. One could say they do have classes proper and did not support traits noting the classes which they were dependent upon in their specification. Seems to me many of these other languages were more wholly conceived at their inception and I doubt the user base had been striving to implement multiple inheritance via a workaround for the past 5 years. Just google 'php multiple inheritance'. 2. For better or for worse the decision to support specification within traits has already been made in the form of the abstract keyword. I'm suggesting taking it one step further for folks who are interested in some semblance of multiple inheritance. If it's a nightmare to implement internally maybe it's best left alone, but if it is straightforward I say implement it and let folks take on 'all the problems of multiple inheritance' if they wish to; everyone else can just laugh at them if they wish to. Isn't that the PHP way? [1] http://www.issociate.de/board/post/478936/Multiple_Inheritance.html thanks, -nathan
Re: [PHP-DEV] Local PHP docs with search facility
On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson phi...@roshambo.org wrote: On Jun 2, 2011, at 2:46 PM, Richard Riley wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. But while we're here, pman is another option: $ pear install phpdocs/pman $ pman mysql_connect That'll show the mysql_connect() documentation as a local man page. not to shabby ;) and to Richard's question about search the -K option may be just the ticket. -nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Sun, Dec 12, 2010 at 7:25 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
Are there any objections to implementing this?
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
Do you intend to use traits as reusable implementations of interfaces? If
not, I could see why this feature isn't of interest to you :)
It also turns a trait into something more complex 'copy paste' code with
requirements/dependencies.
I think copy paste is a good way to conceptualize traits, but feel,
practically, they're a bit more complex than that w/ conflict resolution,
traits composed of traits, and the issue w/ attributes Stefan has brought
up. Essentially, there are already rules being added around the copy
paste concept. Also, this feature is mostly an extension of the abstract
keyword concept in traits, which they already support.
-1 on using 'require' (T_REQUIRE token), an option could be 'within'
trait IteratorUser within Iterator {
function foo() {
$next = $this-next();
...
}
}
class MyIterator implements Iterator {
with IteratorUser;
}
So the 'with/within' tokens would apply to traits.
I feel 'expect', 'need', 'require' etc sound better, matter of opinion
really, but it sounds like from an internals perspective it's preferred to
reuse existing keywords if possible.
Overall I feel -1, more use cases around Trait expresses a requirement for
the composing class would help, it seems like useful theory... not
convinced it's worth the trouble.
If you see the value in the abstract keyword in abstract classes or moreover
interfaces in general, I'd consider the value of this feature equal. Of
course not everyone uses abstract classes or interfaces :D
-nathan
Re: [PHP-DEV] Traits and Properties
On Sat, Dec 11, 2010 at 9:47 AM, Stefan Marr p...@stefan-marr.de wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property
names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get methods or an abstract get that returns a reference
to the property in the class.
However, at the moment it is possible to define properties in a trait:
trait Foo {
private $a;
public $foo;
}
For the moment, that information is completely ignored, thus:
class Bar {
use Foo;
}
property_exists('Bar', 'a') === false
Well, and that is a rather inconsistent status-quo.
I would like to have that fixed in one or another way.
One possibility would be to forbid property definition in a trait
altogether.
That reduces a bit the possibility to have wrong expectations about
properties, however, the dynamic property creation is still possible.
Another way would be to merge the properties in the composing class.
The question here would be how to treat visibility modifiers: how to merge
public and private, should it result in public, or private?
And, to discorage users to go this way, should there be a STRICT notice?
Options here are a notice whenever a property is defined in a trait, or
whenever properties are silently merged.
I would prefer they be definable within traits and merged into classes,
otherwise traits will not have the chance to be self-contained entities of
reusable logic. Also, I think merging them in is consistent with the
treatment given to methods as they pertain to traits.
As I'm sure you know:
?php
class A {
use SomeTrait;
}
trait SomeTrait {
public function traitMethod() {}
}
method_exists('A', 'traitMethod') === true;
?
Regarding visibility modifiers, why not carry them over from the trait
directly, private in the trait definition results in private in the class
definition. Lastly, I'm not sure why you would want to discourage this
usage, I would plan on adding properties in traits myself.
-nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Thu, Dec 9, 2010 at 4:04 PM, Stefan Marr p...@stefan-marr.de wrote:
Hi Nathan:
On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
What I'm getting at is the scenario when a trait is designed to be used
in
concert with the class in which it is being used. In this case the trait
expects certain functions to be available on the class in which it is
used
with. If the methods aren't there (or checked for at runtime) a fatal
error
is raised.
A quick example
?php
class A {
use AHelper;
function blah() {}
}
trait AHelper {
function meh() {
// hoping we get used w/ instances of A ...
return $this-blah() * 5;
}
}
class B {
use AHelper;
/// waiting for a runtime error if blah() is ever called ..
}
?
Do you see what I mean?
No, do not really see what you are getting at.
How is your approach using the instanceof checks (from the first mail)
different from changing AHelper to require blah() by stating this
requirement using an abstract method definition?
For the trait it is not important where that method is implemented, it just
has to be in the final composed class.
So, why don't you want the following trait?
trait AHelper {
abstract function blah();
function meh() {
// hoping we get used w/ instances of A ...
return $this-blah() * 5;
}
}
Ahh, I see how the abstract methods are working in traits now, I didn't
catch that from your first post; thanks for showing that to me.
You want to avoid the fatal error during runtime, right?
Yes, exactly, and the runtime check for expected interface / class / method.
Do you prefer dynamic checks over compile time checks?
Def not :D, however, I still think this paradigm is lacking. Don't you
think it makes more sense if I write a trait that expects a given interface
or class to be able to specify said interface/class in it's entirety with
just a single identifier rather than listing out all the methods?
For example, I think this would be ugly
?php
trait IteratorHelper{
abstract public current();
abstract public key();
abstract public next();
abstract public rewind();
abstract public valid();
}
?
essentially you're redeclaring the entire interface in the trait, the same
would be true of the public interface of an expected class. i think it
would be much more elegant to allow a specification on the trait declaration
itself, something like
?php
trait IteratorHelper expects Iterator {
...
}
?
-nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com wrote: First i have to say that I am not a PHP internals developer, but as a user I think it would maybe be better to just let the trait use the implements keyword, and copy that to the classes utilizing the trait? This is actually in the RFC as a rejected proposal http://wiki.php.net/rfc/traits#rejected_features But what I'm talking about is something different. We're not trying to say 'these are the methods implemented in the trait', rather, 'this trait expects a class it is used with to be of a certain type or implement a certain interface' for the trait to do its job. -nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com wrote:
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com
wrote:
First i have to say that I am not a PHP internals developer, but as a
user
I think it would maybe be better to just let the trait use the
implements
keyword, and copy that to the classes utilizing the trait?
This is actually in the RFC as a rejected proposal
http://wiki.php.net/rfc/traits#rejected_features
But what I'm talking about is something different. We're not trying to
say
'these are the methods implemented in the trait', rather, 'this trait
expects a class it is used with to be of a certain type or implement a
certain interface' for the trait to do its job.
-nathan
Shouldn't the burden be on the programmer to make sure the trait works
with the class using it rather than on the compiler? If they try to
use a trait that requires methods that don't exist, it will error out
anyway, so it won't be difficult to debug.
Well I know PHP is a dynamic language but what about all the compile time
features that have come along over the years. The abstract keyword for
example vs. the PHP4 way of implementing an 'abstract' method which was
triggering an error in the default implementation in a base class.
One of the main things a lot of PHP programmers I've worked with hate is
waiting for code to hit production and encountering a runtime error w/
something that could have been caught at compile time. I know the notion of
compile time in a scripting language like PHP is much less removed from that
of C++, Java etc, however there is a notion of it there, obviously.
Also, I would suggest this feature be optional, so there is no need to use
it if you don't like it. But for those of us who would like to defer as
much type checking to the compiler as possible so we don't need runtime
checks all over our code or prayers that we've tested every line before
production, it would certainly be nice.
Lastly, you may know that traits will allow PHP programmers to move away
from the delegate pattern which is a common workaround to multiple
inheritance at this point. However, in speaking with a colleague over the
concept I'm proposing yesterday we discovered the delegate model actually
does allow you to specify which class/interface the delegate is used w/, it
would be sad not to see comparable support in the trait feature which will
mostly eliminate the need for the delegate pattern, see my quick example.
?php
class MainClass {
private $_oDelegate = null;
function addDelegate() {
$this-_oDelegate = new Delegate($this);
}
}
class Delegate {
private function $_oMain = null;
/// delegate gets to say what it can be used with via type hinting
function __construct(MainClass $oMainClass)
{
$this-_oMain = $oMainClass;
}
}
?
Imagine how much cleaner this could be w/ traits, yet just as expressive
?php
class MainClass {
use Delegate;
}
trait Delegate require MainClass {
...
}
?
-nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-10, Nathan Nobbe quickshif...@gmail.com wrote: --0016e6dbe7fb8861a1049712ad63 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com wrote: On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com wrote: On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com wrote: First i have to say that I am not a PHP internals developer, but as a user I think it would maybe be better to just let the trait use the implements keyword, and copy that to the classes utilizing the trait? This is actually in the RFC as a rejected proposal http://wiki.php.net/rfc/traits#rejected_features But what I'm talking about is something different. We're not trying to say 'these are the methods implemented in the trait', rather, 'this trait expects a class it is used with to be of a certain type or implement a certain interface' for the trait to do its job. -nathan Shouldn't the burden be on the programmer to make sure the trait works with the class using it rather than on the compiler? If they try to use a trait that requires methods that don't exist, it will error out anyway, so it won't be difficult to debug. Well I know PHP is a dynamic language but what about all the compile time features that have come along over the years. The abstract keyword for example vs. the PHP4 way of implementing an 'abstract' method which was triggering an error in the default implementation in a base class. One of the main things a lot of PHP programmers I've worked with hate is waiting for code to hit production and encountering a runtime error w/ something that could have been caught at compile time. I know the notion of compile time in a scripting language like PHP is much less removed from that of C++, Java etc, however there is a notion of it there, obviously. To me, putting this into the language feels like overkill. Unless you're using an opcode cache, the notion of compile time as a differentiation from runtime in PHP has little relevance -- you still only find out when the script executes. *Only* if you hit the line of code at runtime that would destroy your script; often times this doesn't happen until it's too late, and the code has made it to production. And there is a notion of compile time in PHP, I'm not sure what it's referred to by the internals group, but abstract methods and interfaces definitely constitue compile time checks to me. There's already a way to mitigate this as well: write a testing suite for your application, and exercise it often. If you write your tests well (targeting the discrete behaviors of your application), then most likely they'll catch such errors -- allowing you to fix them before you deploy. Right, so you have to do tons of extra work (writing unit tests) which have to actually test every potential line of failure, when this could just simply be caught up front w/o any second guessing whether or not you've covered all cases in your tests. I'm not against unit tests at all, just saying it's much easier to guarantee you're safely using a trait w/ a compile time check rather than deferring the application author to test suite development. -nathan
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 12:39 PM, Chad Fulton chadful...@gmail.com wrote:
On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe quickshif...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com
wrote:
First i have to say that I am not a PHP internals developer, but as a
user
I think it would maybe be better to just let the trait use the
implements
keyword, and copy that to the classes utilizing the trait?
This is actually in the RFC as a rejected proposal
http://wiki.php.net/rfc/traits#rejected_features
But what I'm talking about is something different. We're not trying
to
say
'these are the methods implemented in the trait', rather, 'this trait
expects a class it is used with to be of a certain type or implement a
certain interface' for the trait to do its job.
-nathan
Shouldn't the burden be on the programmer to make sure the trait works
with the class using it rather than on the compiler? If they try to
use a trait that requires methods that don't exist, it will error out
anyway, so it won't be difficult to debug.
Well I know PHP is a dynamic language but what about all the compile time
features that have come along over the years. The abstract keyword for
example vs. the PHP4 way of implementing an 'abstract' method which was
triggering an error in the default implementation in a base class.
One of the main things a lot of PHP programmers I've worked with hate is
waiting for code to hit production and encountering a runtime error w/
something that could have been caught at compile time. I know the notion
of
compile time in a scripting language like PHP is much less removed from
that
of C++, Java etc, however there is a notion of it there, obviously.
Also, I would suggest this feature be optional, so there is no need to
use
it if you don't like it. But for those of us who would like to defer as
much type checking to the compiler as possible so we don't need runtime
checks all over our code or prayers that we've tested every line before
production, it would certainly be nice.
Lastly, you may know that traits will allow PHP programmers to move away
from the delegate pattern which is a common workaround to multiple
inheritance at this point. However, in speaking with a colleague over
the
concept I'm proposing yesterday we discovered the delegate model actually
does allow you to specify which class/interface the delegate is used w/,
it
would be sad not to see comparable support in the trait feature which
will
mostly eliminate the need for the delegate pattern, see my quick example.
?php
class MainClass {
private $_oDelegate = null;
function addDelegate() {
$this-_oDelegate = new Delegate($this);
}
}
class Delegate {
private function $_oMain = null;
/// delegate gets to say what it can be used with via type hinting
function __construct(MainClass $oMainClass)
{
$this-_oMain = $oMainClass;
}
}
?
Imagine how much cleaner this could be w/ traits, yet just as expressive
?php
class MainClass {
use Delegate;
}
trait Delegate require MainClass {
...
}
?
-nathan
As a note, I'm not strongly opposed to this proposal, since I don't
think it would do any harm. It just seems to me like a kitchen sink
feature.
The issue for me is that traits, as I understand them, are there
primarily for horizontal code re-use via compile-time copy/paste.
With that in mind, I feel like the developer is responsible for making
sure the methods they copy into their classes make sense, just as they
would have to do if they physically copied and pasted them.
Copy paste itself leads to duplicated unmaintainable code, so traits are
introduced (among other reasons) to prohibit this practice. Why not take it
a step further and let a trait definition be as expressive as possible,
eliminating ambiguity, right out of the gate?
I think your example above isn't quite what you meant to show, since
you're requiring a specific class and not an interface (since PHP only
allows one class definition for a class name, you're not gaining
anything via traits, since the trait could only be used for that
specific class, in which case why not just have the code in the class
in the first place?).
In retrospect Chad, that's a good point, and perhaps there is no reason to
allow marking of classes as required by traits.
If we take your example in a more general case using interfaces, I
still can't see what the benefit is. All it does is provide a more
explicit and immediate error message for developers (e.g. instead of
method not found error when the bad method call is made at runtime,
you get a classes using trait trait must implement
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 2:42 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-10, Nathan Nobbe quickshif...@gmail.com wrote: --0016e6d7e101e083a4049714bad3 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-10, Nathan Nobbe quickshif...@gmail.com wrote: --0016e6dbe7fb8861a1049712ad63 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com wrote: On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com wrote: On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com wrote: First i have to say that I am not a PHP internals developer, but as a user I think it would maybe be better to just let the trait use the implements keyword, and copy that to the classes utilizing the trait? This is actually in the RFC as a rejected proposal http://wiki.php.net/rfc/traits#rejected_features But what I'm talking about is something different. We're not trying to say 'these are the methods implemented in the trait', rather, 'this trait expects a class it is used with to be of a certain type or implement a certain interface' for the trait to do its job. -nathan Shouldn't the burden be on the programmer to make sure the trait works with the class using it rather than on the compiler? If they try to use a trait that requires methods that don't exist, it will error out anyway, so it won't be difficult to debug. Well I know PHP is a dynamic language but what about all the compile time features that have come along over the years. The abstract keyword for example vs. the PHP4 way of implementing an 'abstract' method which was triggering an error in the default implementation in a base class. One of the main things a lot of PHP programmers I've worked with hate is waiting for code to hit production and encountering a runtime error w/ something that could have been caught at compile time. I know the notion of compile time in a scripting language like PHP is much less removed from that of C++, Java etc, however there is a notion of it there, obviously. To me, putting this into the language feels like overkill. Unless you're using an opcode cache, the notion of compile time as a differentiation from runtime in PHP has little relevance -- you still only find out when the script executes. *Only* if you hit the line of code at runtime that would destroy your script; often times this doesn't happen until it's too late, and the code has made it to production. That's what good testing is about -- exercising all the expected behaviors of your code. If you hit an unexpected behavior in production, you add a test to your suite that reproduces it, fix it, and re-deploy. Right, and implementing an interface or subclassing an abstract class does not require a unit test in order to determine if I've at least met the obligations set forth by the interface or abstract class. The basic idea of a unit test is to write meaningful tests that actually offer you some milage for your time. I mean sure, I could write tests for setters and getters, but that's pretty much a waste of time compared to writing tests that actually get into semantics the class aims to provide. And there is a notion of compile time in PHP, I'm not sure what it's referred to by the internals group, but abstract methods and interfaces definitely constitue compile time checks to me. There's already a way to mitigate this as well: write a testing suite for your application, and exercise it often. If you write your tests well (targeting the discrete behaviors of your application), then most likely they'll catch such errors -- allowing you to fix them before you deploy. Right, so you have to do tons of extra work (writing unit tests) which have to actually test every potential line of failure, when this could just simply be caught up front w/o any second guessing whether or not you've covered all cases in your tests. Writing tests should not be considered tons of extra work; it should be considered a basic part of development. Shrug, taken out of context. I'm sure you can see how writing an extra word in the trait definition is much less work than including a unit test suite in your project and then a test against each class that uses the trait.., IMO, *that* is a ton of extra work. Even in the context of unit test writing a compile time check would eliminate the need of writing what I would consider bolier plate unit tests for traits. It's like, well I just wrote a trait, now any class I write against it I should go ahead and test that it provides all the methods for said trait .. that's just a waste of time
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Thu, Dec 9, 2010 at 1:09 AM, Stefan Marr p...@stefan-marr.de wrote:
Hi Nathan:
On 09 Dec 2010, at 08:44, Nathan Nobbe wrote:
Hi,
I think traits will lend themselves to frequent runtime checking against
the
type of class in which they were used. Consider a trait designed for use
with an Iterator class; the first thing might be to check the type of
$this.
Why would you need such a check?
To avoid a fatal error at runtime.
You want to ensure that the class that is using your trait obeys a certain
interface, right?
Not really, it's so the trait can guarantee the class it has been used with
implements a given interface that it may need to accomplish its job.
More specifically, you need it to implement a number of methods of an
interface, correct?
So, why not asking for it explicitly?
?php
trait InnerIteratorImpl {
abstract function next();
public function apply() {
do somthing with $this-next() ...
}
}
?
Does that what you want it to do?
Not really, in this example above the trait is self-contained, implementing
all the methods of a particular interface so it's reasonable to expect from
one of the methods in the trait, another of the Iterator interface to be
there.
What I'm getting at is the scenario when a trait is designed to be used in
concert with the class in which it is being used. In this case the trait
expects certain functions to be available on the class in which it is used
with. If the methods aren't there (or checked for at runtime) a fatal error
is raised.
A quick example
?php
class A {
use AHelper;
function blah() {}
}
trait AHelper {
function meh() {
// hoping we get used w/ instances of A ...
return $this-blah() * 5;
}
}
class B {
use AHelper;
/// waiting for a runtime error if blah() is ever called ..
}
?
Do you see what I mean?
-nathan
Re: [PHP-DEV] Project Management
On Wed, Dec 1, 2010 at 1:12 AM, Lester Caine les...@lsces.co.uk wrote: While a little off topic, I feel that it is worth our having a discussion on project management. Source control, and the like ... Current discussion on 'git' highlights the fact that there is no clear solution to source control. The switch TO SVN was pushed through even though a few problems with that were then coming to light and now that move is probably questionable. Projects that had not jumped have now put that on hold since DVCS is obviously the next step, but none of the current solutions are ideal and each have as many minus as plus points. The real problem that I am finding is that all of these 'systems' work on the basis that we are handling source code which will then be compiled. Managing code that is not compiled becomes something of a mess especially when it would be nice to maintain file versions in those script files, and running a 'build' process to restore the tidy CVS type headers then makes things difficult between different DVCS systems. Many core DVCS developers simply do not understand that there is NOT a final binary distribution? Personally I've been getting into something of a mess trying to manage distributing PHP projects that are version controlled via hg since the only real way is to install hg on all the target machines ... something which is not really practical? I do get told to just use rsync to clone the files to other machines, which is a little impractical when the target machines are windows or don't have internet access. Fortunatly the CVS original is still running and back porting is sorting out the distribution problem! git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) On top of that managing the release process to combine updates from other distributed code bases has already created the situation where there are 'sub-projects' which it is now difficult to integrate back with the original main project. this happens all the time in centralized models as well, its just a matter of how often the code is being synchronized. in the case of dvcs, it's likely the peripheral project has not re-based or merged recently / frequently enough. and on top of that, the main project maintainers didn't see enough merit to ever sync up the peripheral project anyway.., so the onus would rest on the developers of the sub-project. not too unlike those good ol svn days at the office.., where someone wouldn't commit for weeks at a time, wouldn't even update very often, and then shocked to find out their code isn't merging completely w/ other new features and production support going on the whole time... if you think about it, having the projects disjoint like that is actually doing favor to the maintainers of the main project. less clutter in the 'official' repo. this is actually impossible to attain in svn, since all branches in svn are tied directly to the central server. I think we need to start a more integrated discussion on the whole of this project management process so that we can come up with a usable approach that works more generally for scripted language projects? Add IDE's like Eclipse and to some extent Zend framework, and there is another layer of complexity that further fragments the overall requirements. I've never had a problem with 'merging' simply because Eclipse/BC handles that and is currently allowing me to untangle the current niggles! graphical tools are nice, but I think the underpinnings are more important in deciding which is best for use. svn merging has performance bound tightly to the network meaning, if you aren't running the merge on the box actually hosting svn, you'd better be running it from a box physically close or w/ a really high bandwidth connection. of course dvcs lets you run fast merges no matter where you are and let the actual synchronization run after the merge is done, like while you're sleeping say :) also, the svn merge tracking is convoluted, there's a lot to have to know at the user level just to get around it. I've found it a lot easier to trust the merges from git than I ever did svn, and actually ran svn 1.5 for a while with their merge-tracking, which doesn't work correctly without proper user interaction read: --reintegrate .. I'm not a core php dev, but I have dealt w/ a lot of version control, and frankly moving to git from svn was an even better move than cvs to svn, no doubt about it. -nathan
[PHP-DEV] Proposed - Integrated inner iterator support for Iterator classes
Hi everyone,
I've been taking another look at iterators lately, and compiled trunk and
started experimenting with traits. I also looked at an old mail from Marcus
regarding iterator_apply, and find myself wondering why there isn't just an
'apply' method as part of the Iterator hierarchy itself.
Although PHP had support for the pseudo-type callback when the Iterator
interface was introduced, I'm not sure why an 'apply' function would have
been omitted from the original Iterator interface. Clearly with
iterator_apply out there, there is no functional gain by adding a method
into the Iterator hierarchy, however I think it would be more cohesive with
the OO paradigm the Iterator hierachy presents .. there is already
array_walk and friends for the global function gang :) And now with
closures the idea of an 'apply' method is even more enticing .. yes I'm
thinking of Javascript code like JQuery's each() ...
I can tell why it wouldn't have been added after the original interface was
in the wild though, because changing the interface would break tons of
client code. However a second interface could be added and all client code
would continue to function
interface InnerIterator
{
function apply($mCallback [, mixed $...]);
}
Rather than extend Iterator, InnerIterator should be left independent so it
can be incorporated into implementors of OuterIterator (see below). Then
concrete Iterator(s) could implement this new interface as well
class ArrayIterator implements Iterator, InnerIterator { … }
I'm not sure what the best implementation at the engine level would be, but
with the advent of traits that would clearly be one option, a simple
implementation could be something like
trait InnerIteratorImpl
{
public function apply($mCallback)
{
$aArgs = func_get_args();
array_shift($aArgs);
$aCallbackArgs = array_merge(array($this), $aArgs);
return iterator_apply($this, $mCallback, $aCallbackArgs);
}
}
Then the ArrayIterator definition could become
class ArrayIterator implements Iterator, InnerIterator
{
use InnerIteratorImpl;
...
}
I hardly doubt this is necessary inside the engine, as I'm sure there can be
a common C function which is used to implement the interface, but that would
be for more educated people to decide.
Classes which implement IteratorAggregate (ArrayObject for example) would
then return implementors of InnerIterator, which still implement Iterator as
they originally did. Classes which implement OuterIterator could now also
implement InnerIterator as well, and the 'apply' method in that case can
simply delegate to the wrapped Iterator as they currently do for implemented
Iterator methods.
class CachingIterator implements OuterIterator, InnerIterator
{
public function apply($mCallback)
{
return $this-getInnerIterator()-apply(func_get_args());
}
}
A quick example from userspace with the addition
$oArrayObj = new ArrayObject(array(5, 4, 3, 2, 1));
$oArrayObj-getIterator()-apply(function(Iterator $oIt) {
var_dump($oIt-current());
return true;
});
At the end of the day it's just syntactic sugar since iterator_apply is
there, but in my book it would be welcome sugar ;) I would also argue that
even with traits, implementing this notion in userspace is slower (needless
conversion) and messy, imagine a subclass of ArryObject for example that
implements InnerIterator, inside of getIterator, it has to convert the
ArrayIterator to a new userspace class InnerArrayIterator or some such,
which implements InnerIterator, before returning it.
Your thoughts appreciated!
-nathan
[PHP-DEV] Revise callback Psuedo-type to support new Closure class ?
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it would make sense to allow the callback psuedo-type to also allow the new
Closure class to be an acceptable data type? A simple example that would be
nice to have working would be
?php
$fClosure = function($val, $key) {
echo $key = $val . PHP_EOL;
}
$aNumbers = array(5, 4, 3, 2, 1);
array_walk($aNumbers, $fClosure);
?
Thoughts ?
-nathan
[PHP-DEV] Re: Revise callback Psuedo-type to support new Closure class ?
Ummm... never mind!
Sorry for the noise!
-nathan
On Wed, Nov 24, 2010 at 11:00 AM, Nathan Nobbe quickshif...@gmail.comwrote:
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it would make sense to allow the callback psuedo-type to also allow the new
Closure class to be an acceptable data type? A simple example that would be
nice to have working would be
?php
$fClosure = function($val, $key) {
echo $key = $val . PHP_EOL;
}
$aNumbers = array(5, 4, 3, 2, 1);
array_walk($aNumbers, $fClosure);
?
Thoughts ?
-nathan
[PHP-DEV] Another question on traits
Hi,
Simas' question yesterday lead me to take a look at the RFC on the wiki and
I have a quick question.
Specifically on the 'Rejected Features' - 'Interfaces Propagation' section.
So it sounds like implementing an interface directly with a trait has been
shot down, what I wonder about is will it still work if a class implements
an interface and uses a trait which provides the functions in said
interface?
?php
interface IHello {
public function sayHello();
}
trait SayHello {
public function sayHello() {
echo 'hello world';
}
}
class MyHelloWorld implements IHello {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool (true)
?
An explicit way to leverage traits in the inheritance tree... Is that
accurate, or will that not work either?
thx,
-nathan
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Stan Vass wrote: It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) They do so because it looks like gibberish to them, so it looks unlikely to be a common thing you can Google, nor it gives something recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) Yes, we all acknowledge it's an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly causing support issues. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Makes sense, just alias it and change the error message thus keeping bc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Intermittent problem: can't write to properties of $this
On Thu, Oct 21, 2010 at 5:04 PM, Tim Steiner tstei...@nerdclub.net wrote: Greetings, I'm currently trying to troubleshoot an intermittent problem on one of our servers. After some time of running just fine (usually a couple of hours), scripts will start throwing the warning Attempt to assign property of non-object when writing to a property of the $this object. Once it starts, it seems to keep happening every few requests (with other requests running as expected). The poster at http://www.zfforums.com/zend-framework-components-13/core-infrastructure-19/warning-attempt-assign-property-non-object-zend_config-5469.htmlseems to be having the same issue. I've traced the warning output to line 576 of Zend/zend_execute.c, which means that something is happening to the write_property of the object. At this point, I don't have enough knowledge of the internals to continue tracking this bug down. Any help would be appreciated. Tim, this sounds much more like a typical userspace issue than an internals one. You might have better luck getting help if you start out on the php-general list. -nathan
[PHP-DEV] Using child classes/interfaces as desired type hints
Hi,
Probly rehashing an old conversation here, but I'm wondering why the
following isn't supported
?php
abstract class AbstractServer {}
class ConcreteServer extends AbstractServer {}
abstract class AbstractClient {
abstract function doStuff(AbstractServer $o);
}
class ConcreteClient extends AbstractClient {
function doStuff(ConcreteServer $o) {}
}
?
This results in a fatal
Fatal error: Declaration of ConcreteClient::doStuff() must be compatible
with that of AbstractClient::doStuff() in
/Users/quickshiftin/gitRepos/timberline/php-api-v15-client/testOverride.php
on line 11
I was reading a few posts from way back when
http://marc.info/?t=10777490481r=1w=2
yet still find myself wondering. I think it can be said here that if
there's a contract defined by AbstractClient::doStuff, that same contract is
honored by ConcreteClient::doStuff. I also think changing the language to
support this notion wouldn't raise BC issues for the most part (at all?)
since at the moment you're forced to move to the lowest common denominator
in the tree, in this case
class ConcreteClient extends AbstractClient {
function doStuff(AbstractServer $o) {}
}
your feedback appreciated,
-nathan
[PHP-DEV] Bug in 5.3 __invoke() magic method?
Hi,
Started using 5.3 and stumbled into what appears to be a bug with the
__invoke() magic method. It works fine if used in an object for a class
defining __invoke() is stored in a local variable, however when storing said
object as an instance variable, a fatal is raised. See my example below.
?php
class A
{
public function __invoke()
{
echo __CLASS__ . PHP_EOL;
}
}
class B
{
private $a = null;
public function __construct()
{
$this-a = new A();
$this-a();
}
}
$a = new A();
$a();
$b = new B();
?
Output:
A
Fatal error: Call to undefined method B::a() in
/Users/quickshiftin/gitRepos/timberline/ct-rip/test-callable.php on line 17
Expected Output:
A
A
thx,
-nathan
Re: [PHP-DEV] Bug in 5.3 __invoke() magic method?
On Wed, Sep 29, 2010 at 2:56 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
public function __construct()
{
$this-a = new A();
$this-a();
Here you are calling method a() of object $this. Such method does not
exist. No bug here. Methods are properties are different things.
Stas, thanks for this. Seems that w/ __invoke() in 5.3 if a method property
is_callable then the engine should check for that and call it. I realize
the problem now though, in php instance variables can have the same
identifier as instance methods therefore collisions could exist, for example
class B
{
function __invoke() {}
}
class A
{
public $c = null;
function c() {}
}
$a = new A();
$a-c = new B();
$a-c();
seems i got the notion this would work from javascript, however i also
realize the reason it works there, only a single identifier is allowed which
would map to either a scalar or a function object and in the later case
would be invokable.
the implementation in php make sense to me now.
thanks for your time,
-nathan
Re: [PHP-DEV] inheritance check too strict?
Jonathan Bond-Caron wrote:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is wrong but I was under the impression that the only way to
enforce a signature is using an abstract class or interface?
php allows it:
PHP 5.2.13 with Suhosin-Patch 0.9.7 (cli) (built: Aug 14 2010 16:39:00)
PHP 5.3.99-dev (cli) (built: Aug 20 2010 07:45:44)
?php
class P { function dot(Child $o) { echo .; } }
class Child extends P { function dot(P $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
class P2 { function dot (P2 $o) { echo .; } }
class Child2 extends P2 { function dot(Child $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
?
perhaps you mean..
$t = new Child2;
$t-dot( new P2 );
$t-dot( new Child2 );
:)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Johannes Schlüter wrote:
On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
Hi!
I was under the impression that, in order for inheritance to provide
proper polymorphism, overridden methods should share the parent's method
signature, although they can have additional optional arguments.
Your impression is wrong. Overriden method should have _compatible_
signature - i.e. accept any argument set that parent object accepted.
Nothing requires it to have the same signature.
Let|s take a look at making it one step more complex:
class A {
public function foo(Foo $a = null) {}
}
class B extends A {
public function foo() {}
}
class C extends B {
public function foo(Bar $a = null) {}
}
Here B::foo() is compatible with A:foo() and as the parameter is
optional C::foo() is compatible with B::foo(). But C::foo() is no more
compatible with A::foo().
So I consider the message good and correct.
what if Bar implements Foo, or Bar extends Foo - surely that should be
compatible given the inheritance chain.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Zeev Suraski wrote:
At 17:04 19/08/2010, Ionut G. Stan wrote:
I can't call Child::foo() with an instance of Taz, but I can call
Parent::foo() with such an instance. So, I can't use instances of
Child wherever instances of Parent would be accepted.
Child should clearly not be allowed to inherit Parent in the code above,
since the signature of Child::foo() is more restrictive than the
signature of Parent::foo(). The other way around could work (although I
don't recall if we allow it):
class Foo {}
class Bar extends Foo {}
class Parent
{
public function foo(Bar $bar){}
}
class Child extends Parent
{
public function foo(Foo $foo){}
}
No issues here - since any Bar object is also a Foo object and would
pass the is_a validation of Foo. Again, I don't recall if we allow such
signature overrides or not.
Zeev
Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a
real example - Zeev I've copied the way you specified above.
class Point2D { // Foo
public $x;
public $y;
}
class Point3D extends Point2D { // Bar extends Foo
public $z;
}
class Point2DManager { // Parent
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
class Point3DManager extends Point2DManager { // Child extends Parent
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
You're saying that makes sense and is no problem? honestly?
Best,
Nathan
ps: no offence / nothing personal just want to get this cleared up
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Chris Stockton wrote:
Hello,
On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham nrix...@gmail.com wrote:
Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a real
example - Zeev I've copied the way you specified above.
I think your misunderstanding his position. To summarize my
understanding: he clearly states that in such a use case a warning is
in order, however currently the warning is overly aggressive. I think
in general this is a small fish in the pond but I see his point.
Perhaps I am, I think his example was wrong - if it was an example of
doing it the wrong way and an example which should trigger a warning
then yes I totally agree.
To clarify, hopefully - given:
class Point2D {}
class Point3D extends Point2D {}
the following is incorrect and should raise a (heavy) warning (Zeev's
example with class names changed for clarity):
class Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
whilst the following is correct, and should not raise any warning:
class Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
If we're all saying the same thing then great and apologies for the
confusion.
Best,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
postmas...@colder.ch wrote:
- Nathan Rixham nrix...@gmail.com wrote:
class Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
This is incorrect. Any class extending Point2DManager should be able to provide
at least as much functionality as the parent class. In other words, it should
not tighten the pre-conditions.
In your case, Point3dmanager will no longer be able to handle 2dpoints, which
is a mistake.
lol, got it - confused myself for a bit there! yes agreed..
incorrect:
class Parent { function equals(Parent $o) {} }
class Child extends Parent { function equals(Child $o) {} }
correct:
class Parent { function equals(Child $o) {} }
class Child extends Parent { function equals(Parent $o) {} }
sorry about the noise,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPKAC support for openssl in PHP
Hi All, Wondering if there is any support for SPKAC [1] in the openssl extension for PHP? If not is it planned, and if not can it be? KEYGEN/SPKAC support is growing in the UA vendors and KEYGEN is part of HTML5, being the preferred way to generate client side SSL certificates since the private key never leaves the browser. Further the need for client side certificate generation will be growing somewhat over the next couple of years thanks to FOAF+SSL - which I believe is about to start going through standardisation. At the minute we have to take a rather hacky approach in PHP [2] and it get's much worse if you want to use x509 v3 extensions, you have to go through a nasty process of using a bash script to gen a custom openssl.conf on the fly to use in the SPKAC request. Best, Nathan [1] http://en.wikipedia.org/wiki/Spkac [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/07ea5534/attachment.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SPKAC support for openssl in PHP
Moving forwards a lot of authentication will be done in an HTTP friendly stateless manner, namely via HTTPS where the user is identified by client side ssl certificates. In order to give the user a certificate, you need to generate one, which you can currently do with openssl in php, and provide the user with a pkcs12 certificate+private key to install. However, pkcs12 has a security flaw in the the application giving the certificates also has the private key. SPKAC addresses this because the private key never leaves the users browser, thus it is the preferred option - and as mentioned there will be an ever increasing need for this in PHP once HTML5 takes off (due to the KEYGEN element which is widely supported already) and FOAF+SSL which as I mentioned will be going through standardisation in the near future. Best, Nathan Sriram Natarajan wrote: I am curious as to why you need this feature within PHP. I would expect that web server administrators typically need such feature but I am missing the context of it within PHP script engine. - Sriram On Tue, May 18, 2010 at 2:05 AM, Nathan Rixham nrix...@gmail.com wrote: Hi All, Wondering if there is any support for SPKAC [1] in the openssl extension for PHP? If not is it planned, and if not can it be? KEYGEN/SPKAC support is growing in the UA vendors and KEYGEN is part of HTML5, being the preferred way to generate client side SSL certificates since the private key never leaves the browser. Further the need for client side certificate generation will be growing somewhat over the next couple of years thanks to FOAF+SSL - which I believe is about to start going through standardisation. At the minute we have to take a rather hacky approach in PHP [2] and it get's much worse if you want to use x509 v3 extensions, you have to go through a nasty process of using a bash script to gen a custom openssl.conf on the fly to use in the SPKAC request. Best, Nathan [1] http://en.wikipedia.org/wiki/Spkac [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/07ea5534/attachment.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Richard Lynch wrote: I have taken the liberty of making an RFC for this: http://wiki.php.net/rfc/url_dots Feel free to add/edit it as fit, particularly since it's my first use of that RFC wiki, and I'm not good at wiki markup, and I probably missed something from this thread. I intentionally left out the ?a_b=1a.b=2 because that seemed to me to be beyond the scope, since ?a_b=1a_b=2 is equally problematic in PHP... That said, I am now leaning towards not trying to be BC, and just dropping 'a_b' entirely. It seems unlikely that anybody doing anything sane to attempt to reconstruct their original keys is going to be hurt by PHP not messing them up anymore. Most likely, their revisionary code is simply not going to find any 'a_b' to blindly revert to 'a.b' anymore, and the 'a.b' is going to just sail through. Of course, their a.b might be a^b or a*b or whatever, but whatever it is, PHP not messing it up will just mean their code won't find anything to un-do any more. I did think of one other issue though: There may be some really funky character that is valid in the URL, but that is not kosher for an array/hash key which is currently being masked... It would still have to be masked if such a character exists... I can't think of any such character, but what with i18n of DNS records and whatnot these days, I am woefully ignorant of what might be in the keys. I put that into the RFC already. Thanks Richard, I was struggling to get to time to write this up - all seems fine to me and just as discussed on-list. Thanks again, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Tim Starling wrote: Stan Vassilev wrote: I hope PHP6 will remove this processing as register_globals will be completely removed at that point. I'd be happy if it stayed like it is, for backwards compatibility. Sometimes forwards compatibility has to take precedence though. Linked data is set to explode around the net over the next year or two; general form fields will soon be replaced with properties from ontologies (such as foaf), people will have personal rdf graphs housed in their browsers and autocomplete will populate forms where the property uri's are known; if these form elements all contain uri's with dots swapped out with underscores then this could be a potentially big problem for the giant global graph and PHP developers specifically. All solved very easily by being able to ini switch this replacement feature on and off. on the server side.. http://example.org/ontology/0.1/some_property becomes http://example.org/ontology/0_1/some_property how do you reverse replace the correct underscore with a dot? if we use the input name=data[http://example.org/ontology/0.1/some_property]; / workaround in userland this is no doubt breaking many future browser extensions looking for input name=http://example.org/ontology/0.1/some_property; / quite sure a small patch and ini switch would cater for both BC and FC in this case; even if it was removed all together then to achieve bc would be a simple for loop and str_replace; hardly major. regards! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Alexey Zakhlestin wrote: On 21.01.2010, at 18:21, Richard Lynch wrote: For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet another php.ini flag (sorry!) to choose the behaviour. -1 from me. I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all. It would be absolutely enough to add optional var-name conversion to extract() any word from anybody on the development team to say if this removal of dot conversion (whether optional or not) can be added to some todo list or suchlike and rolled out at some point soon~ish? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Dots and spaces in variable names are converted to underscores.
Dots and spaces in variable names are converted to underscores. For
example input name=a.b / becomes $_POST[a_b].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
reason, when building linked data / rdf based applications using PHP
it's most beneficial to use subject / predicate URIs (eg
http://xmlns.com/foaf/0.1/mbox) as form input names.
also worth noting that if you send:
input name=a.b[c.d] /
you'll receive the following in php:
$_POST[a_b] = array('c.d' = val)
note no conversion of c.d to c_d
regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoloading and undefined class constants
On Sun, Jul 5, 2009 at 10:21 PM, Ben Bidner b...@vuetec.com wrote:
per the manual, exceptions thrown in an autoload method are swallowed,
and an E_ERROR is triggered by php.
http://us2.php.net/manual/en/language.oop5.autoload.php
I have read that note before, and wondered exactly what it was referring to
since you can throw exceptions within an autoloader and catch them (or have
your exception handler do whatever it needs to do with them).
?php
function autoloader($className)
{
echo autoloading . PHP_EOL;
throw new Exception(Fail);
}
spl_autoload_register(autoloader);
try
{
// Exception
$obj = new NonExistentClass;
}
catch(Exception $e)
{
echo caught . PHP_EOL;
}
try
{
// Exception
$const = constant(NonExistentClass::NON_EXISTENT_CONSTANT);
}
catch(Exception $e)
{
echo caught . PHP_EOL;
}
try
{
// Fatal error
$const = NonExistentClass::NON_EXISTENT_CONSTANT;
}
catch(Exception $e)
{
echo never happens . PHP_EOL;
}
?
Will output:
autoloading
caught
autoloading
caught
autoloading
PHP Fatal error: Undefined class constant
on both my systems (mentioned in reply to rob) the script fatals after the
first autoloading, just like the manual says..
nat...@trident2:~$ php testcode.php
autoloading
Fatal error: Class 'NonExistentClass' not found in /home/nathan/testcode.php
on line 41
-nathan
Re: [PHP-DEV] autoloading and undefined class constants
On Sun, Jul 5, 2009 at 8:49 PM, Ben Bidner b...@vuetec.com wrote:
Hi folks,
Just looking for a quick clarification on how class constant look ups are
performed internally under circumstances when an autoload function is also
called.
Consider the following example:
?php
function autoloader($className)
{
throw new Exception(Fail);
}
spl_autoload_register(autoloader);
?
?php
// Exception
$obj = new NonExistantClass;
?
?php
// Fatal error
$const = NonExistantClass::NON_EXISTANT_CONSTANT;
?
I would have assumed that since the autoloader threw an exception while
attempting to load the non existant class, that internally, there would be
no attempt to access the non existant constant (since surely that comes
after the exception was thrown???) and we would get the Exception, rather
than a Fatal error.
Intended or a design error?
per the manual, exceptions thrown in an autoload method are swallowed, and
an E_ERROR is triggered by php.
http://us2.php.net/manual/en/language.oop5.autoload.php
personally, i dont know why it works this way.. even if you register an
error handler, you cant handle it from user-space, b/c set_error_handler()
only lets you handle E_USER_ERROR.. there are 2 issues this presents,
1. if your autoloading logic creates a message that it would pass through to
higher level code, via exceptions or errors, they are swallowed, so you dont
know what went wrong.
2. if you call die() you can log the message, however youll not be able to
leverage standard error handling code here, at least not via a thrown
exception or triggered error
the only solution ive found is to invoke the standard error handling code
directly from the autoloading logic.
imo, this defeats the purpose of the loose coupling errors and exceptions
provide. one of the reasons its really painful is because the autoloader is
startup code.., which means you cant leverage it to load its dependecies,
which means your error logging code cant leverage the autoloading logic iff
the autoloading logic has to call the error handling logic directly:( when
i say 'standard error handling logic' i mean like loading up a static html
page, or similar.
i think, since failures in autoload result in an E_ERROR, it would at least
make sense to allow user-space to trigger E_USER_ERROR, which PHP could
allow to pass through the autoload method untouched. i think this is
reasonable, b/c E_USER_ERROR still interrupts program execution, and then
userspace could leverage the same error handling code it does for everything
else when problems occur with autoloading.
id seen some posts on php.net about using output buffering to be able to
trap E_ERROR but then came to discover that output buffering has been
disabled on the cli since like 4.3.5, so the example code like,
?php
ob_start();
call_fake_function();
?
would blow up w/ a fatal on all my installations. id post on php-general
about it, but im more curious to see what internals folks think about it.
-nathan
Re: [PHP-DEV] need inverted __sleep?
Jonathan Tapicer wrote:
Hi,
Matt's approach works also for your usecase, casting to array returns
all the properties of the class and base classes, but it has some
problems: for private properties the class name is added before the
property name, and for protected properties * is added, both things
added are between null characters, so you can remove the added string
with some regexp.
Another approach that will work is using ReflectionClass and the
method getProperties, it will return all the properties (even
private), but only of the class itself, it won't return the properties
declared in base classes, you have the get the base class
(get_parent_class) and recursively do the same thing for all the base
classes.
Regards,
Jonathan
doh, thanks Jonathan and thanks Matt - completely missed that (array)
even though I'd been using it in a different attempt using Serializable
small note is that you do not need to remove the class names or
suchlike, this works fine (and I assume is faster than recursive reflection)
public function __sleep()
{
$exclude = chr(0) . __CLASS__ . chr(0) . 'notToBeSerialized';
return array_diff(array_keys((array)$this) , array($exclude) );
}
again thanks, and apologies Matt!
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] need inverted __sleep?
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is to
serialize($this) then parse the string, but that's just wrong and what
would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need inverted __sleep?
Matt Wilson wrote:
get_class_vars + array_diff
cheers but nope; as the manual says
Returns an associative array of default public properties of the class
need private and inherited private
On May 31, 2009, at 8:04 PM, Nathan Rixham wrote:
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is to
serialize($this) then parse the string, but that's just wrong and what
would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need inverted __sleep?
matt.. that's public properties on a single class - see the usecase
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
Matt Wilson wrote:
mwil...@mattw-mac:~$ php -r 'class a { public $a, $b, $c, $d; public
function __sleep() { return array_diff( array_keys( (array) $this),
array(b,c)); } } $a = new a; var_dump($a-__sleep());'
array(2) {
[0]=
string(1) a
[3]=
string(1) d
}
On May 31, 2009, at 8:46 PM, Nathan Rixham wrote:
Matt Wilson wrote:
get_class_vars + array_diff
cheers but nope; as the manual says
Returns an associative array of default public properties of the class
need private and inherited private
On May 31, 2009, at 8:04 PM, Nathan Rixham wrote:
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is
to serialize($this) then parse the string, but that's just wrong and
what would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why does $_REQUEST exist?
Michael Shadle wrote:
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
bc? all the reasoning in the world won't justify it to 1 million
businesses running php 4 code which is reliant on $_REQUEST behind the
scenes.
although it would generate a tonne of freelance work :p
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] non static function called as static one
On Wed, Mar 11, 2009 at 3:16 PM, Olivier Doucet webmas...@ajeux.com wrote:
Hello,
I posted the same topic on the general mailing list, but it appears this
can
be posted here, as it is open to feedbacks and is about PHP implementation
of static functions.
I'm wondering if the following behaviour is a bug or a feature. The case is
quite complex, so let me explain my point of view.
here is the source :
?php
class MyTest {
public function myfunc() {
echo get_class($this);
}
}
class MySecondTest {
public function test() {
MyTest::myfunc();
}
}
$test = new MySecondTest();
$test-test(); //output: MySecondTest
?
not sure if this was mentioned on the general list but, i believe what youre
describing is documented in the manual under php5 classes/objects - the
basics:
http://www.php.net/manual/en/language.oop5.basic.php
$this is a reference to the calling object (usually the object to which the
method belongs, but can be another object, if the method is called
statically http://www.php.net/manual/en/language.oop5.static.php from the
context of a secondary object).
-nathan
Re: [PHP-DEV] non static function called as static one
On Wed, Mar 11, 2009 at 4:40 PM, Olivier Doucet webmas...@ajeux.com wrote:
Hi,
not sure if this was mentioned on the general list but, i believe what
youre describing is documented in the manual under php5 classes/objects -
the basics:
http://www.php.net/manual/en/language.oop5.basic.php
$this is a reference to the calling object (usually the object to which
the method belongs, but can be another object, if the method is called
statically http://www.php.net/manual/en/language.oop5.static.php from
the context of a secondary object).
-nathan
I know this behaviour is fully documented, but I was more concerned about
is it a 'normal' behaviour ?. How can a programmer controls the class he
wrote, and make it absolutely bugproof ? How can he detect his function was
called in a static context and forbid it (or write specific code for) ?
well, the access to $this of the secondary object is limited. so the only
way it really does anything useful is if member variables you wish to access
are marked as public; making it mostly useless imo.. but anyway all youd
need to do is mark member vars as protected or private. (personally, i think
it should be able to access protected vars, since the class which invokes
the other statically is essentially sanctioning access to its instance
variables).
?php
class A {
public function showOtherClassInstanceVar($varname) {
var_dump($this-$varname);
}
}
class B {
public $a = 1;
protected $b = 2;
private $c = 3;
public function dumpViaMixin() {
A::showOtherClassInstanceVar('a');
A::showOtherClassInstanceVar('b');
A::showOtherClassInstanceVar('c');
}
}
$b = new B();
$b-dumpViaMixin();
---
outputs
int(1)
then the error log shows,
[11-Mar-2009 17:01:03] PHP Fatal error: Cannot access protected property
B::$b in /Users/nnobbe/testDelegation.php on line 5
[11-Mar-2009 17:01:03] PHP Stack trace:
[11-Mar-2009 17:01:03] PHP 1. {main}() /Users/nnobbe/testDelegation.php:0
[11-Mar-2009 17:01:03] PHP 2. B-dumpViaMixin()
/Users/nnobbe/testDelegation.php:22
[11-Mar-2009 17:01:03] PHP 3. A-showOtherClassInstanceVar()
/Users/nnobbe/testDelegation.php:16
so you should be able to protect your classes w/o too much trouble.
-nathan
Re: [PHP-DEV] Adding/Updating ZVal Arrays to Object
On Fri, Feb 20, 2009 at 12:31 PM, Matthew C. Rice mr...@rcs.us wrote:
Hello everyone,
I am building a custom PHP Extension. It is object based, and while the
documentation seems to be lacking a little on this aspect in extensions, I
haven't let that slow me down. I have used other extensions as examples, and
done a great deal of searching around to find everything I have needed until
now.
I currently have the following http://pastebin.com/m74c98b43 ( the
start method ) in my classes __construct ( I actually use PHP_MALIAS to
alias __construct to the function ) .. This works perfect. It creates a
array in the object, just as I expect it to.
I can even print out the number of elements and their values in the
debug function by passing $Obj-Property to it
The problem I am having is that I can't seem to figure out a way to
append values on to the ZVal Array in another PHP_METHOD(). I have tried
combinations of zend_hash_find() zend_hash_update() to no avail. Is
there anyone that might be able to point me in the right direction as to how
to do this?
i think mainly you just need to read the zval from the instance, operate on
it, then update the instance. heres some working code from the extension
ive been working on,
/* {{{ proto public void MacroCommand::addSubCommand(string commandClassRef)
add a subcommand to this MacroCommand */
PHP_METHOD(MacroCommand, addSubCommand)
{
zval *this, *subCommands, *subCommand;
char *rawSubCommand;
int rawSubCommandLength;
if( zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s,
rawSubCommand, rawSubCommandLength) == FAILURE) {
RETURN_NULL();
}
MAKE_STD_ZVAL(subCommand);
ZVAL_STRINGL(subCommand, rawSubCommand, rawSubCommandLength, 1);
this = getThis();
zend_class_entry *this_ce = zend_get_class_entry(this);
subCommands = zend_read_property(puremvc_macrocommand_ce, this,
subCommands,
sizeof(subCommands)-1, 1 TSRMLS_CC);
ZVAL_ADDREF(subCommand);
add_next_index_zval(subCommands, subCommand);
zend_update_property(puremvc_macrocommand_ce, this, subCommands,
sizeof(subCommands)-1,
subCommands TSRMLS_CC);
}
/* }}} */
and heres my unit test for this method,
--TEST--
MacroCommand::addSubCommand(), ensure addSubCommand actually stores the
ICommand in an internal array
--SKIPIF--
?php if (!extension_loaded(pure_mvc)) print skip; ?
--FILE--
?php
class SubCommand {}
class MyMacroCommand extends MacroCommand {
protected function initializeMacroCommand() {
$this-addSubCommand('SubCommand');
}
}
$macroCmd = new MyMacroCommand();
var_dump($macroCmd);
?
--EXPECT--
object(MyMacroCommand)#1 (2) {
[facade:protected]=
string(0)
[subCommands:private]=
array(1) {
[0]=
string(10) SubCommand
}
}
hope this helps,
-nathan
Re: [PHP-DEV] Adding/Updating ZVal Arrays to Object
On Fri, Feb 20, 2009 at 3:02 PM, Matthew C. Rice mr...@rcs.us wrote: Nathan, Thanks a bunch. That was exactly what I was looking for. word Is there any place you would consider a good resource to learn/get documentation for these functions? my secret weapon, http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/067232704X :D but youll still have to do all the things youre doing now. digging through other extensions, looking through the code under the Zend directory and so forth.. the book just makes things *way* easier to get the ball rolling. -nathan
Re: [PHP-DEV] Re: Adding a property to an object
On Fri, Feb 20, 2009 at 3:45 PM, Matthew C. Rice mr...@rcs.us wrote: David, I personally have not read that book, as I actually heard pertaining to objects ( where I too have had some issues ) it wasn't really a terrific reference. Though if this is not the case, I would love to hear otherwise.. i found the oop section a bit lacking. one of the main issues is that the chapters are titled php4 objects, php5 objects, but really overall material is spread between the two chapters. like the section working with instances in the php4 objects chapter. where was its counterpart in the php5 objects chapter? what you begin to realize is a lot of the things are exactly the same, but i thought at least the organization was a bit awkward. also, im not sure if when zend_call_method and its variants appeared, i suspect after the books publication perhaps. that seems to be the way to go, calling class/object methods. the book illustrates call_user_function() which by comparison is really painful in working w/ objects imo. all-in-all though id say the book is solid. ive been able to accomplish everything ive wanted so far with my first extension. i dunno, ive not worked with a lot of C api's so far, but i think id probly have struggled getting started w/o the book. -nathan
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
did you guys see the other patch i posted yesterday? i re-read Johannes' first reply yesterday and saw the bit about a second api for a zend_call_method with a variable number of parameters. so a made a new function then re-implemented zend_call_method based on that. heres the patch (easier to read on pastebin). http://pastebin.com/m4fd58822 im sure it could be tweaked, but i think the main point is using an array rather than va_list to support the varialbe arg list. is this any better than the first one ? thanks, -nathan
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
On Wed, Feb 18, 2009 at 6:16 AM, Johannes Schlüter johan...@php.net wrote: But I don't think that a new limitation is any better: Tomorrow we have to change it again as somebody has a reason to use 5 parameters, so if it is changed it should be changed to take any number of arguments and no fixed limit (or add a new API for that) that does seem ideal to me, but in the last thread, marcus was clear that an emalloc / va_list solution was unacceptable. that was last january.. has anything changed in that regard since? also, it sounded like he was saying a simple solution for up to 4 parameters would be alright. mainly i thought it would be nice to get it into the code for 5.3 before we'd have to wait for another major release in order to get something included. yes, perhaps the function would need updating again in the future, but since people are using macros rather than zend_call_method directly it wouldnt be too bad right? -nathan
[PHP-DEV] zend_call_method() - support for up to n params - no va_list
On Wed, Feb 18, 2009 at 6:16 AM, Johannes Schlüter johan...@php.net wrote:
But I don't think that a new limitation is any better: Tomorrow we have
to change it again as somebody has a reason to use 5 parameters, so if
it is changed it should be changed to take any number of arguments and
no fixed limit (or add a new API for that)
given Johannes' feedback this morning, i created another patch, which adds
zend_call_method_va(), it accepts an array of zvals. then i changed
zend_call_method() to build the array and call zend_call_method_va().
it seems like this meets all the objectives.
. support for n parameters
. no emalloc calls
. no va_list usage
. zend_call_method() backwards compatible (lesser extent)
your feedback appreciated,
-nathan
(and i did the diff in the right direction this time :D)
--- zend_interfaces.ORIG.c2009-02-17 20:24:47.0 -0700
+++ zend_interfaces.c2009-02-18 11:44:53.0 -0700
@@ -29,9 +29,10 @@
ZEND_API zend_class_entry *zend_ce_arrayaccess;
ZEND_API zend_class_entry *zend_ce_serializable;
-/* {{{ zend_call_method
+
+/* {{{ zend_call_method_va
Only returns the returned zval if retval_ptr != NULL */
-ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2 TSRMLS_DC)
+ZEND_API zval* zend_call_method_va(zval **object_pp, zend_class_entry
*obj_ce, zend_function **fn_proxy, char *function_name, int
function_name_len, zval **retval_ptr_ptr, int param_count, zval** params
TSRMLS_DC)
{
int result;
zend_fcall_info fci;
@@ -39,11 +40,6 @@
zval *retval;
HashTable *function_table;
-zval **params[2];
-
-params[0] = arg1;
-params[1] = arg2;
-
fci.size = sizeof(fci);
/*fci.function_table = NULL; will be read form zend_class_entry of
object if needed */
fci.object_ptr = object_pp ? *object_pp : NULL;
@@ -107,6 +103,19 @@
}
/* }}} */
+/* {{{ zend_call_method
+ Only returns the returned zval if retval_ptr != NULL */
+ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2 TSRMLS_DC)
+{
+zval **params[2];
+
+params[0] = arg1;
+params[1] = arg2;
+
+return zend_call_method_va(object_pp, obj_ce, fn_proxy, function_name,
function_name_len, retval_ptr_ptr, param_count, params TSRMLS_CC);
+}
+/* }}} */
+
/* iterator interface, c-level functions used by engine */
/* {{{ zend_user_it_new_iterator */
--- zend_interfaces.ORIG.h2009-02-17 20:24:36.0 -0700
+++ zend_interfaces.h2009-02-18 11:28:55.0 -0700
@@ -38,6 +38,8 @@
zval *value;
} zend_user_iterator;
+ZEND_API zval* zend_call_method_va(zval **object_pp, zend_class_entry
*obj_ce, zend_function **fn_proxy, char *function_name, int
function_name_len, zval **retval_ptr_ptr, int param_count, zval** params
TSRMLS_DC);
+
ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2 TSRMLS_DC);
#define zend_call_method_with_0_params(obj, obj_ce, fn_proxy,
function_name, retval) \
[PHP-DEV] zend_call_method() - support for up to 4 parameters
hi,
recently, working on an extension, i wanted to call a method w/ 3 params,
and as you know, zend_call_method only supports 2 parameters at most. i
came across this thread in the archives,
http://marc.info/?l=php-internalsm=120179690310419w=2
so i tossed together a quick patch w/ no emalloc or va_list against the
latest 5.3 snapshot.
what do you think?
-nathan
--- zend_interfaces.c2009-02-17 20:50:35.0 -0700
+++ zend_interfaces.ORIG.c2009-02-17 20:24:47.0 -0700
@@ -31,7 +31,7 @@
/* {{{ zend_call_method
Only returns the returned zval if retval_ptr != NULL */
-ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2, zval* arg3, zval*
arg4 TSRMLS_DC)
+ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2 TSRMLS_DC)
{
int result;
zend_fcall_info fci;
@@ -39,12 +39,10 @@
zval *retval;
HashTable *function_table;
-zval **params[4];
+zval **params[2];
params[0] = arg1;
params[1] = arg2;
-params[2] = arg3;
-params[3] = arg4;
fci.size = sizeof(fci);
/*fci.function_table = NULL; will be read form zend_class_entry of
object if needed */
--- zend_interfaces.h2009-02-17 20:51:22.0 -0700
+++ zend_interfaces.ORIG.h2009-02-17 20:24:36.0 -0700
@@ -38,22 +38,16 @@
zval *value;
} zend_user_iterator;
-ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2, zval* arg3, zval*
arg4 TSRMLS_DC);
+ZEND_API zval* zend_call_method(zval **object_pp, zend_class_entry *obj_ce,
zend_function **fn_proxy, char *function_name, int function_name_len, zval
**retval_ptr_ptr, int param_count, zval* arg1, zval* arg2 TSRMLS_DC);
#define zend_call_method_with_0_params(obj, obj_ce, fn_proxy,
function_name, retval) \
-zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 0, NULL, NULL, NULL, NULL TSRMLS_CC)
+zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 0, NULL, NULL TSRMLS_CC)
#define zend_call_method_with_1_params(obj, obj_ce, fn_proxy,
function_name, retval, arg1) \
-zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 1, arg1, NULL, NULL, NULL TSRMLS_CC)
+zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 1, arg1, NULL TSRMLS_CC)
#define zend_call_method_with_2_params(obj, obj_ce, fn_proxy,
function_name, retval, arg1, arg2) \
-zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 2, arg1, arg2, NULL, NULL TSRMLS_CC)
-
-#define zend_call_method_with_3_params(obj, obj_ce, fn_proxy,
function_name, retval, arg1, arg2, arg3) \
-zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 3, arg1, arg2, arg3, NULL TSRMLS_CC)
-
-#define zend_call_method_with_4_params(obj, obj_ce, fn_proxy,
function_name, retval, arg1, arg2, arg3, arg4) \
-zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 4, arg1, arg2, arg3, arg4 TSRMLS_CC)
+zend_call_method(obj, obj_ce, fn_proxy, function_name,
sizeof(function_name)-1, retval, 2, arg1, arg2 TSRMLS_CC)
ZEND_API void zend_user_it_rewind(zend_object_iterator *_iter TSRMLS_DC);
ZEND_API int zend_user_it_valid(zend_object_iterator *_iter TSRMLS_DC);
Re: [PHP-DEV] New function proposal: spl_class_vars / params / contents
Christian Schneider wrote: Lukas Kahwe Smith wrote: On 21.01.2009, at 12:00, Karsten Dambekalns wrote: On 21.01.2009 11:44 Uhr, Kenan R Sulayman wrote: I did propose the function because the construction in user-land is quite expensive; Reflection is expensive, indeed. The way we solved it for FLOW3 is to create a ReflectionService that caches such information as long as the source doesn't change. yeah its a general problem .. but so far the decision has been that we should move away from adding more and more functions/methods for highly specialized cases (as in not continue in the get_class() etc. approach). now speeding up reflections is a very real issue .. suggestions in this regard are quite welcome. maybe offering a cache service as part of core is one approach .. Yes, please. Keep clutter out of the engine especially for stuff which should not be used often. If you are relying on Reflection to be fast for you everyday code then you're IMHO doing something weird and it is ok that you have to write your own caching for it (-:C seems to me that many of the new requests coming in, including my own stupid ones are because people want to build fast decent orm's in php - a definitive list of what one needs to make an orm in php, the userland approaches possible, what could be implemented in php and what couldn't might be good. address the whole thing in a oner. quite sure the requests and need is only going to grow.. imho it's being encouraged by the increasing numbers using PDO - it kind of suggests building an orm :p also, very unlike me, but a service to cache reflection classes is quick and simple to implement in userland - (although if there is a free speed up to reflection going I'll 'ave some) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_class_vars / params / contents
Christian Schneider wrote: Nathan Rixham wrote: seems to me that many of the new requests coming in, including my own stupid ones are because people want to build fast decent orm's in php - Having built an ORM system myself I can say that you don't need Reflection (or even other fancy features not yet in PHP) for this. Maybe you are trying to use a hammer when the problem is not a nail, - Chris likewise didn't use reflection myself when interfaces and class architecture can be used; but there is the whole persist objects that don't extend or implement you're own classes/interfaces thing - hence the possible reflection need (to get the private/protected properties) depends on the design approach I guess -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: maybe we could all?
Nathan Rixham wrote: Project: PHP Common Objects and Datatypes wrong list - forget; meant for general! sorry - having a good week - and it's monday. *sigh* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
first off; had a rather in-depth (but lacking when it comes to internal
input) over on the general list; has been interesting.
Lukas Kahwe Smith wrote:
On 17.01.2009, at 18:06, Nathan Rixham wrote:
a: Optional Static Typing
I'm finding an ever increasingly need to be able to staticly type
properties, parameters, return types etc (in classes) I know there is
type hinting but it's just not enough to do what one needs.
Additionally support for staticly typing primatives.
I am not a type hinting fan .. then again I think that PPP is mostly
bogus for a scripting language as well. I would not mind this stuff if
it would just all just throw E_STRICT's instead of E_FATAL. To me the
point of a glue language is to keep running until the engine is about to
explode or the request has finished.
After talking this one out (and negating which E_ is thrown) I've come
to the conclusion that optional type hinting in the following places
would suffice:
class Example {
private TypeHint $var;
...
Example $var = new Example();
...
and finally primative/scalar type hinting in all of these places.
b: Object superclass
A base class type which all objects automagically extend, with (if
nothing else) a unique id / hashcode for each object. Failing this
some form of function to get a unique reference string for any variable.
I think this is quite pointless. I do not see any need for magic here.
No need to be able to magically redefine the base class and saving the
few chars to type is also not sensible (and this will not give you MI
through the backdoor either).
I'd be tempted to agree; however while you can currently TypeHint in php
as such:
public function whatever(array $someArray)
and
public function whatever(SomeClass $obj)
*you can't*
public function whatever(object $obj)
which seems rather strange, some people are of the belief/misconception
that stdClass is the superclass of all objects but it just isn't; all in
it means that one can't specify (typehint) that a method param should
simply be an object - seems strange and hopefully the internals will
concider adding this functionality at the very least.
In the above scenario of you adding this functionality I ask you would
the logical and appropriate approach be to perhaps make stdClass or some
other class the super of all objects, and if this was the case surely
adding in the functionality implemented in spl_object_hash or the
discussed spl_object_id may be appropriate.
(reasons why not would be great) - or would the approach be to allow the
aforementioned public function whatever(object $obj)
c: Method overloading
TBH it's something I could live without, whereas a/b aren't, but it
would be an ideal addition to php; Many times I've had to work around
the lack of this functionality with (what could be) unneeded code.
You mean polymorphism? I hope we will never see that in PHP. This kind
of magic is dangerous and just forces PHP even more into a static typed
corner. Maybe you need to whip up a patch for your PHP version that
makes PHP statically typed?
fair enough; stut also raised the point that it makes no sence to
implement this when you can have variable argument lists.
re patch: would love to, considering it, 7 years since I touched c -
otherwise this is the approach I'd be taking! may still yet.
additional:
a magic method __cast may be beneficial to allow users to create there
own primative/scalar wrappers and convert from primative to wrapper and
back.. thoughts?
cheers for the input lukas.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
Hannes Magnusson wrote:
On Sun, Jan 18, 2009 at 17:42, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 17.01.2009, at 18:06, Nathan Rixham wrote:
a: Optional Static Typing
I'm finding an ever increasingly need to be able to staticly type
properties, parameters, return types etc (in classes) I know there is type
hinting but it's just not enough to do what one needs. Additionally support
for staticly typing primatives.
I am not a type hinting fan .. then again I think that PPP is mostly bogus
for a scripting language as well. I would not mind this stuff if it would
just all just throw E_STRICT's instead of E_FATAL. To me the point of a glue
It doesn't throw E_FATAL. It throws E_RECOVERABLE_ERROR which doesn't
do anything.
E_RECOVERABLE_ERROR seems appropriate IMHO
I've reworded my original mail completely maybe this one will have more
feedback (or not)
question: Would anybody else like to see, or feel the need for,
*optional* type hinting of variables and class properties in PHP?
examples (all optional, and syntax may differ):
class Example {
private TypeHint $var;
}
Example $var = new Example();
in addition the ability to type hint primatives/scalars/[type object] in
the existing implementation:
function(bool $flag) {
}
function(object $flag) {
}
This would all be under the assumption and proviso that an
implementation would not break bc, have any markable perfomance hit, or
in any other way effect existing applications or new applications that
did not use the functionality (in the same way the existing type hinting
implementation doesn't)
internals: can anybody confirm if this would even be possible and if so
what the cost would be?
regards, thanks / apologies where needed etc.
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
Robin Burchell wrote: On Sun, Jan 18, 2009 at 9:39 PM, Nathan Rixham nrix...@gmail.com wrote: I've reworded my original mail completely maybe this one will have more feedback (or not) question: Would anybody else like to see, or feel the need for, *optional* type hinting of variables and class properties in PHP? I was involved on a thread on exactly this some weeks earlier. I (and a few others, though I don't really remember specifics) would very much appreciate the possibilities of proper code structure when working with large teams that this could help provide :) it was a thread q on primatives i think.. guess who started it *ducks* (As to your original proposal, multiple method signatures is something I've come across a need for *occasionally*, though personally, I'm not a big fan of the feature -- the one place I would like having it is __construct(). noted; found the same thing, another specific being that all classes have a default no arg constructor so it can be instantiated prior to calling the setters even if there's a constructor which demands params. Say, you've got an ORM class which is derived for usage: [snip] very interesting that you give an ORM example; this is exactly the area where I've found the need for this class property type hinting (and on web services tbh) - but still, mapping a private bool $flag to a tinyint(1) is so much easier than mapping a private $flag to it (complications multiplied somewhat with other data types) Yes, I realise that this can be done with retrieving arguments and the like, but for such purposes it's not the neatest solution syntactically.) agreed any possible implementation in php feels like more of an inefficiant hack tbh (perhaps a bit strong..)? cheers! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Really Need..
Afternoon all, Recently I've been running in to a lot of frustrations with PHP, don't get me wrong I love the language, but I just can't do what I *need* to in a few situations, specifically when dealing with Classes and Objects. I strongly feel that these need added in to PHP 6, for multiple reasons which I'd be happy to elaborate on. a: Optional Static Typing I'm finding an ever increasingly need to be able to staticly type properties, parameters, return types etc (in classes) I know there is type hinting but it's just not enough to do what one needs. Additionally support for staticly typing primatives. b: Object superclass A base class type which all objects automagically extend, with (if nothing else) a unique id / hashcode for each object. Failing this some form of function to get a unique reference string for any variable. c: Method overloading TBH it's something I could live without, whereas a/b aren't, but it would be an ideal addition to php; Many times I've had to work around the lack of this functionality with (what could be) unneeded code. I can't stress enough what a vast difference the implementation of these three features would make to php, even above many of those currently rfc'd (imo), infact I'd put them on par with the need for namespaces, and additionally they'd compliment namespaces perfectly. Is there any way to get the ball moving with any of the above? (if I was a c dev I'd do it myself.. infact even considered learning c just for this task) Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] open_basedir .htaccess relative path problem - BUG or Expected?
Hi All, Figured this was for internals before opening up a bug report. In php 5.2.8 on windows and linux (only ones tested so far) when you add in a value to open_basedir in either php.ini or a vhosts.conf file; *relative* paths suddenly do not work for the php_value error_log specified in a .htaccess file. thus: with php.ini/vhosts.conf open_basedir NOT set these values in .htaccess WILL work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt === with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: open_basedir .htaccess relative path problem - BUG or Expected?
Nathan Rixham wrote: Hi All, Figured this was for internals before opening up a bug report. In php 5.2.8 on windows and linux (only ones tested so far) when you add in a value to open_basedir in either php.ini or a vhosts.conf file; *relative* paths suddenly do not work for the php_value error_log specified in a .htaccess file. thus: with php.ini/vhosts.conf open_basedir NOT set these values in .htaccess WILL work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt === with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir .htaccess relative path problem -BUG or Expected?
Jani Taskinen wrote: Nathan Rixham wrote: with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific What exactly IS the open_basedir setting value here? Did you leave . out of it..? --Jani when open_basedir is set to the correct value (in this specific case set to the site root directory) eg /var/sites/testsite/ and the full path to the log file is /var/sites/testsite/logfile.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir .htaccess relative path problem -BUGor Expected?
Nathan Rixham wrote: Jani Taskinen wrote: Nathan Rixham wrote: with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific What exactly IS the open_basedir setting value here? Did you leave . out of it..? --Jani when open_basedir is set to the correct value (in this specific case set to the site root directory) eg /var/sites/testsite/ and the full path to the log file is /var/sites/testsite/logfile.txt just a quick one; it's def not a path error; the same config works using vhosts rather than .htaccess; and works completely using htaccess / vhosts on 5.2.6 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] christmas decorations..
I just threw the christmas tree out, came online and noticed that the decorations are still up on the php.net site; any idea when they're coming down? ho-ho-ho etc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
Ilia Alshanetsky wrote: While I whole heartedly agree with the idea, I am not sure its a good thing to do in 5.2 branch. I'd like to hear more feedback on that topic before making the decision. The only mitigating factor is that it will only affect new users since upgrading the release does not modify the INI files, unless people are running without an INI file entirely relying on the built-in defaults. On 6-Jan-09, at 10:52 AM, Lukas Kahwe Smith wrote: On 16.12.2006, at 19:50, Hannes Magnusson wrote: On 12/16/06, Derick Rethans der...@php.net wrote: On Fri, 15 Dec 2006, Andi Gutmans wrote: Time to turn it off in php.ini-dist in addition to php.ini-recommended? I would instead change them to php.ini-development and php.ini-production. In development you'd want to have this stuff on.. I think its time for a vote on that. We've been talking about it long enough. +1 ! ok warming up an old topic. it seems most people are in agreement that the above is a good idea. (so speak up if you think its a bad idea .. otherwise it just might happen ..) so it would be ok with us RM's if someone starts working on this ASAP .. this would essentially entail reviewing the current php.ini files we ship and giving good defaults for development and production. ideally this should be done with the beta1 release, because i envision there will be a bit of a need for discussion (especially from the side of the end users). regards, Lukas Kahwe Smith m...@pooteeweet.org Ilia Alshanetsky 'scuse my ignorance; but having a single well documented ini file rather multiple recommended configurations seems to make sense; purely because it will encourage users to read the file and familiarise themselves with the settings rather than simply load up which one looks best, forget about it, then come looking for help when they don't understand why they can't see error messages. I'd vote a single well documented php.ini with production defaults active. (no -dist, -recommended or suchlike) regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
Marco Tabini wrote: On 6-Jan-09, at 11:49 AM, Ilia Alshanetsky wrote: I'm ok with doing for 5.3, most people when upgrade rarely look at the INI file especially if the update is done through a distribution's package management system. Not to barge in, but many people won't consider 5.2 - 5.3 a major upgrade. That's what major version numbers are for. Mt. agreed but I'd assume that most (all) distro package makers would notice it was a major version if suitably named. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Robin Burchell wrote:
Just a random thought I have from reading over that:
Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.
'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?
it would break all php code existing so far; the only real way to
implement return value types would be as such
public static function somefunc():int {
this would allow the return type to be optional and leave all existing
code functional; likewise it could be implemented for any style of
php'ing, thus:
#php4 style class method or normal procedural function
function dosumit():int {
type hints are all ready there so adding primitives /should/ be possible
without any bc issues
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Robin Burchell wrote: Hmm. How would it break it? By leaving 'function' to mean variant, it's only adding new functionality by overriding types to replace 'function', which should have no issue with older code, surely? To clarify: current method declaration: function foo() public static function foo() public function foo() because all of those current declarations would no longer work on the new version of php which implemented such change..? and I'm assuming it would be a much bigger change to the php internals than adding in an optional type after the method params..? I do like the type method() syntax though, but don't think it's a php thing..? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
2008/12/18 Dave Ingram d...@dmi.me.uk
Also, what about this case:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
I would argue that the most specific function should be called, but how
costly would that be to determine? What if you have a Baz subclass of
Bar, but no corresponding method? What if Bar itself is a subclass of Foo?
Ideally a most specific first approach, failing that I'd suggest taking
doing it the nearest first way (like we do when catching exceptions) ?
Re: [PHP-DEV] Q on Primitives
Dave Ingram wrote:
I remember that multiple signatures was said to have a possible very
difficult implementation. However, a similar behaviour can be achieved by
some instanceof().
I thought it probably would be awkward, but we do already have some type
hinting that can also be accomplished with instanceof() -- this is just
an extension of that idea. Although it's not my idea as such!
instance of is handy however it isn't the cleanest; consider:
public static function parseByte( $var )
{
$testPassed = false;
if( $var instanceof Number ) {
$var = $var-byteValue();
$testPassed = true;
} if( $var instanceof String ) {
$var = $var-__toString();
}
if( !$testPassed is_numeric( $var ) ) {
$var = 0 + $var;
$testPassed = true;
}
if( $testPassed Byte::MIN_VALUE = $var Byte::MAX_VALUE =
$var ) {
return $var;
}
throw new NumberFormatException();
}
could be:
public static function parseByte( Number $var )
{
return $var-byteValue();
}
public static function parseByte( String $var )
{
if( is_numeric( $var = $var-__toString() ) ) {
$var = 0 + $var;
if( Byte::MIN_VALUE = $var Byte::MAX_VALUE = $var ) {
return $var;
}
}
throw new NumberFormatException();
}
mini-use-case but shows how useful it would be..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Dave Ingram wrote:
Cristian Rodríguez wrote:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
Looks like you are using the wrong language, you need JAVA instead.
Yes, I'll admit it does look like Java (or any C++-like OO language) -
but PHP already does some type hinting, and IMO it can be very useful as
an additional sanity check.
Dave
I am a Java developer :p and PHP and AS3 (they're my primary languages),
some things are good regardless of what language they're from, it's not
exactly a major shift to generics or packages that I'm suggesting, just
natural progression from type-hinting and most useful whatever language
you are in.
I daily switch between PHP and Java and there are only a few things that
make logical sense to have in a language that I miss when back on php;
primitives, multiple method signatures, and the ability to call a class
member function without using this; however I'm well aware the latter is
impossible since PHP is both procedural and OO.
Regards!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Nathan Rixham wrote:
Dave Ingram wrote:
Cristian Rodríguez wrote:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
Looks like you are using the wrong language, you need JAVA instead.
Yes, I'll admit it does look like Java (or any C++-like OO language) -
but PHP already does some type hinting, and IMO it can be very useful as
an additional sanity check.
Dave
I am a Java developer :p and PHP and AS3 (they're my primary languages),
some things are good regardless of what language they're from, it's not
exactly a major shift to generics or packages that I'm suggesting, just
natural progression from type-hinting and most useful whatever language
you are in.
I daily switch between PHP and Java and there are only a few things that
make logical sense to have in a language that I miss when back on php;
primitives, multiple method signatures, and the ability to call a class
member function without using this; however I'm well aware the latter is
impossible since PHP is both procedural and OO.
Regards!
and strongly typed returns.. nearly forgot
public static function parseByte( Number $var ):bool {
or
public static function bool parseByte( Number $var ) {
or such like
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Q on Primitives
Don't want to take up much of you're time, just wondered if anybody
could point me to the reason why some primitives aren't in php.
Would find it very very useful to have byte, short, long, float, double
and char in php. (primarily byte and char).
while I'm here I may as well also ask about further adding type hinting
for the existing scalars and array.
and finally different method signatures such as:
class Whatever {
public function __construct(Bar b);
public function __construct(Foo f);
public function doSomething(Bar b);
public function doSomething(Foo f);
}
Regards!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Graham Kelly wrote: Hi, I think the reason there aren't more primitive types in PHP is because of the nature of the language. One of the main features of PHP over say, C (and even Java), is that the memory managment is completely transparent to the devloper. This means that it really shouldent matter to the devloper how an integer is implimented on the machine. Same with doubles and chars. Granted, I can see some reasons why forcing the data to be of a specific length or type would be handy, but I dont know if there would be a wide enough requierment for this to actually impliment it as a language feature. Plus, you usually can find a way around it anyway :). But basically, if your interest in byte and char are for conserving memory then dont be worried... PHP does a fairly good job with your memory and this wouldent actually translate into a memory savings on the machine. mainly it was for the strictness and for the extra speed gained by having a primitive at php level, to implement using say class Byte (which I have done) is seriously heavy processor and memory wise for something so simple.. especially if you consider an implementation of ByteArray.. obviously there isn't much call otherwise this would have been implemented back at v4 or at least 5; however I for one would love to see this simple little bit of support added. Would open up masses of avenues, including the ability to make some decent orm's for php (much easier to map byte to byte than scalar might be a byte but is really an integer to byte if you know what I mean. regards! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Clarifying the resolution rules
Stan Vassilev | FM wrote: Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls). personally not very disruptive, and after a few hours I think it would become second nature. I'm sure there will be a few comments about this, but.. why not move all internal functions and classes to a php namespace so that everything has to be in a namespace by default - ie no code that isn't in a namespace. ie php\file_get_contents(__FILE__); instead of \file_get_contents(__FILE__); major major change but nice and strict -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: namespace separator and whining
Greg Beaver wrote: Hi all, Let me make this brief: there will be lots of complaining about the namespace separator. Stop. Now. It serves no possible useful purpose. If you want to discuss why this was chosen or suggest alternatives, feel free to write me *off-list*. I would be more than happy to answer any questions about the technical aspects of various choices. The decision is made, now I suggest everyone get busy actually trying it out. You will very quickly understand why it is a very viable choice. Thanks, Greg just wanted to quickly say thanks for all you're long suffering hard work on this - and a great decision imho. thanks again :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/socketssockets.c
Jani Taskinen wrote:
1. This should be applied to PHP_5_2 (not big change and in no way can
break anything)
2. You can always simply put a short comment like Fixed in CVS, needs
documenting and reclassify the bug report as docu issue. There's no
need for some fancy shortcuts or such. Just tune your process..
--Jani
nice suggestion I'm gonna do that at work! saved me a headache - cheers :)
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Diogo Galvão wrote:
The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence.
As far as I understand it if your active record references the PDO
instance (say $this-conn) your object gets destroyed before the
connection object.
Perhaps it's a better approach then introducing destruction order for
global or singleton problems.
wbr,
Diogo
Larry Garfield wrote:
On Wednesday 22 October 2008 2:31:38 am Mike van Riel wrote:
I believe the end of your script part is the problem. Imagine you
have some object (say, ActiveRecord style) that writes itself to the
database when it's destroyed if the data has been modified. Now cache
that object in a static variable somewhere for performance. You're
also using PDO, so your database connection is a global or singleton
instance of the PDO class.
Then your script reaches the end. Does your object get destroyed and
therefore saved to the database before or after the PDO object goes
away? I don't actually know.
I'm not saying that manual destructor order is the correct way to deal
with that issue necessarily, but I think that's the sort of use case
it's intended to address.
just to add it in; in ejb3 in java you have PostConstruct and PreDestroy
which are pretty useful; maybe something along the same lines could be
implemented in PHP?
regards!
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Jani Taskinen wrote: Nathan Rixham wrote: just to add it in; in ejb3 in java you have PostConstruct and PreDestroy which are pretty useful; maybe something along the same lines could be implemented in PHP? Or perhaps you should just stick with Java? just a suggestion for some useful functionality - where's the harm? anyhow, apologies if I offended - have a great day :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UltraSimple Namespace Solution
Ronald Chmara wrote:
On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:
*A Simpler Solution*
Force userland / general naming conventions in PHP.
# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();
thoughts, opinions, reasons why it wouldn't work?
Assuming this is a real question:
1. PHP is heading towards broad i18n. How do you uppercase or
lowercase written languages that don't have a concept of case?
2. PHP was designed for wide adoption, and the authors of libraries
often used function and class cases that matched their library. So,
PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
ucase), etc. etc. etc.
Right now this all works. Changing it would break, well, darned near
*everything*.
3. The vast majority of user operating systems (and filesystems) out
there do *NOT*, I repeat, do *NOT* all handle case in the same way, a
sane way. Windows boxes are still lugging around DOS/VMS legacy with
UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
anything that autoloads (such as namespace code) needs to handle all
of these.
Assuming that this is A Modest Proposal:
1. It needs to be more over the top to be funny to a broad,
multi-lingual, global, audience.
For example, you might have suggested that we add an include_instead()
operator, so somebody who wants to use a function/method which is
located in '/var/location1/file_class.inc', rather than the already
loaded function/method in '/var/location2/file_functions.inc', can
override an existing function/method, and for giggles, you might
suggest that the operator have the power to override all internal
functions, but just for local execution scope, spawning a new
process/thread for each invocation, so a blog post can have 30-80
thousand processes with different scopes to render a web page.
Okay, I'm shutting up now. :)
-Bop
Thanks Bop,
After more thought I came to pretty much the same thoughts - received
some heavy replies but then that's my own fault for treating the
internals list the brainstorming room at work!
I jump the gun often and write before thinking things through 100%; even
even I can see the namespace problem clearly enough to know that the
problem lies in php being both a procedural and OOP language, unless you
remove one or the other from namespaces there is always going to be a
level of ambiguity somewhere; IMO Greg's solution #2 (introducing ::: to
mark the end of a namespace) and stas' proposal #1 are the best I've
seen. Personally though I'd love to see stas' #1 get implemented and
- used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step-two(); //always function of namespace.
But it's still ambiguous (only in a rarely though) - if an object with a
method two is assigned to the static variable of a class called one
then problem comes back.
I'd love to see a perfect solution; but know enough to realise it
isn't going to come from me (and may well be impossible) so bailing out.
I have to say this; the reason people like me pop on to internals and
give brainstorming not thoroughly thought through (or discussed)
opinions, is because there isn't a public forum for that kind of
thing, if there was a place where userland and the internal's could meet
up to even just discuss or thrash out ideas, get opinions, votes,
whatever then it would alleviate the problem.
Regards Happy Weekend
Nathan
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
