Re: [PHP-DEV] [RFC] path_join function
On Wed, 17 May 2023 at 18:24, Gunnard engebreth wrote:
>
> > Maybe im missing something here but the already available `dirname()`
> does this. right?
> https://www.php.net/manual/en/function.dirname.php
>
>
dirname just traverses up the directory, it doesn't join paths.
For example, this example won't be possible with dirname:
path_join('/root', '/foo\\bar/baz', '../test', 'file.json'); // =>
/foo/bar/test/file.json
[PHP-DEV] [RFC] Deprecate properties using var
Hi all Before I create an RFC, I just want to get some feedback on a proposal, to deprecated the use of var when declaring properties on a class. This was previously deprecated in PHP 5.0.0 and the deprecation notice was removed in PHP 5.1.3. My proposal is to deprecate the use of var on properties in PHP 7, and then remove support for it in PHP 8. This compliments the [0] Remove PHP 4 Constructors RFC, as it is old PHP 4 behaviour, and according to the docs is only supported for compatibility reasons, and personally I think users should be encourage to use proper visibility when defining properties. [0] https://wiki.php.net/rfc/remove_php4_constructors Regards Pierre du Plessis
Re: [PHP-DEV] RFC: Anonymous Classes
On 24 September 2013 14:51, Nicolas Grekas nicolas.grekas+...@gmail.comwrote:
What about allowing a use statement on these methods?
$someFoo = bar;
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object-method(); // bar;
I think the idea of anonymous classes is very useful.
a use case that I recently encountered, is to override a specific method in
a class.
So instead of creating a new class that extends the original class, you can
just use an anonymous class and override the methods that you want.
E.G.
You can to the following:
use Symfony\Component\Process\Process;
$process = new class extends Process {
public function start() {
/* ... */
}
};
instead of the following:
namespace My\Namespace\Process;
use Symfony\Component\Process\Process as Base;
class Process extends Base {
public function start() {
/* ... */
}
}
$process = new \My\Namespace\Process\Process;
Re: [PHP-DEV] New syntax for multidimensional array loop with foreach
On Thu, Jun 27, 2013 at 6:14 PM, Johannes Schlüter
johan...@schlueters.dewrote:
On Thu, 2013-06-27 at 16:58 +0200, Nikita Popov wrote:
On Thu, Jun 27, 2013 at 4:10 PM, Christian Stoller stol...@leonex.de
wrote:
The new syntax could make it shorter and faster to write... but maybe
it's
a bit too confusing?
$count = 0;
foreach ($array as $key = $innerArray as $innerKey = $value) {
$count += $value;
// and do something with $key and $innerKey
}
With the addition of array_column in php 5.5, this can be done in a much
cleaner way:
$array = array(
array('value' = 1),
array('value' = 2),
array('value' = 3),
);
$count = 0;
foreach(array_column($array, 'value') as $value) {
$count += $value;
}
Re: [PHP-DEV] New syntax for multidimensional array loop with foreach
On Thu, Jun 27, 2013 at 7:29 PM, Tjerk Anne Meesters datib...@php.netwrote:
On Fri, Jun 28, 2013 at 1:13 AM, Pierre du Plessis
pie...@pcservice.co.zawrote:
On Thu, Jun 27, 2013 at 6:14 PM, Johannes Schlüter
johan...@schlueters.dewrote:
On Thu, 2013-06-27 at 16:58 +0200, Nikita Popov wrote:
On Thu, Jun 27, 2013 at 4:10 PM, Christian Stoller
stol...@leonex.de
wrote:
The new syntax could make it shorter and faster to write... but
maybe
it's
a bit too confusing?
$count = 0;
foreach ($array as $key = $innerArray as $innerKey = $value) {
$count += $value;
// and do something with $key and $innerKey
}
With the addition of array_column in php 5.5, this can be done in a much
cleaner way:
$array = array(
array('value' = 1),
array('value' = 2),
array('value' = 3),
);
$count = 0;
foreach(array_column($array, 'value') as $value) {
$count += $value;
}
And what about the // and do something with $key and $innerKey part?
This is using the original example provided, which didn't do anything with
the $key and $innerKey.
Re: [PHP-DEV] Proposal for new array_map function to pass in keys
function my_call_back($key, $value) {
return array($value, strlen($value));
}
$array = str_word_count(PHP is lots of fun!);
$array = array_map_key('my_call_back', $array);
The result would be the following array:
array(5) {
[PHP]=
int(3)
[is]=
int(2)
[lots]=
int(4)
[of]=
int(2)
[fun]=
int(3)
}
This example doesn't make any sense, as str_word_count returns an integer,
so you would in fact pass an int to array_map_key and not an array.
But let's say using your example, you use explode( , $string) instead of
str_word_count, which will give you an array of all the words.
What happens in the following case:
function my_call_back($key, $value) {
return array($value, strlen($value));
}
$array = str_word_count(PHP stands for PHP hypertext preprocessor);
$array = array_map_key('my_call_back', $array);
This would give you 2 keys with the value of PHP. What happens in this case?
What if you have duplicate integer keys. Does the keys simply increment or
throw an error?
Re: [PHP-DEV] Scalar Type Casting Magic Methods
The __toArray can be useful if you want to perform array functions on the object (E.G array_filter), otherwise I think it would be very useful if the array functions can accept an object implementing ArrayAccess as well instead of just an array On May 7, 2013 8:40 PM, Nikita Popov nikita@gmail.com wrote: On Sat, May 4, 2013 at 5:31 PM, Oleku Konko oleku.ko...@yahoo.com wrote: Quick Observations : I had this issue ( http://stackoverflow.com/questions/16375331/increment-on-tostring ) and it kept me thinking why no error was returned, then i stumble up this RFC : https://wiki.php.net/rfc/object_cast_to_types The patch is basic , simple and working and it should be seriously considered in 5.5. I want to believe if https://github.com/php/php-src/pull/334 can make it to PHP 5.5 then we should give object_cast_to_types the same opportunity except they are string objections why it should not be so I don't think that this would be particularly useful and as such I don't think we need it. The idea of doing some meaningful operation when writing $obj + 1 is nice, but only if you have actual operator overloading and can compute the result of that expression yourself. If you don't have this possibility and only get to cast $a to an integer/float, then the whole thing becomes rather useless. The only thing it could be used for are thin wrappers around integers/floats and I don't see why one would want to do such a thing (especially as you get back a number and *not* a wrapper object). Thus, __toScalar(), __toInt(), __toFloat() seem pretty useless. The only thing that might have some merit is __toArray(). But there again, I'm not really sure what it gives us. After all we already have Traversable and ArrayAccess, so we can already make an object behave pretty much like an array. Nikita
Re: [PHP-DEV] Method check - Can someone create a RFC for it?
On 03/20/2013 11:43 AM, Carlos Rodrigues wrote: Like Mike emaild me, i can just change my code to something like $obj-getImage()-getUrl(), where getImage() will return a mock object with getUrl() returning an empty string. But my request here is not about this case only. Imagine you have a web page with 3 blocks of information. Let's say news, partners and blog. Now if for some reason you didn't code it right, you might get a fatal error in one of these blocks. I'd love to have a way to try/catch these blocks, Currently i can only do this using ajax, or running shell exec php block.php for each one. If we could catch fatal errors, or at least the Call to a member function on a non-object, we could have this code in our Zend Framework implementations, wrapping each view in a try/catch, and showing a error, sorry, in case the view has errors. - Carlos Carlos, You should take a look at the other thread that's been in the internals group over the last day or so. There is an effort to see cases like this become E_RECOVERABLE_ERRORs, which I think would address what you're really looking for. (In fact, this particular error is mentioned first in that thread.) But I would argue that, while this is a change I support, this is not a substitute for proper testing prior to code deployment (as others have pointed out). I think changing the fatal error to E_RECOVERABLE_ERROR will be a good option, because if you have a generic error handler, then you won't have to worry about blank pages on a production server
Re: [PHP-DEV] __invokeStatic() method
Hi,
Le Mon, 18 Mar 2013 09:07:43 +0200, Matīss Roberts Treinis a écrit :
Not only that. This potentially might break compatibility with many
software products already out there.
I don't see how it could break existing software as it is not a
modification of an existing method but a brand new one.
It would break existing software if you have a class and function with the
same name.
Consider the following example:
class foo {
}
function foo()
{
}
Now what if you have several calls to foo() in your existing application?
With the new change, will those calls call the function, or invoke the
__invokeStatic method if it is available?
Also, this might lead to many
misunderstandings and, in fact, ambiguous code. Consider the sample.
$name = 'something';
$something = $name(); // What is this - a function call or object?
Fact is, we can not know that unless a) do a search in code b) var_dump?
As long as you use syntax like $foo = new $bar() or $foo = $bar(), you'll
always wonder if the function/class behind $bar exist or not, etc...
And it is easy to remove any ambiguity by using $something = $functionName
() or $something = $className() or add proper comments. It's only up to
the dev.
I find that __invokeStatic() could be a quite cool syntactic sugar.
My 2 cents.
Bruno
I'm not against the function, just the implementation of it. __invokeStatic
might be useful in some (rare) cases,
but I don't think the proposed syntax will work.
Also I'm sure that most use cases can anyway be solved by using the
__callStatic method
Re: [PHP-DEV] __invokeStatic() method
Le Tue, 19 Mar 2013 09:37:43 +0200, Pierre du Plessis a écrit :
It would break existing software if you have a class and function with
the same name.
Consider the following example:
class foo {
}
function foo()
{
}
Now what if you have several calls to foo() in your existing
application? With the new change, will those calls call the function, or
invoke the __invokeStatic method if it is available?
It will clearly technically lead to a problem. Now I don't see why in the
world a class and a function could share the same name. Regarding
conventions, a class name should begin with an uppercase character and a
function a lowercase one. I don't see any relevant use case where a class
and a function should share the same name.
PHP doesn't care about uppercase or lowercase when it comes to function
names.
Have a look at http://3v4l.org/cePT5 for an example.
And not everybody uses conventions anyway (although they should)
Although it is not common to have a class and function have the same name,
it can happen.
Take the following code as an example.
class Debug {
public static dump($var)
{
// some code to debug $var
}
}
function debug($var)
{
return Debug::dump($var);
}
The problem is clear if you have a __invokeStatic method in the debug
class, and you want to make a call to debug().
Re: [PHP-DEV] __invokeStatic() method
It is clear to me that there are valid reasons to say yes to this proposal, but there are a lot to say no too. Even if it could be interesting in theory, due to of how PHP handles collisions between classes and functions names (no check at all), implementing a callable class could break existing code. At the moment a class and a function with the same name can coexist, but implementing a callable class would mess this state of affairs. With the adoption of the namespaces, I think that this collisions could became so rare to not exist, but of course we cannot ignore pre existing situations. As suggested by Patrick Schaaf, a workaround is to implement a function, with the same name of the class, that behaves like a wrapper for a method call. It is a good point, but has the negative side that it must be implemented for every class who follow this pattern. It is not usable in a framework for example. It seams that to handle consistently a callable class is to modify PHP to treat functions/classes names case sensitive and to trigger an E_WARNING (or similar) in case of collision. In this way new code could take advantage of the new syntax and old code could simply suppress the warning. What do you think? This change might be disastrous in some applications, and I don't think it will be worth it just for the sake of some syntactic sugar. And still this change won't even make a difference if you have a class and function with the same name that E.G uses all lowercase.
Re: [PHP-DEV] __invokeStatic() method
On Mar 18, 2013 2:41 AM, Thomas Bley thbley+...@gmail.com wrote:
On Sat, Mar 16, 2013 at 9:33 PM, Pierre du Plessis
pie...@pcservice.co.za wrote:
On Mar 16, 2013 9:35 PM, Daniele Orlando dnl.r...@gmail.com wrote:
Hi List,
I'm interested in proposing an RFC and I would know your opinion.
=== Current Situation ===
Since PHP 5.3 we can use an object instance, who defines the __invoke()
method, as a callable object.
Example:
// PHP Code.
class Runnable
{
public function __invoke()
{
echo Runned;
}
}
$r = new Runnable();
$r();
// Output
Runned
=== The Idea ===
In Python, when you construct an object, you don't need to use the
new
keyword but you just invoke the class name followed by (), like the
class
is a function.
Example:
// Python Code.
class A:
pass
A()
// Output.
__main__.A instance at %address
Now, would be interesting to extend the PHP __invoke() method adding an
__invokeStatic() method, like happens with __call() and __callStatic()
methods.
In this way could be possible to use a class name to invoke the
__invokeStatic() method.
Example:
// PHP Code.
class TrueRunnable
{
public static function __invokeStatic()
{
echo Runned;
}
}
TrueRunnable();
// Output.
Runned
But the possibility are endless:
class A
{
public static function __invokeStatic()
{
return new A();
}
public method m() {}
}
A()-m();
// or
class A
{
private $_instance;
public static function __invokeStatic()
{
// Singleton pattern.
if (self::$_instance) {
return self::$_instance;
}
return self::$_instance = new A();
}
public method m() {}
}
A()-m();
=== Conclusion ===
This feature makes the __invoke() method consistent with the __call()
and
__callStatic() methods,
and opens the door to many cool stuff.
Any feedback is appreciated.
Daniele Orlando
I don't really see a use case for this, as you can already use the
syntax
A::method();
E.G class A { public static function invoke() { return new A; }
public function m() { echo 'Runned'; }
A::invoke()-m();
Your example above only saves a few characters to type and can lead to a
lot of problems if you have a function with the same name as the class.
Using A::invoke(), you need to know the name of invoke() and it's
hard to force users always to use the invoke() function.
Using A() would be more clean since all the static init(), factory(),
invoke(), getInstance() are gone.
Having __call(), __callStatic(), __invoke() and invokeStatic() would
make the overloading concept more consistent.
Regards,
Thomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Using A() looks too much like a function call. And there is still the issue
with having a function name the same as the class name.
Re: [PHP-DEV] __invokeStatic() method
On Mar 16, 2013 9:35 PM, Daniele Orlando dnl.r...@gmail.com wrote:
Hi List,
I'm interested in proposing an RFC and I would know your opinion.
=== Current Situation ===
Since PHP 5.3 we can use an object instance, who defines the __invoke()
method, as a callable object.
Example:
// PHP Code.
class Runnable
{
public function __invoke()
{
echo Runned;
}
}
$r = new Runnable();
$r();
// Output
Runned
=== The Idea ===
In Python, when you construct an object, you don't need to use the new
keyword but you just invoke the class name followed by (), like the
class
is a function.
Example:
// Python Code.
class A:
pass
A()
// Output.
__main__.A instance at %address
Now, would be interesting to extend the PHP __invoke() method adding an
__invokeStatic() method, like happens with __call() and __callStatic()
methods.
In this way could be possible to use a class name to invoke the
__invokeStatic() method.
Example:
// PHP Code.
class TrueRunnable
{
public static function __invokeStatic()
{
echo Runned;
}
}
TrueRunnable();
// Output.
Runned
But the possibility are endless:
class A
{
public static function __invokeStatic()
{
return new A();
}
public method m() {}
}
A()-m();
// or
class A
{
private $_instance;
public static function __invokeStatic()
{
// Singleton pattern.
if (self::$_instance) {
return self::$_instance;
}
return self::$_instance = new A();
}
public method m() {}
}
A()-m();
=== Conclusion ===
This feature makes the __invoke() method consistent with the __call() and
__callStatic() methods,
and opens the door to many cool stuff.
Any feedback is appreciated.
Daniele Orlando
I don't really see a use case for this, as you can already use the syntax
A::method();
E.G class A { public static function invoke() { return new A; }
public function m() { echo 'Runned'; }
A::invoke()-m();
Your example above only saves a few characters to type and can lead to a
lot of problems if you have a function with the same name as the class.
Re: [PHP-DEV] [VOTE] array_column() function
On 12 January 2013 00:17, Ben Ramsey ram...@php.net wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting Regards, Ben The vote has been open for almost three weeks and discussion tailed off after only a few days here. What are your thoughts or plans on moving forward with this, or at least coming to a conclusion: given the current state of play (over 80% voted yay thus far) and the release timeline (moving along with the 5.5.0 alphas), not that there's any reason to necessarily rush anywhere. I know the list has been a bit crazy recently so this might have been cast out of the limelight a little, perhaps. Cheers, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Is there any plans to get this into 5.5? Voting has a majority yes, and the 5.5 beta feature-freeze is almost upon us.
Re: [PHP-DEV] array_map() function modification
I'm not sure that adding this functionality in array_map would actually execute faster than doing array_combine($keys, array_map(null, $vals, $vals2, $vals3));. I will need to do some benchmarks to test, but I'm sure you will only see a performance improvement with extremely large arrays. Also why change a function to add functionality that can already be achieved with another existing function? Anybody using array_map is already aware of it's functionality and what it is used for. To change it to add other use cases, which is already available with array_combine, will just be confusing to most developers. If there is a serious need for multiple arrays for values, then I'd rather argue that array_combine be modified to accept multiple arrays, which won't break BC, but I doubt that it would be feasible for the majority developers to have this feature added, as it is very easily implement in user-land with a few lines of code. On Sat, Jan 12, 2013 at 9:41 PM, Thomas Hruska thru...@cubiclesoft.comwrote: array_combine($keys, array_map(null, $vals, $vals2, $vals3)); Kind Regards Pierre du Plessis *Cell*: 072 775 3477 *Fax*: 086 650 4991 *Email*: i...@customscripts.co.za ad...@customscripts.co.za *www*: http://www.customscripts.co.za
Re: [PHP-DEV] - True Annotations
The # would be parsed as a comment Kind Regards Pierre du Plessis *Cell*: 072 775 3477 *Fax*: 086 650 4991 *Email*: i...@customscripts.co.za ad...@customscripts.co.za *www*: http://www.customscripts.co.za On Wed, Jan 9, 2013 at 3:27 PM, Nikita Nefedov inefe...@gmail.com wrote: No please, two symbols for each side looks ugly. BTW There's number sign (#) which is, as far as I remember, not used in PHP at all. Could be something like: #JoinColumn(name=..., type=..., ...) #Foo(Bar()) Or #Foo(#Bar()) (should we put a annotation-sign in front of a nested annotation?) On Wed, 09 Jan 2013 17:17:44 +0400, Patrick Schaaf p...@bof.de wrote: Regarding syntax... Would this work? |foo| |bar( |baz| )| best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
