Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()
2014-11-28 2:13 GMT+01:00 Bostjan Skufca bost...@a2o.si:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function called spl_object_hash() exists,
but it returns identical hashes for equal objects.
It returns unique IDs for existing objects. A hash is only reused only when
the corresponding object was removed by the GC earlier.
So actually asking me it makes more sense to fix the behaviour of
spl_object_hash(),
You need object ID to be
really sure if two references are indeed the same object or two identical
objects.
Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting Allowed memory exceeded.
The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.
Sample implementation (not tested):
=
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, o, obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */
Two questions:
1. Do you think this function should be included in PHP core?
2. If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.
Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think open file handle, etc).
What is your opinion about this?
Tnx,
b.
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Abstract final classes
Hi, 2014-11-27 4:47 GMT+01:00 guilhermebla...@gmail.com guilhermebla...@gmail.com: Hi, I worked on an implementation of a somehow controversial concept that exists in hack and C#: abstract final classes. https://wiki.php.net/rfc/abstract_final_class The example is a little bit misleading: Instead of a new concept you can use functions, right? Regards, Sebastian My motivation is to further expand class support to add modifiers (PPP - public, protected, private). I added this change to initially segregate grammar rules. It was an easy feature without extensive complexity and covers some use-cases. As a reference, here is the commit hash that added this feature to Hack: https://github.com/facebook/hhvm/commit/faedfaf46b0deb859b0c20fb36a574be7a4f2f55 Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- github.com/KingCrunch
Re: [PHP-DEV] Not all archives in http://museum.php.net/php5/ ?
2013/9/30 Yasuo Ohgaki yohg...@ohgaki.net Hi all, I would like to get _exactly_ the same sources that has been released. I though all archives are stored in museum.php.net, but apparently not. http://museum.php.net/php5/ Is there any place that archives old release tar ball? Or anyone could copy them to museum? Whats about checking out the source [1] and compile it yourself? [1] https://github.com/php/php-src Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net -- github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/27 Michael Wallner m...@php.net
On 27 September 2013 09:55, Nicolas Grekas nicolas.grekas+...@gmail.com
wrote:
If you need access to the methods in AProxifier then why does the
anonymous
class extend A, you should extend AProxifier as you would with any other
class.
Because A has the behavior I want to extend?
An other example:
class A {...}
class B {...}
class Factory
{
protected function protectedMethod() {...}
function getA()
{
return new class extends A {.. call Factory::protectedMethod()?
..};
}
function getB()
{
return new class extends B {.. call Factory::protectedMethod()?
..};
}
}
This is possible and welcomed with closures.
I see it as useful for anonymous classes than it is for anonymous
functions.
What do others you think about it?
-1
Just because a closure is an anonymous function does not mean that an
anonymous class has closure capabilites.
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Automatic Property Initialization
2013/9/27 Gordon Oheim g...@php.net
Independent but related to
-
https://wiki.php.net/rfc/**constructor-promotionhttps://wiki.php.net/rfc/constructor-promotion
I wrote an RFC about porting Dart-like Automatic Property Initialization
to PHP. Nikic was so generous to provide an initial PoC for it (since I
don't do C):
-
https://wiki.php.net/rfc/**automatic_property_**initializationhttps://wiki.php.net/rfc/automatic_property_initialization
-
https://github.com/php/php-**src/pull/474https://github.com/php/php-src/pull/474
I am proposing this for inclusion in 5.6.
There is no BC breaks afaik.
The RFC suggests to allow for $this-foo as Constructor arguments to make
the boilerplate code for property assignments in constructors superfluous.
This is the core feature subject to discussion.
I simply don't like it to have a concrete method without body. Either
abstract without body, or concrete _with_ body. In this case it would mean
to have an empty body
public function __construct ($this-x) {}
but I think that wouldn't be too bad :)
I've spoken to about two dozen developers outside internals prior to
suggesting this RFC and the general response was positive and the core
feature unanimously deemed useful. Moreover, in the previous discussion
about constructor promotion there was some messages suggesting that the now
proposed syntactic approach is more preferred than using visibility
keywords.
The RFC also suggests some related syntactic sugar like Methodless
Constructors, an alternate and shorter syntax, as well as making this
available in the entire class scope. These are things I am not sure of so I
am hoping for comments on these. Should this RFC get into the voting phase,
we should by then have either promoted or eliminated these options through
discussion.
Thanks and Regards, Gordon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Re: RFC: Automatic Property Initialization
2013/9/27 Matthieu Napoli matth...@mnapoli.fr
Le 27/09/2013 09:17, Gordon Oheim a écrit :
Independent but related to
-
https://wiki.php.net/rfc/**constructor-promotionhttps://wiki.php.net/rfc/constructor-promotion
I wrote an RFC about porting Dart-like Automatic Property Initialization
to PHP. Nikic was so generous to provide an initial PoC for it (since I
don't do C):
-
https://wiki.php.net/rfc/**automatic_property_**initializationhttps://wiki.php.net/rfc/automatic_property_initialization
-
https://github.com/php/php-**src/pull/474https://github.com/php/php-src/pull/474
I really like the proposal.
I just wonder about how it could mix/conflict with the named parameters
proposal? Given what you said about Reflection ($this-foo is treated like
$foo), then I guess it's not a problem then.
However maybe the RFC should reflect that you can't use:
public function __construct($this-foo, $foo) { … }
Also, at first glance I didn't find the methodless constructor very
useful (since it's only saving {}), but actually the possibility to use
this feature in setters too looks very good, it would avoid a lot of
boilerplate code.
Actually I would prefer to get rid of getters/setters completely and
finally get _real_ accessor methods like in
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
The ability to shorten the setters is interesting, but it makes them look
asymetric to their corresponding getter (which still requires a
body/code) and anyway: It just patches the symptom, that they are required
at all.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Rasmus Lerdorf ras...@lerdorf.com
On 09/22/2013 11:39 PM, Joe Watkins wrote:
https://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
I am having a hard time picturing a real-world use-case for this.
The use case is one-time usage of an implementation, where you currently
probably pass callbacks into a Callback*-class like
$x = new CallbackFoo(function() {
/* do something */
});
vs.
$x = new Foo () {
public function doSometing()
{
/* do something */
}
});
Imagine you have several abstract methods in one interface/class, which
would need several callbacks passed to the constructor.
Also '$this' is mapped to the right objects.
Regards,
Sebastian
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Anonymous Classes
2013/9/23 Joe Watkins krak...@php.net On 09/23/2013 02:43 PM, Lars Strojny wrote: Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins krak...@php.net: Morning All, https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Same as any other object; what you are creating is normal classes without a (declared) name, nothing about the objects functionality has differs from an object of a named class. When you serialize an object the serialized form contains the class name. So as long as the instance doesn't have a own class name it isn't possible to serialize it properly and even further to unserialize it, because the whole definition is gone. To sum it up: They aren't serializable. Imo it isn't such a flaw, that anonymous instances aren't serializable, because anonymous functions/closures aren't neither. Regards, Sebastian. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Re: RFC: Anonymous Classes
2013/9/23 Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl Everyone, As a lurker i rarely have anthing to say, but this time i'd like to make an exception: I see some usability for this type of usage, but would like to disagree on the extra class... My usage would be more in line with JSON way of passing around objects... But i'd hate to see yet another new class type and kind of feel the StdClass would've been more logical... To me it sounds like you mix something up and describe a different use case (which is already easily possible) $stdClass = (object) [ 'foo' = 'bar' ]; The RFC is about anonymous objects _with_ behaviour (- methods), whereas stdClass-objects doesn't have any methods. The reasons for this imho is that the StdClass is the one-for-all object without anything that's already there... (it's not like anonymous functions are something different than regular functions?) As for actual need: personally i can easily live without, but then again: we the influx of JSON-like notation / ubiquity this might make a logical follow up.. ? Met vriendelijke groet, Robin Speekenbrink Kingsquare BV 2013/9/23 Joe Watkins krak...@php.net On 09/23/2013 07:39 AM, Joe Watkins wrote: Morning All, https://wiki.php.net/rfc/**anonymous_classes https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe Serialization: As I have said, serialization does work, and unserialization does work ... Classes do have unique names, so as long as the entry is present upon unserialize you will get the object you expect ... if the entry is not present unserialization will fail silently. The same kind of thing can happen where you have declared a class based on some predicate, whose value has changed upon unserialize and so the entry is not present ... I'm not sure it is necessary to force any particular behaviour for serialization, it depends entirely on the application whether or not the entry is present upon serialization, it should be left down to the programmer. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Re: RFC: Anonymous Classes
2013/9/23 Joe Watkins krak...@php.net
On 09/23/2013 07:39 AM, Joe Watkins wrote:
Morning All,
https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
Cheers
Joe
Serialization:
As I have said, serialization does work, and unserialization does work
...
Actually if you cant unserialize a serialized object, it isn't a
serialized object, but only a string describing the object it was created
from.
Classes do have unique names, so as long as the entry is present upon
unserialize you will get the object you expect ... if the entry is not
present unserialization will fail silently.
Which name do you give them? The name of the originating interface/class?
if ($debug) {
$listener = new class extends ListenerInterface () {
public function onFoo() { debug(); };
};
} else {
$listener = new class extends ListenerInterface () {
public function onFoo() { normal(); };
};
}
$someBar-addListener($listener);
$x = serialize($listener);
The same kind of thing can happen where you have declared a class based
on some predicate, whose value has changed upon unserialize and so the
entry is not present ...
I'm not sure it is necessary to force any particular behaviour for
serialization, it depends entirely on the application whether or not the
entry is present upon serialization, it should be left down to the
programmer.
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Allowing is_* functions to accept multiple parameters
2013/9/18 Igor Wiedler i...@wiedler.ch
On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good reason to do this, because the var might not
exist at all, and as such you cannot use a function, as it would produce
warnings.
However, for is_* functions, this could easily be done with a higher-order
every function. You pass a predicate and an array of values. It returns a
boolean.
Example:
if (!every('is_int', $numbers)) {
throw new \InvalidArgumentException(...);
}
Actually it was about multiple parameters
if (!every('is_int', $a, $b, $c)) { /* .. */ }
To me using `is_int()` directly feels more intuitive too.
if (!is_int($a, $b, $c)) { /* .. */ }
Not only is that much cleaner in my opinion, it also is composable without
having to change *all* of the is_* predicates.
As such, I don't see much value in changing this.
Well, asking me that sounds like the same value like it is for
array_column(). It is a minor improvement, but it is an useful one (imo).
Just my 2 cent
Regards,
Sebastian
Igor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Re: Function autoloading
2013/9/3 Levi Morrison morrison.l...@gmail.com On Tue, Sep 3, 2013 at 10:54 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Sep 3, 2013 at 6:04 PM, Levi Morrison morrison.l...@gmail.com wrote: In which case we have very different ideas about what good design is and would never come to any agreement on that. This is already evident in ALL of your recent discussions on this ML. Go and look: you are the most active participant in each topic and you are bickering in each one. Could you please stop dominating every discussion? I'd to say it is more an attempt to understand the needs of one feature or another. This is why this ML exists, to discuss (which may move to arguing sometimes, so it goes). But I won't ever ask someone to stop participating to discussions, unless it goes off topic or the tone is not appropriate (had one recently where my tone was not the best, I stopped :). I didn't ask him to stop participating: I asked him to stop dominating every discussion. There is a significant difference. I must say, that I share this opinion. I follow this list quite a while now and it is not the first time, that the discussion about a quite promising proposal were dominated until one after the other leaves the discussion -- annoyed and demotivated. That being said, there is always a point in a RFC discussion where there is nothing left to discuss or argue about, we are so far with this one. We've been at this point for a while; no new arguments have been raised despite several people asking to bring it back in focus. -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Skipping parameters take 2
2013/9/2 Lester Caine les...@lsces.co.uk Ferenc Kovacs wrote: you write your code where you copypaste the default value some time passes somebody changes the default value in the called function definition your code now calls the function with a non-default value. Actually THAT is a problem I've hit in reverse! Some bugger changing the default in a library without understanding the consequences! In which case the fix was to put in the 'default' I wanted ... this works either way, but I could at least see in the IDE that the default had been changed so tracing it did not take as long as it could have. But thats a problem no language (with default values for parameters of course) can help you, except you avoid default values in every case. I for myself always use null as default value, so I must say, that a special keyword doesn't bring me any benefit. In this meaning: The named parameters are more useful :) Regards, Sebastian -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Skipping parameters take 2
2013/9/2 Pierre Joye pierre@gmail.com hi Stas, On Mon, Sep 2, 2013 at 9:17 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I've finally took some time to revive the skipping parameter RFC and patch. For those who doesn't remember what it is please see: https://wiki.php.net/rfc/skipparams TLDR version: The idea is to allow skipping parameters in function with optional arguments so that this: function create_query($where, $order_by, $join_type='INNER', $execute = false, $report_errors = true) can be called like this: create_query(deleted=0, name, default, default, /*report_errors*/ true); Instead of trying to remember what the defaults are. The patch is here: https://github.com/php/php-src/pull/426 Any comments or feedback on the RFCs and the code are welcome, especially pointing out the cases where it may not work (which means we need more phpt's there :) Using default instead of ,,, is indeed much more readable. However I still wonder what prevents to finally implement named parameters too, it will provide the same feature while being even more handy and easier. And it covers an additional use-case: Self-explaning parameters like in foo(is_strict = false) instead of foo(null, null, false). I could dig the archives but I don't remember what was the reason why we rejected the idea back then. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: AW: [PHP-DEV] [RFC] Skipping parameters take 2
2013/9/2 Stas Malyshev smalys...@sugarcrm.com Hi! I would not agree with your argument that it should be introduced because it is requested by real people for years and it is simple to add. Isn't that pretty much the same as because we can? No, it is pretty much the opposite. It is because people need it. I am a user and I don't need it and named parameters makes it obsolete anyway. Now it would be interesting, if people would need named parameters less, than the ability to pass default instead of null (or whatever) IMO we should wait with this RFC if Nikita is willing to write an RFC for named parameters including an implementation afterwards, because I think We've been talking about it for years (last time here: https://wiki.php.net/rfc/namedparameters) but nothing happened. But I'm certainly willing to give it a chance, if it is happening. I just not want for all the effort to be wasted if it's not and we'd be left without a solution for a real problem again. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
[PHP-DEV] Re: Function autoloading
2013/8/31 Vartolomei Nicolae nvartolo...@gmail.com So you say you will create a file for every function you want to support autoloading? I already _have_ create files for functions of a namespace... Closed source. As I already asked, tell us about realworld use case, for example where this could improve say big projects like Symfony or ZF. Not everything can be found in the 5 most popular frameworks. There is no logic to add this functionality just because we can. The lack of logic is: Why is it actually missing? - Classes: Triggers an autoloader - Functions: Needs manual handling - Constants: Needs manual handling That is at first inconsistent. The need of require_onces is inefficient and error prone. Regards, Sebastian kindly, nvartolomei On Friday, August 30, 2013 at 8:38 PM, Nikita Popov wrote: On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev smalys...@sugarcrm.com(mailto: smalys...@sugarcrm.com)wrote: Hi! Well, static methods aren't the same as functions. The big difference being? This seems to be the core of your argumentation in this thread: Why don't you just use Foo::bar() instead of foo\bar()? In which case, I wonder why we have functions at all. We could just use static methods instead after all. Maybe we should deprecate function support? On a more serious note: If you want an actual example of how functions can be easier to use than static methods, consider the use function RFC. Now that it's in, it is possible to directly import a function foo\bar() and use it with just bar(). Static methods allow no such thing. You always need to write the class name. The reason why people currently resort to using static methods instead of functions is the fact that there is no autoloading for functions. With autoloading, functions become a lot easier to use. Nikita -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com Hi! I disagree on the basis that namespaced functions/constants *do* fit the same autoloading paradigm. If they're already namespaced, what prevents one to put it in a class and use good old PSR-compatible loading? Well, static methods aren't the same as functions. Those function calls would only kick in if the function/constant wasn't already defined, which will be the exception case, so perf isn't a strong argument. Not according to the code I see in the patch. There I see 2 func calls (among other things) before the hash is even looked up. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com Hi! I have created a new draft RFC implementing function and constant autoloading in master: https://wiki.php.net/rfc/function_autoloading All feedback is welcome. I think it is an unnecessary complication. Classes fit autoloader paradigm nicely, since the usual pattern is one class per one file (actually recommended in PSR), so it is easy to establish one-to-one automatic mapping between classes and files (also recommended in the PSR). Autoloading was introduced long before PSR-0 and PSR-0 is also only a recommendation. So saying class autoloading was easily introduceable, because there was _always_ a class-file mapping is somehow misleading. But for functions nobody does this. This means that to implement function autoloader one will need to have a complicated and fragile logic (since there's no way to ensure this logic would be in sync with actual content of files containing multiple functions). This is the same complicated and fragile logik you need for class loading. For example compared to PSR-0 functions could be implemented in a file named after the namespace. An autoloader would be very similar to every already existing PSR-0 class loader. Moreover, since this replaces a simple hash lookup with additional two function calls (and also other operations included in those) everywhere in the engine, it will also have performance impact of one of the most frequently used operations in the engine - function calls - while providing absolutely no benefit for 100% of existing code and 99.99% of future code. Putting autoloading of different entities into one function makes very little sense to me - why would the same code load both classes and functions? How would it do that besides ugly switch that just stuffs two completely different logic pieces into one function for no reason? The example given in the RFC is certainly not what anybody would actually want their autoloaders to do, so I fail to see any case for doing it and for putting loading more than one entity into one function (that given that autoloading function would be desirable at all, which it still doesn't seem so for me). It is -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com Hi! Well, static methods aren't the same as functions. The big difference being? A function is stateless [1], a method isn't. A function operates only on the passed parameters [1], the method operates on the parameters and the context it inherits from the instance (non-static), or class (static and non-static). [1] Beside IO and global variables-hacks -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Syntax for variadic functions
2013/8/30 jbo...@openmv.com jbo...@openmv.com
On Wed Aug 28 11:47 AM, Nikita Popov wrote:
https://wiki.php.net/rfc/variadics
Interesting idea, expanding on:
function log($message, ...$options) {}
It would seem convenient to allow ...$options to be passed as a key-value
array of arguments as well:
function logA($message, ...$options[]) { echo count($options); }
logA(foo); // 0
logA(foo, 1, 2); // 2
logA(foo, array(1,2,3)); // 3
The difference here is that variadic options is declared as an optional
array, it would not support a 'typehint' forcing all arguments to be of the
same type.
It could be a way to support ~ named parameters
// requires at least 1 argument named as 'level'
function logB($message, ...$options['level']) {
echo $options['level'] .' '. count($options);
}
logB(foo);// fails: 'level' argument
missing
logB(foo, 'notice'); //notice 1
logB(foo, ['level' = 'notice']); // notice 1
logB(foo, 'notice', 'extra'); // notice 2
logB(foo, ['level' = 'notice'], 'extra'); // notice 2
// requires min 2 arguments
function logC($message, ...$options['level','priority']) {
echo 'level:'. $options['level'];
echo 'priority:'. $options['priority'];
}
logC(foo, notice, 4);
logC(foo, ['level' = 'notice', 'priority' = 4]);
That would remove the need for a splat or scatter operator. The
declaration ...$options[] would mean, I accept an array of arguments
followed by extra arguments
I'd recommend to use an object, or separate parameters instead. Thats not a
use-case for argument-lists.
Regards
Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
2013/8/31 Stas Malyshev smalys...@sugarcrm.com Hi! We got a performance win from exactly this at Facebook. We have some extensions in HHVM to autoload that allowed us to remove almost all our *_once calls. But autoloading does not remove require - you still have to load the files. But it removes many many 'require_once's. Only thing that can be removed is a non-loading require. Is it that frequent that it had significant performance impact (given that with opcode caching non-loading require is pretty much a couple of hash lookups)? Those, who doesn't wrap anything in classes, can see this very frequently. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default
2013/8/22 Yasuo Ohgaki yohg...@ohgaki.net Hi all, I realized that not many users are using more entropy parameter Therefore, I made Request #65501 uniqid(): More entropy parameter should be true by default https://bugs.php.net/bug.php?id=65501 The comment title explains what this FR is. Any comments? Tbh I don't get the real problem with the _current_ behaviour. Who need the entropy, can set it as second parameter and I am not sure, if it is wise to use uniqid() for _security purposes_. Regards Sebastian -- Yasuo Ohgaki yohg...@ohgaki.net -- github.com/KingCrunch
Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default
2013/8/22 Leigh lei...@gmail.com On 22 August 2013 13:39, Sebastian Krebs krebs@gmail.com wrote: Tbh I don't get the real problem with the _current_ behaviour. Who need the entropy, can set it as second parameter and I am not sure, if it is wise to use uniqid() for _security purposes_. It's absolutely not wise to use it for anything security related, the purpose of the function is simply to provide a unique value within a system, not a random value, not an unpredictable value. Thats what was my thought too, but the bugreport states Without more entropy, uniqid() may produce non unique id even if the name states it. This could be security issue under certain cases. more_entropy in this case might as well be called higher_resolution. As Nikita already pointed out, without this flag set a usleep is performed to force function calls to be at least 1 microsecond apart (since the id is microtime based). All more_entropy does is add some additional random on the end instead of the usleep so when uniqid is called multiple times during the same microsecond, the values are still (probably) unique. Wait ... With more it is _faster_?! (Havent read Nikitas mail so closely before...). Definitely something I should remember ^^ My trivial mind would assume, that the longer output would take more effort. Making the function return a longer output by default is a BC break imo. As already pointed out constrained DB fields will not accept the new default, filenames generated using it will no longer conform to a set pattern, etc. etc. Worth to mention: The longer output also contains a dot ., which may lead to worse things with filenames ;) Regards, Sebastian -- github.com/KingCrunch
RE: [PHP-DEV] [RFC] Constant Scalar Expressions
Am 14.08.2013 08:17 schrieb Christian Stoller stol...@leonex.de: Hello all, I'd like to propose a new RFC for 5.NEXT: https://wiki.php.net/rfc/const_scalar_expressions This allows for defining constant expressions which are resolved at compile time. What should that be for? const FOO = 1 + 1; const BAZ = HELLO . WORLD!; Why not just writing const FOO = 2; const BAZ = HELLO WORLD!; I think it makes code les readable. And if you want to give an important hint for the reader of the code, you can still write comments. Other examples are better I think const $flag3 = 17; const $timeout = 60*8; For strings it can make sense to avoid newlines, when you want to split a long string onto several lines. Best regards Christian
Re: [PHP-DEV] [RFC] Constant Scalar Expressions
Hi,
Just asking: Does this cover only declarations, or every constant
expression, for example
$weeks = $secs / (60 * 60 * 24 * 7);
becomes to the opcode-equivalent of
$weeks = $secs / (604800);
?
2013/8/14 Anthony Ferrara ircmax...@gmail.com
Stas,
On Wed, Aug 14, 2013 at 5:01 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
https://wiki.php.net/rfc/const_scalar_expressions
I like the idea, but absence of constant support makes this thing much
less useful, as you can't do things like:
public $angle = M_PI/2;
I think this is one of the reasons this idea was never implemented -
because without constant support you're limited to doing things that are
quite obvious and trivial.
Yeah, having constants in those expressions would be great. If only
constants in PHP were actually constant...
But this win is really cheap (a trivial change to the parser), so I figured
it was worth proposing separately. If we want to add the opcode stream
later to do expressions for constant values, we can. This just gives us the
quick win today of allowing relatively trivial, but important expressions.
The biggest wins I see are in power-of-2 math:
class Foo {
const FLAG_1 = 1 0;
const FLAG_2 = 1 1;
const FLAG_3 = 1 2;
const FLAG_4 = 1 3;
const FLAG_5 = 1 4;
const FLAG_6 = 1 5;
const FLAG_7 = 1 6;
}
And in other complex formulas where having the self-declaration adds
semantic meaning.
Now, as far as if it's worth while making the change without constant
support, that's for each of us to decide. I think it is, but if you don't,
that's cool too.
Thanks
Anthony
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Importing namespaced functions
Hi, Whats about constants? Regards, Sebastian Am 19.07.2013 19:30 schrieb Igor Wiedler i...@wiedler.ch: Hello internals, I posted the initial idea for a use_function RFC a few months back. I would like to make the proposal official now, and open it for discussion. I also did some work on a patch that probably still has some issues. Review on that is welcome as well. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 Regards, Igor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Importing namespaced functions
Hi,
Thanks for that.
But actually I don't see: Why is use not enough? As far as I can see your
example, why it would introduce a BC, doesn't really match to original
question, why use function is used. Especially I don't see any ambiguity:
foo(); // Always a function. You cannot call classes this way
new foo(); // always a class
foo::bar(); // Always a class
But the example I mentioned before
namespace {
function bar() {}}
namespace foo {
function bar() {}}
namespace {
use foo\bar;
bar();}
points to a different problem, which I didn't see solved by adding the
function-keyword to use. Can you clarify this? Because I'd try to avoid
new syntax wherever possible.
Regards,
Sebastian
2013/7/23 Igor Wiedler i...@wiedler.ch
Hi,
Based on Sebastian's feedback I have updated the RFC and the patch to
include a `use const` sequence that works just like `use function`, but for
namespaced constants.
Example usage:
namespace foo\bar {
const baz = 42;
}
namespace {
use const foo\bar\baz;
var_dump(baz);
}
I also fixed some other issues that the original patch had in the process
(see commit history). Please keep the feedback coming.
Thanks,
Igor
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Importing namespaced functions
2013/7/23 Stas Malyshev smalys...@sugarcrm.com Hi! But actually I don't see: Why is use not enough? As far as I can see your example, why it would introduce a BC, doesn't really match to original Consider this: use a\b\c as foo; foo(); Now it would resolve to global function foo(). If use were changed to apply to functions, it would resolve to function \a\b\c() instead. But if I explicitly import foo this way, this is intended :? Yes, foo could also be a classname, but right now it is also not part of the language to detect collisions. Additional I have _never_ seen any core- or user-function, whose name could be a classname to. Of course I've never seen every function ever written, but even if this a real issue, how many people are really affected? Regards, Sebastian. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Importing namespaced functions
2013/7/23 Igor Wiedler i...@wiedler.ch Hi Sebastian, The reason is precisely to avoid BC breaks, such as the one that you quoted from the FAQ. Are you suggesting that such a BC break is acceptable for 5.6? I don't fear BCs and actually I prefer BCs against weak compromises. This depends on the weight of the BC ;) But aside: I am a regular user, not a core-dev or something. I just comment. As much as I dislike introducing new syntax, keeping BC was the reason I did so. -- github.com/KingCrunch
Re: [PHP-DEV] PHP proposal on modular systems
2013/7/16 Giuseppe Ronca giuseppe.ron...@gmail.com
I've studied Composer and as i thought ..it's a component installer
(implementing an autoload system) .. nothing else ( i can have similar
result using git submodules )
anyway , *you can have a class collision using or not using composer ( it
doesn't solve it, but just advise you that you can't install that package
)*
I fear having multiple implementations of the same class in the same
process will result in something worse than a simple class name collision.
Again: It is up to the plugin-/addon-maintainer to keep their products
up-to-date and compatible.
for example, if i require those packages ( that require respectively
monolog 1.3 and monolog 1.2 ) :
{
require: {
dbarbar/campfire-monolog-handler: dev-master,
swestcott/monolog-extension: dev-master
}
}
*composer will shows it:*
- Can only install one of: monolog/monolog[1.3.0, 1.2.0].
- Can only install one of: monolog/monolog[1.3.0, 1.2.1].
- *Conclusion: don't install monolog/monolog 1.3.1 *
so , since both of packages need same library ( but with different version
) you can't install them.
It's the same limitation that you can find in CMS and external extensions
...and it's a language issue ofc.
2013/7/15 Marco Pivetta ocram...@gmail.com
On 15 July 2013 16:51, Giuseppe Ronca giuseppe.ron...@gmail.com wrote:
I'm not talking about this kind of problem...
I think you know how a CMS works ... we've for example :
* *CMS sources that are developed by Joomla devs ( i.g ) with theirs
libraries.*
* *Plugin (A) developed externally and installed by the final user, that
includes inside its sources pclzip library ( the version and library
doesn't matter) .*
* *Component (B) developed externally and installed by the final user,
that
includes inside its sources pclzip library again.*
That's why you got two names for a different implementation of the same
thing.
You can't call your own thing the same as the original one: it's not the
same.
That would even confuse the consumer, which doesn't know if it's the
original or the new one.
Now ..since that library could not be installed in CMS by default, since
devs of the Plugin (A) can't know if needed library is installed ( at
their
needed version ) inside another component...*we will have ofc a name
collision when both plugin and component will be loaded.*
That's actually one of the problems solved by composer...
It could be also a problem of various languages...but classes in local
scope / nested are a known technique used by different languages..and
php
could implements it even better.
These classes still live under their own package, and their fully
qualified name is different from all others.
In this way any CMS/Extension can arbitrary decide to use load their
components/library in a private scope ( avoiding collision ) .
i.g:
class Loader {
public static function LoadComponent () {
local_include foo_component/loader.php;
}
}
This is really coupled to your own system and with how extensible you
design it.
You may look at modern PHP frameworks to see how the problem of
extensibility is solved: it's mainly a DI/configuration issue that has
nothing to do with class names.
PS i'm not so practice with composer ( used few times ) but when modular
systems , such as CMS , give the possibility to extends them with
external
components...i don't think that composer could solve this problem.
It is actually already happening.
You should really really really check it out before going further in
exploring already explored grounds.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
--
github.com/KingCrunch
Re: [PHP-DEV] PHP proposal on modular systems
2013/7/16 Giuseppe Ronca giuseppe.ron...@gmail.com
You can have multiple objects from the same type in different
implemenations in the same process?
No i'm not saying it.
OK, what then? You have A and B, that both rely on X, but in version 1 and
2. Both A and B are used at the same time. How can now be possible, that X
is _not_ instanciated in the same process with different implementations?
What should happen, when I instanciate an object of test in version X
and
pass it to a function, that expect it as version Y? To be consistent PHP
_must_ trigger an error too, if something from the locally included file
leaves its scope
class foo {
public static function bar () {
local_include test.php / / file which includes test class;
return new test (); // -- error here
}
}
Because else it is not a local scope anymore.
the concept as i said is the same of nesting a class inside another ( or
dynamically namespacing a file )
if two different components need Library v1.0 and Library v2.0 .. they
will probably have same classes and namespaces ( but the code is not the
same ). So how could we use both lib at the same time? Actually php can't
load classes in a scope way so you can't do it in any way on global scope.
nesting dynamically libraries inside a namespace or a class , we can
create objects that can be accessed only throught their root
namespace/class...something like:
new Version1\ExternalLibrary\FooClass();
new Version2\ExternalLibrary\FooClass();
and also Composer will thankyou about it since they can solve
automatically problems .
It will lead to new problems... Lets say you have a third component C, that
works both X in both version 1 and 2. So now I say new X(). What should
happen? If 1 is instanciated, it is compatible to A, but if 2 is
instanciated it is compatible with B. I cannot simply pass that object to A
and/or B.
Backward compatibility (or compatibility in general) between component is
something the plugin maintainer should take care of, not the language.
Regards,
Sebastian
i'm talking about backward compatibility of php version...not external
plugins etc...i think that my idea doesn't require any change to php apps
to adapt their code.
But I am talking about compatibility in general (or backward compatibility
in special). :)
--
github.com/KingCrunch
Re: [PHP-DEV] PHP proposal on modular systems
2013/7/15 Lester Caine les...@lsces.co.uk Marco Pivetta wrote: PS i'm not so practice with composer ( used few times ) but when modular systems , such as CMS , give the possibility to extends them with external components...i don't think that composer could solve this problem. It is actually already happening. You should really really really check it out before going further in exploring already explored grounds. The real problem here is with PEAR being installed as part of the distribution, and not then being compatible with other applications. The safest way to use this is by bundling the correct version with the application, but that does create bigger downloads. Even were applications using the like of Zend framework need the correct version given the number of wrapper systems that go with it. Composer is just another complication that has to be added to the mix ... and not currently common in linux distributions? No need for: $ chmod +x composer.phar $ # use it -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] PHP proposal on modular systems
2013/7/14 Giuseppe Ronca giuseppe.ron...@gmail.com
Php is now used by many CMS, many of which use a modular system with a wide
range of add-ons developed by third parties. This can cause various
conflicts, such as when two or more external components using the same
library (i.g. with a different version) in this case the classes /
namespace will be in collision. This can become unmanageable by the
webmaster because they are not always able to change third parties code and
there aren't other clean methods to solve this kind of problem ( complex
and dirty eval methods excluded ).
here you are a thread related to this issue:
http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library
*One possible solution* would be to extend the scoping for the inclusions
of files using something like:* local_include_**
in this way you can also create a sort of nesting system for classes
making possible a syntax like this:
class foo {
public static function bar () {
local_include test.php / / file which includes test class;
return new test ();
}
}
echo get_class (foo :: bar ()) / / output: test
new test () / / raise an error instead
*Also this could work:*
namespace {oldversion
local_include / lib/api-1.0/library.php;
}
namespace {newversion
local_include / lib/api-2.0/library.php;
}
$ oldlibary = new oldversion \ Library ();
$ newlibrary = new newversion \ Library ();
It shouldn't have backward compatibility issues since it's a new
implementation and you shouldn't change anything else.
What do you think about that?
You can have multiple objects from the same type in different
implemenations in the same process?
What should happen, when I instanciate an object of test in version X and
pass it to a function, that expect it as version Y? To be consistent PHP
_must_ trigger an error too, if something from the locally included file
leaves its scope
class foo {
public static function bar () {
local_include test.php / / file which includes test class;
return new test (); // -- error here
}
}
Because else it is not a local scope anymore.
Backward compatibility (or compatibility in general) between component is
something the plugin maintainer should take care of, not the language.
Regards,
Sebastian
--
github.com/KingCrunch
Re: [PHP-DEV] Gauging Interest:RFC to add map() function
2013/6/27 Tjerk Anne Meesters datib...@php.net
On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan florinpa...@gmail.com
wrote:
On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters datib...@php.net
wrote:
On Wed, Jun 26, 2013 at 11:20 PM, Jeremy Curcio j.cur...@icloud.com
wrote:
Hello,
I would like to submit an RFC to add a new function to the PHP
language.
The function would be called map(). The purpose of this function
would be
to take an existing value within a range and make it to a
corresponding
location within a new range.
The map() method would have 5 required parameters, $originalLow,
$originalHigh, $newLow, $newHigh, and $value.
map() would be implement the following:
function map($originalLow, $originalHigh, $newLow, $newHigh, $value) {
return $newLow + ($value - $originalLow) * ($newHigh - $newLow) /
($originalHigh- $originalLow);
}
Purely from a development perspective, having five required function
arguments is bad; it can be reduced (by treating the first four as two
ranges) to three arguments, e.g.
map([55, 92], [70, 100], 55);
You can go one step further and call it what it is, not a mapper, but a
single dimensional range transformer and use a closure, e.g.:
$transformer = get_1d_range_transformer([55, 92], [70, 100]);
echo $transformer(55); // get transformed value
You might also benefit from an OOP approach. I won't paste it here, but
I've created a pastie for it: http://codepad.org/nGZv8GJa
It's debatable whether this somewhat specialized code would need to be
coded at something other than the language level; in most likelihood
you
won't gain any appreciable performance increase.
Example:
Let's say we are teachers and are grading final exams. We have a
policy
that the best score is 100, and the worst score is a 70. Students
scored
between 55 and 92. We want to easily re-score the exams to be within
the
new score range, so we would use the new map() function. Let's begin
with
mapping the lowest score:
$newScore = map(55, 92, 70, 100, 55); //$newScore = 70
If we have all of our scores in an array:
$scores = array(71, 65, 55, 85, 88, 86, 92, 77, 73);
We could use a foreach loop to remap each value:
$newScores = array();
foreach($score as $scores) {
$newScores[] = map(55, 92, 70, 100, $score);
}
var_dump($newScores);
/*
array(9) {
[0]=
float(82.972972972973)
[1]=
float(78.108108108108)
[2]=
int(70)
[3]=
float(94.324324324324)
[4]=
float(96.756756756757)
[5]=
float(95.135135135135)
[6]=
int(100)
[7]=
float(87.837837837838)
[8]=
float(84.594594594595)
}
*/
Just like that, we have the new exam grades that fit our policy,
within
the proper scale, without having to do any of the messy math
ourselves.
While I do recognize that this is somewhat trivial to anyone who knows
the
proper formula, I feel as though it would serve the PHP community
well.
Much the same as the pow() or pi() functions do. I appreciate your
thoughts
on this matter and whether or not this is worth pursuing as an RFC.
Thank you,
Jeremy Curcio
j.cur...@me.com
--
--
Tjerk
Hi,
May I kindly ask why all the PHP users would want this function in the
core?
Are you meaning to ask why would *any* php user want this function in the
core? As with most things, the need of one may be shared among a critical
mass that could swing the balance. In practice though, the critical mass is
usually determined by the internals peeps :)
But this method is _really_ quite special, isn't it? I cannot imagine, that
there is critical mass, that needs this _in core_.
Just to remind: It works with pure-PHP too. Also you may provide this as
PECL-extension if performance is important.
I've never needed such a function nor do I understand why we should
have it. It's good for what?
It's good to perform affine transformation in a single dimension; if you've
never done this before, you wouldn't need it.
And as I understand, PHP delegates the math stuff to the underlying C
implementation so why would it be faster having it in PHP core rather
that in PHP userland?
Performance is not the only reason why features make it into the core; it's
providing a rich set of built-in features to make the developer's lives
easier, such as the latest password hashing API which is easy to get wrong
or generators that reduce boiler plate code.
You cannot compare language features (generators) with functions. And
security is always a topic on its own.
As such, an addition to the
set of numerical functions to address a particular use-case is not
unthinkable.
Thanks
Florin Patan
https://github.com/dlsniper
Re: [PHP-DEV] New syntax for multidimensional array loop with foreach
2013/6/27 Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl
I'd thought this would have been `solved` by allowing the list statement in
foreach (
http://nl3.php.net/manual/en/control-structures.foreach.php#control-structures.foreach.list
)
Doesnt that solve your problem already?
This is only useable for structs, not for lists, or sets.
Kind regards,
Robin Speekenbrink
2013/6/27 Florin Patan florinpa...@gmail.com
On Thu, Jun 27, 2013 at 4:10 PM, Christian Stoller stol...@leonex.de
wrote:
Hi internals,
during my current work I had an idea for shorter array iteration with
foreach. I haven’t seen such a syntax until now, but I think it is easy
to
understand ;-)
Maybe you know the case where you have to iterate over all values of a
2D (or more) array:
$count = 0;
foreach ($array as $key = $innerArray) {
foreach ($innerArray as $innerKey = $value) {
$count += $value;
// and do something with $key and $innerKey
}
}
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
}
If the keys aren't needed, you can shorten it to:
$count = 0;
foreach ($array as $innerArray as $value) {
$count += $value;
}
What do you think?
--
Christian Stoller
LEONEX Internet GmbH
Hi,
Quick question, how would the engine then treat this case:
$array = array();
$array['level1.1']['level2']['level3'] = 'value';
$array['level1.2'] = new StdClass();
foreach($array as $level1 as $level2 as $level3) { ... }
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] New syntax for multidimensional array loop with foreach
2013/6/27 Florin Patan florinpa...@gmail.com
On Thu, Jun 27, 2013 at 4:10 PM, Christian Stoller stol...@leonex.de
wrote:
Hi internals,
during my current work I had an idea for shorter array iteration with
foreach. I haven’t seen such a syntax until now, but I think it is easy to
understand ;-)
Maybe you know the case where you have to iterate over all values of a
2D (or more) array:
$count = 0;
foreach ($array as $key = $innerArray) {
foreach ($innerArray as $innerKey = $value) {
$count += $value;
// and do something with $key and $innerKey
}
}
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
}
If the keys aren't needed, you can shorten it to:
$count = 0;
foreach ($array as $innerArray as $value) {
$count += $value;
}
What do you think?
--
Christian Stoller
LEONEX Internet GmbH
Hi,
Quick question, how would the engine then treat this case:
$array = array();
$array['level1.1']['level2']['level3'] = 'value';
$array['level1.2'] = new StdClass();
foreach($array as $level1 as $level2 as $level3) { ... }
When I get this right it would fail. As far as I see this is equivalent to
foreach ($array as $level1) {
foreach ($level1 as $level2) {
foreach ($level2 as $level3) {
// ..
}
}
}
So I'd say they should behave the same.
I for myself find this proposal at least interesting. I don't know how many
foreach-chains I see every day :(
Regards,
Sebastian
Best regards
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: Protocol Type Hinting
2013/6/27 Anthony Ferrara ircmax...@gmail.com Stas et al, So, the question of what is the difference between the two errors remains unanswered. If the whole diff is that one of the errors has word recoverable in the message, it's not substantial difference at all and one that does not require new syntax and big change in the language. I'm assuming that you do know the difference between E_RECOVERABLE_ERROR and E_ERROR. And the difference is not trivial... Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it Can we please lay the goto argument to rest? The argument goto was introduced, so feature X must too, because goto was introduced didn't sound good even the first time... I'm absolutely not trying to say we should include this because GOTO was introduced. I'm trying to point out the circular nature of the argument of good-vs-bad practice in general... should enable today's good practice to be followed. But it should not take a stand about bad practice. In my opinion, we should. We should not take into the language any concept that anyone considers useful in some particular piece of code. PHP language is very widely used, and we should consider how it would influence this huge ecosystem and if the overall effect would be beneficial and justify complicating (if there is one) the whole language system. Language is a system of thought and a system of approaching communication. IMO, this means it should have some principles and not just be a random bag of things that somebody at one point or another decided to stick into it, they should make sense together. PHP doesn't have the best reputation in this regard, but we are trying to make it better, not worse. It does not mean we should avoid change. It means we should have good reasons for change and carefully consider it. Good use cases IMO are prerequisite for that. Of course they are. Use-cases matter. A lot. But good practice vs not-good-practice shouldn't be a significant factor, because your good-practice is different from mine. And unless we as a group decide to stick to one interpretation (we haven't), then it's kind of pointless to talk about good practice. If you want to vote based on it, that's your prerogative. But in general I think that thought process is dangerous for the community as a whole and for core... My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. IMO there's no merit in the feature besides its use. That's the only merit a feature could or should ever have. Ok, so then you agree that best-practice doesn't come into it at all...? Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to In fact, most other dynamic languages don't even have parameter typing. Neither Perl, Python, Ruby or Javascript have it. Let alone typing of the kind you suggest. What they have we have too. Duck typing for them doesn't mean what you propose - it means what we already have, checking type at the point of use. Check https://en.wikipedia.org/wiki/Duck_typing and see the examples - most of them don't have any typechecks. Referring to most dynamic languages while promoting this proposal is a bit misleading. Those other languages (all of them in fact) throw exceptions if the function or method does not exist. PHP hard fatals. They can live with pure duck-typing because their engines are designed to stay running, where ours is designed to fall on its face. This proposal is one attempt to bring some consistency and recoverability to the dynamic aspect of programming while providing for the ability to verify APIs at the engine level. One thing I find interesting is that I have discussed this feature with about 50 people at this point (quite a few at conferences and such before actually proposing it), and the sentiment elsewhere (not on list) was very predominately this solves a ton of problems. I find it interesting that on-list people seem to think that I'm making the use-cases up, and that there's not really a problem to solve. I wish some of the other people I talked to would speak up here ;-)... You havent talked to me, but I bring my voice in. One thing to note is who the major audience for a feature like this is. It's not predominately for 1st party developers (developers writing one-off applications). It's not predominately for 2nd party developers (developers writing frameworks and other applications that have few dependencies and are intended to be used by 1st party
Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Amaury Bouchard ama...@amaury.net
2013/5/28 Maciek Sokolewicz maciek.sokolew...@gmail.com
It’s a good idea in general but what about having it for variables as
well? Could open interesting possibilities for an optimizer.
final $foo = str;
$foo = bar; // bails out
Don't we already have that? It just has a different name: constants.
It's different. You can manipulate variables in some ways you can't with
constants.
This code, for example:
$a = 'abc';
$b = 'a';
print($$b);
It will display abc. It's currently not possible to do something similar
with constants.
define('FOO', 'bar');
$b = 'FOO';
print(constant($b));
and yes, constant() works for namespace- and class-constants too.
I think the subject was already debated, but I wonder why we should write
that:
final $foo = 'bar';
instead of:
const $foo = 'bar';
--
github.com/KingCrunch
Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Amaury Bouchard ama...@amaury.net 2013/5/28 Sebastian Krebs krebs@gmail.com print($$b); print(constant($b)); It's definitely different. In your example you have to know that you are manipulating constants only. And in your example you have to know, that you are manipulating a variable :? -- github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@gmail.com
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
Something I don't understand: You call test() in line 7 and line triggers
the error, so in fact it is _really_ line 3, that causes the message. So
why should it display line 7, when it is obvious the wrong line?
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file name to
display.
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com
wrote:
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie.
the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file
name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain
for
the execution.
I think that this is a sensible default, and allowing to fake that from
the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that
there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line numbers.
You would either need to hardcode those in your application and make sure
that the reference and the actual content of your file is in sync (you
will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist
Exceptions (there you can add a backtrace) too, but you have to catch them,
if not your script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug
trigger_error's notices. (But I don't know if only adding a third parameter
to trigger_error is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Thomas Anderson zeln...@gmail.com
On Tue, May 7, 2013 at 2:04 PM, Sebastian Krebs krebs@gmail.comwrote:
2013/5/7 Thomas Anderson zeln...@gmail.com
If you do user_error('whatever') it'll show, as the line number for that
error, the line number on which that user_error() call is made. It'd be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie. the
line that the call to the test() function is made).
Something I don't understand: You call test() in line 7 and line triggers
the error, so in fact it is _really_ line 3, that causes the message. So
why should it display line 7, when it is obvious the wrong line?
I thought half the point of OOP was to abstract away the internals and as
is the error messages don't make much sense unless you *do* consider the
internals.
Part of OOP are Exceptions.
Like let's say you have a bignum library and you're doing
$fifteen-divide($zero) on line 5 of test.php. Seems to me that it'd be
more useful to say error: division by zero on line 5 of test.php instead
of line line xx of file yy. It's like...
Somebody else already mentioned, that he wants to trigger notices at first,
but here the application is broken. So (see above) Exception is more
apropriate.
ooh - let me try to find where I'm doing division by zero. Let me to line
xx of file yy that I didn't even write and don't know a thing about. ok...
so it looks like that's in the private _helper_function(). And
_helper_function() is called by 15x other public functions. I give up!
You should have validated the input parameters before every of the 15 calls.
As an end user of a library you shouldn't have to actually look into that
library if you're the one who's not properly handling something.
In an ideal world you are propably right, but this is rarely
possible/useful.
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 21:07 schrieb Sebastian Krebs krebs@gmail.com:
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 18:25 schrieb Ferenc Kovacs tyr...@gmail.com:
On Tue, May 7, 2013 at 6:09 PM, Thomas Anderson zeln...@gmail.com
wrote:
If you do user_error('whatever') it'll show, as the line number for
that
error, the line number on which that user_error() call is made. It'd
be
nice if you could control the line number and file name that was
displayed.
eg.
?php
function test() {
user_error('whatever');
}
test();
?
That'll say Notice: whatever in ... on line 4 (ie. the line that the
user_error is on) instead of Notice: whatever in ... on line 7 (ie.
the
line that the call to the test() function is made).
If the displayed line numbers could be controlled by user_error then
debug_backtrace could be used to get the desired line number / file
name to
display.
line 3, but I suppose that is just a typo on your part.
the default error handler reports the line when the actual error is
generated and it also provides a backtrace so you can see the callchain
for
the execution.
I think that this is a sensible default, and allowing to fake that from
the
userland would make the debugging of the problems harder, as many/most
people would look up the file:line number and would be surprised that
there
is no E_USER_* thrown there.
Additionally I'm not sure how/where would you get your fake line
numbers.
You would either need to hardcode those in your application and make
sure
that the reference and the actual content of your file is in sync (you
will
screw yourself over sooner or later) or you would use __LINE__ + offset
which is still error prone..
I didn't like this proposal.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error originates
from.
Still don't get it:
if ($errorCond) {
trigger_error();
}
The error orginates from at most one line before...
And $errorCond may have some long complicated preprocessing by internal
functions of the framework I don't want to know about, so that I cannot
imagine instantly what's going on?
You debug today trigger_error's in libraries with putting a
debug_print_backtrace behind the trigger_error.
I use a debugger :X
I don't know why, but I find it more comfortable to debug with gdb than
with xDebug. With gdb it's only setting a break into the trigger_error
function and then use zbacktrace... But for debugging on some production
system because only there something goes wrong for some reason, I wouldn't
want to install xDebug (which will be loaded at every request...).
Yes, debugging by logs is hard and debugging on a production is not
ideal, thus you should try to reproduce the problem on your development
machine. Here you can have any extension you like :)
But to some my concerns up: I am unsure, if it is useful to let the error
message lie to you. It should tell you, where it appears, not where some
reason occured (or not), that might cause the call, that contains the line,
where the error occurs.
function foo1($a) {
foo2($a);
}
function foo2($a) {
foo3($a);
}
function foo3($a) {
foo4($a 0 ? 0 : $a);
}
function foo4($a) {
foo5($a);
}
function foo5($a) {
if ($a == 0) trigger_error('Foo');
}
foo1(42); // OK
foo1(0); // Error
foo1(-42); // Error, but the wrong value now comes from foo3()
So now which line should the error report? Note, that in foo3 is a
condition, which makes it non-trivial to find out, where the wrong value
were injected the first time.
btw: Ever considered assert() to find such situations during development?
(Of course you should disable them on production)
Regards,
Sebastian
I think you should be able to track down the error source without
manipulating any library code in the best case (yeah, there exist
Exceptions (there you can add a backtrace) too, but you have to catch them,
if not your script will abort; but I only need a notice...)
What I'm doing now is using my own error handler, add a called at
[line:file] and output the string myself (via fwrite to STDERR). I don't
think that this is the right way, this seems to me more like a temporary
solution.
Please change there something that makes it easier to debug
trigger_error's notices. (But I don't know if only adding a third parameter
to trigger_error is enough...)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Bob
--
github.com/KingCrunch
Re: [PHP-DEV] idea: letting the line number and file name be set via user_error
2013/5/7 Bob Weinand bobw...@hotmail.com
Am 7.5.2013 um 22:11 schrieb Stas Malyshev smalys...@sugarcrm.com:
Hi!
And today we have the problem that we cannot use in any useful manner
trigger_error in libraries, when we don't know where the error
originates from. You debug today trigger_error's in libraries with
putting a debug_print_backtrace behind the trigger_error. I think you
Why not use a debugger to debug? Debuggers have backtrace tools.
(there you can add a backtrace) too, but you have to catch them, if
not your script will abort; but I only need a notice...)
If you need additional information in the notice, you can always add it
to the text of the notice.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nothing against the debugger, but it'd be something really time saving to
see the entry point instantly instead of having to use the debugger first...
And yes, I can add it to the text (I can even add a function between which
analyses the backtrace first), but I think we need more useful (= more
information) error throwing in PHP?
How do you want to find out, which call _initially_ set the invalid values?
Is this even (reliable) possible? I've given an example, that it isn't that
trivial.
So even if you have the two additional parameters, what will you set there
(except maybe something like __LINE__-4, which is as trivial as useless)?
With this in mind: How do you think the additional parameters _can_ help?
Another example
function foo() {
return 0;
}
function bar($a) {
div($a);
}
function div($a) {
if ($a == 0) trigger_error('');
}
div(bar(foo()));
Which line should the message report now:
- bar() because it calls div()?
- or foo() because it is the function, that returns the invalid value, that
is used later? But 0 is maybe a valid return value for foo()?
- or div(bar(foo()));, but how to find out, that foo() _really_ returned
the invalid value?
Like in my other example you can report any file and line you want and
which is maybe/probably involved, but in most if not all cases it doesn't
prevent you from debugging.
Regards,
Sebastian
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Re: Importing namespaced functions
Hi, Are you going to cover autoloading of functions too? Regards, Sebastian 2013/5/2 Igor Wiedler i...@wiedler.ch Hi internals, Since there's been no major objection to this proposed RFC, I will go ahead and create it on the wiki. I will amend it to address some of the points that were discussed so far. Thanks, Igor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Re: Importing namespaced functions
2013/5/2 Igor Wiedler i...@wiedler.ch
No, I want to keep autoloading out of this proposal. It is way beyond the
scope of the namespacing issue and also incredibly complex.
That said, this RFC may be useful for implementing autoloading in the
future, as it addresses one of the things that makes function autoloading
hard, which is being able to distinguish between namespaced and global
function calls. But that's only one piece of the puzzle.
Well, it is not as complex as it sounds
This is the behaviour right now
- Does X exists as namespaced function (current namespace or imported)?
- Does X exists as global (builtin) function?
- Trigger error
The behaviour including autoloading would be more like
- Does X exists as namespaced function (current namespace or imported)?
- Does X exists as global (builtin) function?
- Trigger autoload
- Does X exists as namespaced function (current namespace or imported) now?
- Maybe: Does X exists as global function now?
- Trigger error
The autoloading itself could use parts already used for class-autoloading.
// Signature
// spl_autoload_register($callback[, $type = AUTOLOAD_CLASS]);
$autoload = function ($name, $type = AUTOLOAD_CLASS) {
// Do something
};
spl_autoload_register($autoload, AUTOLOAD_CLASS | AUTOLOAD_FUNCTION |
AUTOLOAD_CONSTANT); // constant here just to make it complete
Namespaced functions without autoloading seems kindof incomplete,
especially because it isn't such a big deal to simply use the prefixed one,
so the benefit seems quite small to me :X
use MyFoo\Bar\MathFunctions as math;
$x = math\sin($y);
Just saying :)
Regards,
Sebastian
On May 2, 2013, at 11:40 PM, Sebastian Krebs krebs@gmail.com wrote:
Hi,
Are you going to cover autoloading of functions too?
Regards,
Sebastian
--
github.com/KingCrunch
Re: [PHP-DEV] property de-referencing
2013/5/1 Rasmus Schultz ras...@mindplay.dk
Any PHP dev who works with a mainstream framework does this daily, but the
frameworks rely on strings for property-names.
Take this example from the Symfony manual, for example:
class Task
{
protected $task;
protected $dueDate;
public function getTask()
{
return $this-task;
}
public function setTask($task)
{
$this-task = $task;
}
public function getDueDate()
{
return $this-dueDate;
}
public function setDueDate(\DateTime $dueDate = null)
{
$this-dueDate = $dueDate;
}
}
$form = $this-createFormBuilder($task)
-add('task', 'text')
-add('dueDate', 'date')
-getForm();
In this example, 'task' and 'dueDate' are property-references - except of
course that, no, they're not - they're obviously just strings... rewriting
this example to use a (fictive) form builder API with static
property-references:
$form = $this-createFormBuilder()
-add(^$task-task, 'text')
-add(^$task-dueDate, 'date')
-getForm();
One problem I have with this example is, that you usually (or at least
often) don't have a $task object here.
We now have static property-references, which means the codebase can be
proofed using static analysis, which also means better IDE support with
property auto-completion, inline documentation, and automatic refactoring
for operations like renaming properties, etc.
Note that $task need not be passed to createFormBuilder() anymore -
instead, we can now use PropertyReference::getObject() inside the
form-builder to obtain the instance.
For that matter, we can now scrap the form-builder entirely and introduce a
simple form-helper in the view instead:
Task name: ?= $form-textInput(^$task-task) ?
Due Date: ?= $form-dateInput(^$task-dueDate) ?
This is even better, because we now have the same level of IDE support and
static analysis for textInput() and dateInput() which were previously
unchecked strings.
Or even simpler:
Task name: ?= $form-input(^$task-task) ?
Due Date: ?= $form-input(^$task-dueDate) ?
Using PropertyReference::getObject() and reflection inside the
form-helper's input() method, we can now use property-annotations to
specify the input-type. This is a matter of preference of course, but use
of annotations in Symfony is pretty popular.
This is just one example - most PHP devs (at least those who do PHP for a
living) use form abstractions and object/relational-mappers of some sort,
so this has practical applications for practically everyone, everywhere.
Rasmus Lerdorf wrote:
It is certainly not worth overloading the XOR operator for
Are we really going to quibble about syntax? This adds nothing to this
discussion. And as I explained earlier, the ^ operator is used for the sake
of discussion only - if it's more practical to use another character for
this operator, I don't care what it looks like.
On Tue, Apr 30, 2013 at 4:58 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I'm proposing we need a way to statically reference an object property
-
the object property itself, not it's value:
You probably have use case for that, and it should be pretty easy to
write a class that does that, but why it should be in the language? It
certainly doesn't look like something sizeable portion of PHP devs would
do frequently.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
github.com/KingCrunch
Re: [PHP-DEV] Could we kill call_user_func?
2013/3/15 Steve Clay st...@mrclay.org I'm sure this question has been discussed before, so if anyone can point to me to links or briefly recap I'd appreciate it. Why can't we make $someCallable() always work? E.g. http://3v4l.org/FLpAq I understand the problem of $obj-foo() where -foo is a callable property. The workaround could be: ($obj-foo)(); call_user_func() just seems so ugly now that we have nicer syntax in so many other areas. You don't need to use it, if you don't like it. Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Allow all callables to be called directly
2013/3/15 Steve Clay st...@mrclay.org My subject was misleading. I didn't mean to suggest call_user_func() be removed, just be made unnecessary by direct call syntax. This should make the inconsistency clearer: http://3v4l.org/L8Yvq On 3/15/13 10:21 AM, Sebastian Krebs wrote: You don't need to use it, if you don't like it. I do need to use in case my $callable is an object callback. Well, I would agree, if it is wouldn't be already possible :) You simply defined your static method wrong http://3v4l.org/IrPTn I am unsure, if it useful to support Foo::bar too, because it doesn't give any further benefit compared to [Foo,bar] Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Could we kill call_user_func?
2013/3/15 Stas Malyshev smalys...@sugarcrm.com Hi! why not enable then this getCallback()();? There's an RFC for that: https://wiki.php.net/rfc/fcallfcall but it has some edge cases which I didn't have time to figure out yet. In the long run I think it would be great :) Earlier I also realized, that [MyClass::class, 'methodName'](); doesn't work either. Regards, Sebastian -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
2013/3/7 Stas Malyshev smalys...@sugarcrm.com Hi! RFC updated. Any other comments about this RFC? Could you provide a use case for this - which practical value this has? It also still contains factually incorrect claim that unset() is a function and that there's some inconsistency in the fact that it does not return value. Also, it is not clear what false returned from unset() actually means - did it fail to unset the value (i.e., it is still set) Shouldn't this fail a little bit more obvious (- loud)? And how is this even possible? or there was nothing to unset (i.e., it is still not set)? So I guess this is the only useful behaviour. However, I have no idea, what this information should tell me. If I call unset() then I want to ensure, that the variable is not set anymore, but for what reason I should need to know, whether it was set before, or not? Regards, Sebastian -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Memory warning hook
2013/3/5 Lazare Inepologlou linep...@gmail.com 2013/3/5 Tom Boutell t...@punkave.com Can't you do this already? memory_limit can be fetched via ini_read, and together with memory_get_usage you should be able to check for this sort of thing. Admittedly having to parse memory_limit (which can be in various units) is not perfect. 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. You can use ticks :) http://php.net/control-structures.declare#control-structures.declare.ticks 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. Well, maybe I don't understand, what you are trying to tell, but if you run out of memory, this of course only affects one server on its own. On Tue, Mar 5, 2013 at 1:23 PM, nat...@starin.biz wrote: 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Lazare INEPOLOGLOU Ingénieur Logiciel -- github.com/KingCrunch
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
2013/2/28 Jens Riisom Schultz ibmu...@me.com
Hi everyone,
(I got hooked off this discussion, so I have tried to keep up by reading
the digest... This makes it impossible for me to correctly interleave my
comments, so I'll just top post or whatever the term is) (I'm sure this
has been mentioned before but a forum would be so much more accesible than
this mailing list concept...)
* In response to the argument that you want to be able to modify a
framework or use it in an unintended manner:
This would be possible by explicitly stating namespace Framework; in a
given php file.
* In response to the argument that php has no assembly concept:
I know this, but namespaces are as close as we get, and would effectively
solve this.
No. A namespace is in fact more or less just a prefix, that groups the
containing elements together. Beside the semantic meaning of grouping they
don't have any further abilities, or meaning.
Without knowing exact details I guess, that internal in C# is primary a
technical thing, that allows a compiler further optimizations, because he
definitely knows, that the function/method is only used within the assembly
and is not required to do anything to expose it to the outside?
* In response to the argument that php already has accessibility
restrictions with private and protected:
This is true, but it does not solve all problems. Often you need classes
to interoperate in a way that can only be facilitated by making
functionality public. Also, there is no way to make a private or protected
class (since php has no assembly concept), though what I propose would
likely birth the concept of private and protected classes as well.
Maybe it's just me, but no: I've never had the need of what you describe
and where a public method wasn't apropriate anway... At least for a very
long time :D
* In response to the argument that PHP does not restrict anyone from
adding to a namespace:
That is true, but say you were using Doctrine2. Would you ever make a php
file with namespace Doctrine2; in it, unless you wanted to modify
Doctrine2, and hence you knew what you were doing, or accepted the risks?
Well, yes. But extending/overriding a components method _always_ requires,
that you know what you do, so why enforcing/encouraging hacks, instead of
the good old protected?
* In response to the concept of solving this through documentation:
First off, this is not possible with the current phpdoc and phpdoc2
standards. Second off, problems like these should not be solved by
documentation, imho, or of course I would not propose this. The C#
designers seem to agree with me. And the Java designers, too (though they
have no internal keyword they do have a way of hiding framework specific
classes).
Information hiding is one of the staples of good OOP, and the internal
keyword would facilitate further information hiding in a way which is
extremely hard to do as php is now.
I would like to finish off with an example - I can tell there is a huge
resistance to this but I do not agree with your arguments, so I'll give it
another shot.
?php
namespace Framework;
class PublicAPIClass {
public function doStuff() {
$instance = new InternalClass();
return $instance-doInternalStuff();
}
internal public static function internalStuffHelper() {}
}
internal class InternalClass {
public function doInternalStuff() {
return PublicAPIClass::internalStuffHelper();
}
}
This doesn't explain, why the InternalClass should be hidden? Additional
the new in doStuff() and the cyclic calls let me believe, that you'll
have a tight coupling-problem anyway.
abstract class APIAbstract {
protected function doInternalStuff() {
return PublicAPIClass::internalStuffHelper();
}
protected static function internalStuffHelper();
}
namespace NotTheFramework;
$instance = new \Framework\PublicAPIClass();
$instance-doStuff();
// You would not be able to do the following things:
use Framework\InternalClass;
$instance = new \Framework\InternalClass();
\FrameWork\PublicAPIClass::internalStuffHelper();
And the question remains: Why _should_ I not be able to do this? If it is
that specific to the PublicAPIClass maybe it should be an abstract parent
instead? Or a trait?
If it is _not_ that specific to PublicAPIClass ... well, ehm, this can't
be, because it calls internalStuffHelper(), thus it is bound to the class
in any case. :)
?
Please read my example carefully, before simply writing it off.
...And a question: Am I wrong when I assume that this should be
relatively easy to implement?
-Jens Riisom Schultz
On Feb 27, 2013, at 10:11 AM, Lazare Inepologlou linep...@gmail.com
wrote:
Hello,
2013/2/27 Jens Riisom Schultz ibmu...@me.com
Hi,
I just want to get a feel for whether the following idea would be
instantly rejected
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
2013/2/27 Jens Riisom Schultz ibmu...@me.com
Hi,
I just want to get a feel for whether the following idea would be
instantly rejected (for example I get the feeling that adding keywords is a
big deal):
Often, when writing frameworks, you need to make public or protected
functionality or classes which should only be called from inside the
framework. You CAN ensure this with a lot of ninja tricks and
debug_backtrace, but it is very cumbersome and often hides your methods and
properties from class signatures.
Just my 2 cent, but whats about just trust other developers, that when they
call a method/function marked with @internal they know, what they are doing?
Therefore I would propose adding a C# style internal keyword. (
http://msdn.microsoft.com/en-us/library/7c5ka91b(v=vs.80).aspx )
The idea is, simply, that functions, methods and classes marked as
internal would only be accessible from within the namespace in which they
are defined.
I don't think it makes sense for methods as public/protected/private is
enough. For know I don't see reasonable use-cases for an additional
visibility-modifier for public as long as in the same namespace, or
namespace-protected for methods. But maybe it's interesting to extend
public/private/protected to classes and functions like
protected function anInternalFunction() { /* Restricted to this and
subnamespaces */ }
private class { /* Restricted to this namespace */ }
Worth the mention, that I rarely miss something like this, but at least I
can imagine some use-cases.
For example the following class, namespace Framework; internal class
Something {}, would only be visible from within the Framework namespace.
I have a hunch that this would be relatively easy to implement.
If noone objects I would attempt to create a patch and an RFC.
What do you think?
-Jens Riisom Schultz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Add get_object_constants and get_class_constants
2013/2/27 Frank Schenk frank.sch...@2e-systems.com
Hi Crypto Compress,
big congratz to that name, your mummy Hash Compress and your daddy Image
Compress must be very proud!
SCNR
Am 02/27/2013 03:54 PM, schrieb Crypto Compress:
Hello Mike,
thank you! It is a useful feature to me.
class MyBitmask {
const POS_1 = 1;
//const POS_2 = 2;// reserved/undefined
//const POS_3 = 3;// reserved/undefined
const POS_4 = 4;
I'm developing software with PHP since version 2 and i'm still easily
impressed by such code. So we need get_object_constants and
get_class_constants for such fancy stuff?
Where's the good old
$flag == true; or FLAG == true;?
A bitmask class to shuffle around with class constants using reflection
of itself and a magic method get_class_constants to check a boolean flag?
I just don't get it but maybe i'm to focused to doing things the most
simple and readable/maintainable way.
Maybe, in a few years, c++ will be a beginners language compared to PHP
which gets added new shiny features every day which will only be used by
even more shiny frameworks and the most shiniest, bloated objects one
can imagine.
I don't see this one in a framework. Just said :)
With every fancy feature added to PHP you kill a kitten!
I'm more with this Give PHP and it's core developers a rest so that
the core can be improved/cleaned up instead of adding Java features
people have seen on the university and like them but now they're forced
to use PHP which is like the opposite of Java. Java has it's good
reasons too. Just a tool. Use the tool that fits best, don't use the
hammer as a saw by adding teeth to it.
Cheers,
Frank
--
Frank Schenk
Software Analyst
2e Systems
Tel: +49 - 6196 - 95058 - 30
Fax: +49 - 6196 - 95058 - 94
E-mail: frank.sch...@2e-systems.com
Address: 2e Systems GmbH, Königsteiner Str. 87, D-65812 Bad Soden am Taunus
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Director: Philip Douglas
http://www.2e-systems.com/ - making your business fly!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
2013/2/27 Steve Clay st...@mrclay.org On 2/27/13 3:18 AM, Nikita Nefedov wrote: I, for one, think it should be solved on the IDE side. I used a lot of Doctrine's internal methods lately and if they would be not accessible I wouldn't be able to do a lot of things. Of course internal methods/classes shouldn't be exposed as a part of API, but if they exist, I would want to call them *if I know what I'm doing*. I think it would be useful if phpdoc had an @internal tag so that IDEs could highlight places where you use internal parts of library. Agreed, IDE/phpDoc is the place for a solution (and I do recognize that there is some need here). phpDoc already supports @access private for items to be left out of public documentation. An IDE could be configured to have these items appear greyed or not to appear in autocomplete lists. a) You misuse the private visibility here: @access private comes from old PHP4-days, where the DocComment must know the visibility, because the method itself didn't b) Most doc-tools are able to generate developer-docs, which usually contain all protected and private elements. This hidden element will appear as regular private method there. Can be confusing I think :) There's already a way to tightly control access: embrace OOP and eliminate statically accessible APIs (global vars/funcs and static props/methods) that you don't want people calling. You don't actually need them. Although closures helped too, PHP gained true information hiding in 5.0 with private. I agree Steve Clay -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Allow (...)-foo() expressions not only for `new`
2013/2/26 Lazare Inepologlou linep...@gmail.com
Hello Nikita,
2013/2/25 Nikita Popov nikita@gmail.com
Hi internals!
PHP 5.4 added support for expressions of the kind (new Foo)-bar(), (new
Foo)-bar and (new Foo)['bar'].
I guess it must have been discussed, but Is there any technical reason or
conflict that prevents us from having something like new Foo-bar(),
without the extra parenthesis?
It could mean new (Foo-bar()), which in this case is invalid, but there
are other cases, where this problem is more obvious
if ($foo) {
$bar = 'Classname';
} else {
$bar = new BarClass;
}
new $bar-baz(); // (new $bar)-baz() or new ($bar-baz())?
I'd like to extend this support to any expression instead of just new.
Why should be do this? Because it's just an arbitrary restriction.
Removing
it would for example allow clone calls in the parens, so you could do
something like (clone $date)-modify('...'). Which - you may have already
noticed this - is more or less a replacement for the DateTimeImmutable
class that was added for 5.5 (with the nice benefit of being fully
compatible and not being an object oriented abomination :) That's just
one
example, but I think there are a lot more (especially if you also
consider
that it allows array dereferencing too). One further use that is of
interest to me personally is for https://github.com/nikic/scalar_objects
,
so I can do calls like (foo)-bar().
A nice side benefit from this is that it removes a shift/reduce conflict
from the parser.
The patch for the change can be found here:
https://github.com/php/php-src/pull/291/files. It's a very simple patch,
it
basically just changes one parser rule and adjusts the allowed opp types
for some opcodes. The rest is just the vm regeneration for the new op
types.
I hope that this change is trivial enough to not require dragging it
through the whole RFC process. If there are no objections I'd commit it
sometime soon.
Thoughts?
Nikita
Lazare INEPOLOGLOU
Ingénieur Logiciel
--
github.com/KingCrunch
Re: [PHP-DEV] Late FQCN resolution using ::class
2013/2/25 Jens Riisom Schultz ibmu...@me.com
Hi everybody,
I have read up on this, and done some testing.
First up, my findings with PHP5.5 alpha5:
?php
namespace spacy;
class classy {
public static function fqcn() {
/* This works but is not useful enough: */
//return self::class;
$me = 'classy';
/* This just doesn't work, but I wish it did: */
//return $me::class;
/* This simply does not work as expected: */
return eval(return $me::class;);
/* Output: classy - Expected output: spacy\classy */
}
}
?
Without testing anything: My first idea would be 'static::class'. Did you
tried this?
I'm trying to late resolve a class name contained in a variable to the
FQCN. I understand that this is hard (maybe even impossible) with the
current implementation, because class name resolution happens compile time,
but eval(return $me::class;) simply returns something that is weird.
I guess what I'm trying to ask is whether it would be impossible to
support late FQCN resolution in any way? It would be very useful for
frameworks to be able to do this.
- Jens Riisom Schultz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC Autoboxing Draft
2013/2/25 Nils Andre nilsan...@gmail.com
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.
== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.
== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.
Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.
== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)
By _adding autoboxing_ for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.
== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).
== Syntax ==
The mapping is very straigtforward. Consider this:
$a = This is a string;
$b = $a-toUpperCase()-- $b = ucase($a)
$b = $a-substring(0,4) -- $b = substr($a, 0, 4)
It would also allow many brilliant constructs like the following
if ($b-startsWith(This)) { ... }
in contrast to
if (substr($b,0,4) == This) { ... }
Must say, that for now I didn't read your mail completely, but this example
is .. it doesn't fit. The problem is, that you compare two different
semantics.
function startsWith($string, $startsWith) {
return !strncmp($string, $startsWith, strlen($startsWith));
}
$b-startsWith('This');
startsWith($b, 'This');
Now they aren't that different anymore.
Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.
No: strlen($string)
== Compatibility ==
The old notation could be switched on/off at any time.
The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some use
\PHP5\*; or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
old/compatibility stuff.
== Advantages ==
- Cleanup of the language
- Consistency and predictability improved a lot (also in constrast to
possible userland classes - which would then all be slightly different)
- No lacking backwards compatibility
- Easier learning for new PHP programmers (beginners to PHP would be much
more pointed to learning OOP than procedural programming)
- Easier switching for programmers from Java to using PHP and vice versa
(now that PHP grew very mature, attract the Java folks with the cool stuff
PHP offers)
- Little overhead (as far as I am aware) to implement
- Nicer language syntax (see References)
== Disadvantages ==
- I don't know how complicated it is to implement. So far we don't have any
extensions for this on PECL, except for strong typing (see reference). From
a theoretical point of view, it is just mapping.
- There might be heaps of ways to implement, as the other autoboxing RFC
offers one possiblity. Certainly we need discussion on the best way to
implement.
Re: [PHP-DEV] rfc:trailing-comma-function-args
2013/2/22 Rasmus Schultz ras...@mindplay.dk
I've been thinking about this RCF for a while now:
https://wiki.php.net/rfc/trailing-comma-function-args
It just doesn't seem necessary - the only time I've ever found something
like this to be necessary, is when a function takes closures or other very
long arguments, some of which are optional...
I must say, that I find this RFC completely useless. In my opinion when one
has such a long parameter list (or too long variable names),
that he must break the call onto several lines, the additional line in the
vcs' diff is the minor problem.
but actually, writing this in
a VCS-friendly way is already possible:
$tree-traverse(
$tree
,
function($node) {
// ...
}
);
... version 2 ...
$tree-traverse(
$tree
,
function($node) {
// ...
}
,
function($node) {
// ...
}
);
This actually comes out more legible, in my opinion.
What really irks me about this patch, is that the trailing comma implies
that another optional argument may exist - it really doesn't make the code
more intuitive to read. The example on the page (using fopen) really isn't
a realistic use-case - who would break a couple of simple arguments into
individual lines like that?
/sign
Especially about the implies, that another optional argument may exist:
One does not simply add arbitrary arguments to a function call. Except when
the function signature changes, but in this case (to repeat myself) the
additional diff-line is negligible.
Just my two cents...
My too
- Rasmus
--
github.com/KingCrunch
Re: [PHP-DEV] Pull request for array_filter() improvement
2013/2/21 Tjerk Anne Meesters datib...@php.net
Hi,
I found myself wanting a feature of array_filter() with which I can perform
filtering based on the array key instead of the value.
To scratch this itch, I decided to dive into C again and just add the
feature. My proposal is to add a third argument to array_filter() that will
send the array keys to the callback.
Hi,
Why not simply _always_ push the key to the callback?
Regards,
Sebastian
function myfilter($value, $key)
{
return $key 4;
}
array_filter([1, 2, 3, 4, 5, 6, 7], 'myfilter', true);
// returns: [6, 7]
The pull request can be found here:
https://github.com/php/php-src/pull/287
If this is useful for the language as a whole, do let me know what else I
should do to champion it.
Thanks!
--
--
Tjerk
--
github.com/KingCrunch
Re: [PHP-DEV] PHP 6 : a new API ?
2013/2/20 Klaus Ufo klaus...@yahoo.fr Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions Just to throw that in: Even if you pack them into namespaces they will still remain global functions. They simply don't live in the root-namespace anymore. - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] File system watcher/monitoring
2013/2/15 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net On 15/02/13 14:20, Sebastian Krebs wrote: 2013/2/15 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net** Hi Stas, On 14/02/13 22:37, Stas Malyshev wrote: Hi! A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. I think it'd be great to have a library with unified interface and an extension that uses it. However, I'm not sure if these libraries are useful in common php use case - short-lived requests. Could I get the changes since the last request? Or is it useful only for long-running persistent processes? It is only useful for long-running processes. For example when you are writting tests: at each modifications, you would like to re-run or re-generate tests. In this case, you have a daemon that watches files changes and executes a command when needed. Why do you need PHP for this? http://stackoverflow.com/**questions/3283228/bash-** execute-script-on-file-save#**answer-3283390http://stackoverflow.com/questions/3283228/bash-execute-script-on-file-save#answer-3283390 I don't understand your point. For the use-case you described here a PHP-implementation is not required, because you can use the system-tools to invoke PHPUnit. In fact you don't need a daemon at all ;) -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] File system watcher/monitoring
2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net Hello Julien, On 14/02/13 15:29, Julien Pauli wrote: On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Well ok, forget PHP core, but an extension would be great. At least for inotify there is an extension, which works quite fine. Never searched something similar for other OSs. Regards, Sebastian -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] RFC mysqlnd.localhost_override
2013/2/12 Asbjørn Sannes asbjorn.san...@interhost.no https://wiki.php.net/rfc/**mysqlnd_localhost_overridehttps://wiki.php.net/rfc/mysqlnd_localhost_override I propose we introduce a new option called mysqlnd.localhost_override which enables a system administrator or php distributor to configure how localhost should be overridden. I believe it would make life easier on system administrators and distributions with varying defaults. Working patch at: https://github.com/php/php-**src/pull/275https://github.com/php/php-src/pull/275 It is backward compatible by falling back to earlier behaviour if mysqlnd.localhost_override is not set Any comments welcome. Hi, On the one side it seems, that PDO already support DSN-alias [1], that covers your use-case. On the other side I don't think it is useful to redefine a hostname (and 'localhost' is nothing else than a hostname), especially because it is only in this context, but in other contexts 'localhost' remains the same. localhost is localhost and everything else only leads to confusion. Regards, Sebastian [1] php.net/pdo.configuration#ini.pdo.dsn -- Vennlig hilsen for Interhost AS Asbjørn Sannes konsulent www.interhost.no m...@interhost.no +47 21 42 01 12 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
2013/2/3 Sebastian Bergmann sebast...@php.net
Am 03.02.2013 18:07, schrieb Sebastian Bergmann:
Can you explain why you are using eval() instead of a real anonymous
function? Thanks!
Please ignore my email; I mixed up create_function() and eval(). Then
again, your code still does not make sense to me ...
Don't know, how create_function() works internally, but it seems, that they
at least act quite similar
?php
create_function('','}echo Foo;{'); // Foo
http://codepad.viper-7.com/h6NQfO
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you need
to define an id for it?
Bu whats about
file_put_contents('php://memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect, that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Regards,
Sebastian
Best regards
Chris Wright
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)
2013/1/31 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
On 31/01/13 12:00, Sebastian Krebs wrote:
2013/1/31 Chris Wright chr...@aquacool.ltd.uk
I propose the following syntax:
php://memory/id
php://temp/id/maxmemory:**size
I would very much like to see this as well.
Would this also allow you to open multiple pointers to the same bucket?
For example would this work?
?php
$fp = fopen('php://memory/foo', 'w+');
file_put_contents('php://**memory/foo', 'data');
rewind($fp); // would this be necessary?
echo stream_get_contents($fp); // outputs 'data'
Everything else wouldn't make much sense, because why else should you need
to define an id for it?
Bu whats about
file_put_contents('php://**memory/foo', 'data');
$fp = fopen('php://memory/foo', 'w+');
'file_put_contents()' closes the stream after writing. I would expect,
that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Yup, I also expect the engine to clean memory when closing php://memory or
php://temp, but this is another proposal I think, no?
Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Is this question for me or Chris?
A question for everone :)
If it is for me, I don't want multiple accesses to the same
“bucket”/space, I want multiple “buckets”/spaces.
So now I am confused: As far as I can see you can open as many memory- or
temp-streams as you like.
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
2013/1/25 Thomas Bley thbley+...@gmail.com One thing I can guarantee is that if we add it to core in its current condition it will delay 5.5 by 6+ months if not longer. I think it is fine if APC doesn't support all features of PHP. When there is a clear documentation, everybody can decide if he skips some features for better performance. Maybe this also offers room for more optimizations. You cannot simply decide, what features you want to use, when you rely on third-party-libraries from time to time. Regards, Thomas On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 01/24/2013 11:56 PM, Ralf Lang wrote: From what I understood from Rasmus the biggest challenge with merging APC into core is the fact that the compiler currently isn't built to support opcode caching. One of the challenges he pointed out was some of the MAKE_NOP trickery that can make APC's work a bit more complex than necessary. It's possible to optimize the compiler enough to the point that APC's code could be reduced down to very simple opcode caching, putting less stress on the engine and making it easier to maintain. I think there was some support for moving APC first from pecl to the PHP standard distribution's ext folder before any tighter integration is started. I'm really not convinced that by moving it to core we will magically get people to help with it. I have been trying to get people interested for years, and it hasn't gotten very far. Everyone wants it in the core, but with a couple of exceptions, nobody is willing to actually work on it to get it there. And I can understand the lack of help. It is probably the most complicated piece of the entire stack. It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded. It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way. So the learning curve is steep and the bugs are extremely hard to track down because it is the only PHP component that isn't a perfect sandbox. A slight memory corruption almost anywhere in any extension can segfault a dozen requests later with a backtrace that points to the opcode cache code. Not to mention web servers like Apache that longjmp() on us at the wrong time. Zend-signals addresses this, but even in 5.4 they aren't enabled by default because of stability issues and without those no shared memory opcode cache is safe. I firmly believe that we need opcode caching in core. I'm rather skeptical that simply moving pecl/apc to ext/apc is going to help users in any way. People have no trouble finding and installing APC today. The real issue here is robustness and lag time between a PHP release and and solid APC release and that has to do with resources which are scarce due to the code complexity. This is the real problem we need to solve. Either by a number of people stepping up to help with the existing APC code, or perhaps more realistically making it a priority in PHP 5.6 to streamline the engine and the executor for opcode caching and either including a heavily simplified version of APC or writing a new one. One thing I can guarantee is that if we add it to core in its current condition it will delay 5.5 by 6+ months if not longer. -Rasmus -- 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 -- github.com/KingCrunch
Re: [PHP-DEV] I think that Function naming inconsistency bug deservers more attention
2013/1/25 Pierre Joye pierre@gmail.com hi, On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis martin.kecke...@gmail.com wrote: Hello, you are right Damian. Also today on a german page: http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html Relating to this bug report: https://bugs.php.net/bug.php?id=52424 We all know that, since years. The answer however remains the same: We can't do it without major backward compatibility breakages. Please check the internals archive for the past discussions. Theoretically you can have both: The API in it's current state as well as a consistent api in the php-namespace. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
2013/1/22 Lester Caine les...@lsces.co.uk Clint Priest wrote: There seems to be a lot of userland support for this proposal from people who don't have voting rights. And what about the userland people who don't want the additional complexity who don't have voting rights? Don't use it. Regarding your other mails you are stuck with 5.2 anyway ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] FW: Functionality request/proposal
2013/1/14 Johannes Schlüter johan...@schlueters.de
On Mon, 2013-01-14 at 04:10 +, Paulo Henrique Torrens wrote:
Hi,
I'm currently interested in two features I'd like to see in PHP; how do
I proceed to request/propose them? I'd be glad to help implementing them as
well, if necessary.
One of them is really simple, but would be helpful to people with
different coding styles
class Test {
public function blabla() {
// ...
} // the interpreter fails if there
// is a semicolon here, although
// some c++ programmers may be used
// to add it
That one is wrong in C++, too. Unless you're confusing function
declarition with function definitions.
class CPPClass {
void some_declaration();
void some_definition_of_an_inline_function() {
return;
} // No ; here
}
};
Well, people should be aware of the language they are using ...
And the other one would be multiple return values
function multi() {
return 10, 20;
Use
return [10, 20];
which exists and returns an array. This is clear and quite easy to read.
};
function sum($a, $b) {
return $a + $b;
};
echo sum(multi()); // echoes 30
This becomes confusing when reading.
echo array_sum(multi()); // :)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] [Reflection] Improve logic of ReflectionMethod-invokeArgs() for static methods
2013/1/14 Alexander Lissachenko lisachenko...@gmail.com
My use-case is weaving aspects into the methods. Yeah! )
So, I take the original class, rename it and then create a decorator
class instead of original class with overridden dynamic and static
methods. Method in the decorator should make some specific logic and
then just invokes the original static method with Reflection, but the
scope should be also correct.
For example, previous class First will be renamed during load-time to
the First_AopProxied:
class First_AopProxied
{
public static function foo()
{
echo get_called_class();
}
}
and decorator will be created
class First extends First_AopProxied
{
public static function foo()
{
// some logic here, that should call parent method and
preserve the scope (class First)
// can not use parent::foo() here, because around advice
should be able to call this method somewhere in the closure...
}
}
I must say this example is not really better than the last one (it feels
like it is exactly the same with 2 lines more comments). Also I don't know,
what you mean by call this method somewhere in the closure; which
closure?!?
I guess you are in fact looking for regular instance methods.
2013/1/14 Sebastian Krebs krebs@gmail.com:
2013/1/14 Alexander Lissachenko lisachenko...@gmail.com
Hi! It's my first letter here )
I want to suggest a small improvement for ReflectionMethod-invoke()
and ReflectionMethod-invokeArgs() methods to support LSB for
overridden static methods. Currently, for invoking static methods
first argument should be null, information about class (scope) is
taken from the reflection class. However, there is one issue that can
not be solved at the current time.
Suppose, we have two classes:
class First
{
public static function foo()
{
echo get_called_class();
}
}
class Second extends First
{
public static function foo()
{
echo Do not call me, please;
}
}
Now I want to invoke the First::foo() method with Reflection from the
Second class scope for using LSB. Currently this is impossible:
$class = new ReflectionClass('First');
$class-getMethod('foo')-invokeArgs(null, array()); // Outputs
'First' as no scope information is passed
$class = new ReflectionClass('Second');
$class-getMethod('foo')-invokeArgs(null, array()); // Outputs 'Do
not call me, please' as method is redefined
So, there is no way now to invoke the static First::foo() method from
the child scope because it was redefined. However, this can be easily
implemented by adding the scope for static methods invocation (like
Closure::bindTo()):
$class = new ReflectionClass('First');
$class-getMethod('foo')-invokeArgs('Second', array()); // Outputs
'Second'
This improvement can be very useful for building proxies for static
methods, that use LSB. Can it be implemented for PHP 5.3-5.5? Thanks!
Maybe it's just me, but could you explain which use-case want to solve?
The
example isn't very useful, because you can achieve this quite easy
without
reflection. Also why do you override the method, when you don't want it
to
get called? Shouldn't they two separate methods then?
?php
class First
{
public static function foo()
{
echo get_called_class();
}
}
class Second extends First
{
public static function foo()
{
echo Do not call me, please;
}
public static function bar() {
parent::foo();
}
}
Second::bar();
http://codepad.viper-7.com/fwG5GB
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Reflection annotations reader
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com wrote: I think that our work is to isolate each annotation so it'll be easy to access, then, it'll be easy enough to write the code that creates complex annotations, such as constructors and so on, in userland. In fact, there's probably no need (now) to go on and build a full annotation reader that instantiates classes and does fancy stuff as we currently do in doctrine/common. A fast parser is more than enough I suppose. That's our bottleneck (besides scanning files). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ So the problem is the syntax which is difference? When wrote this RFC, I just though about basic cases... Though I agree with you that the main problem is the syntax. We can extract the entire doc-comment and only isolate between annotations, so doc-comment like: /** * @Route(/) * @ORM(Key=foo) * @var string */ Will be : array( 'Route(/)' = , 'ORM(Key=foo)' = , var = string ) But the question is it really worth it, since you'll probably need to create some sort of sub-parser that uses this isolated annotations array and apply on them your syntax. As a suggestion, that should cover most (all?) cases: The identifier could be defined as between @ and the first non-alphanumeric character (it should probably allow some special like /, or \ to allow namespace-like annotations). @Route(/) would be array( 'Route' = '(/)'. Now a secondary parser only needs to take care about (/), but for example it can already directly test, whether or not the annotation exists. That's being said, if we'll see performance improvements, I really think that it's a good solution to start with, since because its not an Attributes, I don't think that we should dictate the syntax for each application. Each application will get the doc-comment annotation and will be able to apply on it its own syntax and fancy stuff... I think that it's the best solution because of BC too. To throw that in: Multiline-annotations must be taken into account too :) Regards, Sebastian What do you think? -- github.com/KingCrunch
Re: [PHP-DEV] Improve DateTime Class
Hi,
are you mabe just looking for
$date-add(new DateInterval('P15D'));
?
2012/12/10 Christian Stoller stol...@leonex.de
Hi internals,
what do you think about improving the modification functionality of the
DateTime class. I always get a cold shiver, when I write something like
this:
?php
$date = new DateTime()
$date-modify(‘+15 day’);
In my opinion it would be nicer if one could write:
$date-modify(15, DateTime::INTERVAL_DAY); // for adding 15 days
$date-modify(-15, DateTime::INTERVAL_DAY); // for subtracting 15 days
Even better would be to have methods like addDays(), addMonths(), etc.
This would make it cleaner and more readable. You do not have to do
something like this:
$date = new DateTime();
$date-modify(getDaysToAddMethod() . day); // I am not sure if a '+'
sign is needed if the value is positive
And it is fully backward compatible.
Best regards
Christian
--
github.com/KingCrunch
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: “Now
- this is simply ignored”. Really? But the behavior is pretty
straightforward isn't? “modify to now” means “set to the current date and
time and let the timezone unchanged”.
It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
Other way round: You are looking for the set*()-methods :) Because you
want to _set_ a date, not modify one.
Regards,
Sebastian
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: ext/mysql deprecation
2012/11/20 Lester Caine les...@lsces.co.uk Pierre Joye wrote: https://www.google.de/search?**q=php+mysqli+tutorialhttps://www.google.de/search?q=php+mysqli+tutorial Which gives About 273,000 results and the first of them are causing more confusion with PDO alternative. BUT newcomers know nothing about mysqli and will be looking for https://www.google.de/search?**q=php+mysql+tutorialhttps://www.google.de/search?q=php+mysql+tutorial gives About 9,040,000 And https://www.google.de/search?q=standart gives you 128,000,000 results. You cannot avoid, that outdated, or wrong information remains. The bigger problem seems to be, that the google results are treated with more attention, then the official manual. Any idea against that? The most important think here is getting the word out and getting as I said - get the more popular tutorial sites 'converted' or at least pointing out that mysqlI is now what you have to look for. Who should be responsible for this task in your opinion? For example why didn't you contacted w3schools already? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Autoload Functions RFC in 5.5?
2012/11/11 Patrick E. zeno...@gmail.com Hi, use My\Math Math\sin(); very intuitive. And it would be a bit like Python Modules, where you import symbols (including global variables of the module) of modules: import math print math.sin(math.pi) Const autoload would also make sense, but results in different Coding styles (personality driven), Module Consts vs. Class Consts : use My\Math; Math\sin(Math\PI); // class constants: use My\Math; Math\sin(Math\M::PI); For something like PI I don't know, why it should be in a seperate class anyway (instead of a namespace-constant). However, I guess you would still import class directly anyway, what will look more like use My\Math as math; // Lowercase, to make it obvious, that this is NOT a class use My\Math\Constant; math\sin(Constant::PI); In my opinion current coding styles are not affected either, because right now I can't remember one, that covers the namespaced functions-topic. Everything else could (and should) stay the same as before. -- best regards, Patrick Engel -- github.com/KingCrunch
Re: [PHP-DEV] Autoload Functions RFC in 5.5?
2012/11/10 Laupretre François francois.laupre...@francetv.fr Given the strong opposition of core devs against this feature in the past, I want a vote on the RFC before I start working on a patch. Before this vote can take place, as you note, we need to solve the function fallback issue: in theory, we should call the autoloader before looking into the global namespace, but, in practice, most function calls reference PHP internal functions, and the performance hit would be too big. Forcing people to prepend a '\' to every function calls is also not possible. So, the only remaining solution, IMO, is to call the autoloader (first with NS suffix, then global) AFTER a global function lookup. In this case, we must accept that namespaced functions named the same as a global function may be incorrectly ignored in some cases. This only affects the situation, where a function is in the same namespace, where it is used, because else functions must get called with the namespace anyway use My\Foo; Foo\myFunction(); So in my opinion that behaviour is fine. It doesn't sound useful to name a function like a built-in ones anyway (this overwrite existing ones always seemed to be confusing in my eyes). François -Message d'origine- De : Benjamin Eberlei [mailto:kont...@beberlei.de] Envoyé : jeudi 8 novembre 2012 11:53 À : PHP Internals Objet : [PHP-DEV] Autoload Functions RFC in 5.5? There is this wonderful RFC sitting around: https://wiki.php.net/rfc/autofunc Is there any chance that we can integrate this in 5.5 and somebody is willing to write this patch? The only topic missing from the RFC is how the fallback to global namespace works, if the autoloader is called before or after the fallback. greetings, Benjamin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Object comparison
Hi, Maybe it goes way to far, but there is a PECL-extension [1], that allows to overload every(?) operator. However, it seems to be unmaintained for 6 years now and will probably not work anymore, but it may be usable as a starting point. Python provides this too [2] Regards, Sebastian [1] http://pecl.php.net/package/operator [2] http://docs.python.org/2/reference/datamodel.html#special-method-names 2012/11/9 Christian Stoller stol...@leonex.de 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. Best regards Christian Stoller -Original Message- From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara Golemon Sent: Friday, November 09, 2012 1:07 AM To: PHP internals Subject: [PHP-DEV] Object comparison From: http://php.net/manual/en/language.operators.comparison.php An object compared to anything which is not a bool, null, or object should result in the object appearing to be greater than the other operand. For example: $a = new stdClass(); $b = new stdClass(); var_dump(null $a); var_dump(false $a); var_dump(true == $a); var_dump($a == $b); var_dump(0 $a); var_dump(1 $a); // false var_dump(2 $a); // false var_dump(foo $a); var_dump(2 $a); var_dump(tmpfile() $a); Based on docs, I expect all nine of these to yield true, however in practice, the two marked false come out as false because the RHS object is converted to an integer (1), contrary to the docs. Doc bug? Or code bug? I'm inclined to call it a code bug, but wanted others' thoughts. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP
2012/11/8 Anthony Ferrara ircmax...@gmail.com Florin, On Thu, Nov 8, 2012 at 6:42 AM, Florin Razvan Patan florinpa...@gmail.comwrote: Hello, After a talk on the Symfony framework here: https://github.com/symfony/symfony/issues/5911 Long story short, the point that @Seldaek suggestion to have a common interface for loggers actually makes sense and the best way to have it would be to have PHP include it by default. I'm not sure exactly what amount of work this implies, nor my C skills are existent, but with PHP having such an interface available it would help standardize things in the PHP world. Also, I'm not sure if this could be backported into existing PHP 5.3 or PHP 5.4 versions but this would make sense to consider it for PHP 5.5. What do you guys think? Could this be considered to be included in PHP? Thank you for your time. Best regards, Florin Pedantically speaking, isn't this the exact goal of the FIG/PSR group? That they define these common parts? There are already discussing this (to be honest: For months now). Some are mentioned at the pull requests at https://github.com/php-fig/fig-standards/pulls Is there an advantage to having it in C (performance, etc)? If so, there may be something to discuss. But if it's just to enforce a common paradigm, I'd say leave that to the community to do. They are in a better position and can change their mind if they need to. Something that core is reasonably positioned to not do... Anthony -- github.com/KingCrunch
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Why isn't `spl_autoload` called for functions?
2012/11/7 Laupretre François francois.laupre...@francetv.fr
De : sebastian.krebs.ber...@gmail.com
I hope you find more support on this than I had. Technically
speaking,
it would be easy to extend autoloading to functions and constants. It
can even be done without BC breaks, combining 'old-style' and 'new-
style'
autoloaders without ambiguity (adding a second argument to the
autoload hook, and checking the number of args declared by the
function).
Thats not even required, if you fixate (-- default value) the second
parameter to class all existing loaders will behave, like they did
before.
Correct, but that's not enough to preserve BC.
OK, giving a default value of 'class' to the second arg allows using a
'new-style' autoloader with an 'old-style' PHP engine.
But, now consider the opposite, using a 'new-style' PHP engine, with
autoloading extended to functions and constants, with one or more
'old-style' autoloaders: when the engine needs to autoload a function or a
constant, we must not call any 'old-style' autoloader, as it would take the
symbol and attempt to load a class by that name. And the easiest way to
decide if an autoloader is a new or old-style one is to check if the
autoload handler func is declared with one or two args.
// signature
function spl_autoload_register($autoload, $type = SPL_AUTOLOAD_CLASS);
// Old style
spl_autoload_register(function($classname) {
// foobar
});
// new style
sply_autoload_register(function($name, $type) {
switch ($type) {
// Foobar
}
}, SPL_AUTOLOAD_CLASS | SPL_AUTOLOAD_FUNCTION | SPL_AUTOLOAD_CONSTANT);
Why is this not enough? Even if we pass the type as second argument to
the autoloader, nothing (in behaviour) will change. You are right, that we
must not call the first one, when it's not required, but also it _will_ not
get called, because it is not registered to get called for anything except
classes. Maybe I got you wrong?
If you want a more organized autoloader, create a class for it :)
class MyAutoloader {
public function __invoke ($name, $type) {
switch ($type) {
case SPL_AUTOLOAD_CLASS: return $this-loadClass($name); break;
case SPL_AUTOLOAD_FUNCTION: return $this-loadFunction($name); break;
case SPL_AUTOLOAD_CONSTANT: return $this-loadConstant($name); break;
default: return false; break;
}
}
// Here load*() functions
}
spl_autoloader_register(new MyAutoloader, SPL_AUTOLOAD_ALL);
Just my thoughts
François
--
github.com/KingCrunch
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Why isn't `spl_autoload` called for functions?
2012/11/6 Laupretre François francois.laupre...@francetv.fr I've asked this question for a while (one, or two years ago or so). Must say, that I didn't remember the answer, but I would like to see autoloading for namespace-constants and functions too :) I proposed extending the autoload mechanism to functions and constants several times since I released Automap. Automap ( http://automap.tekwire.net) is a map-based PHP autoloader. It includes a source scanner which analyzes source files and builds a map file from the symbols it finds. This process already registers functions and constants, as well as classes. So, it is ready to resolve functions and constants (and it was recently improved to support namespaces). After I released Automap (back in 2006 !), I had planned to finish the work, i.e. create new hooks in the PHP core to autoload undefined functions/constants. Unfortunately, when I proposed this on the list, the reaction was mostly negative and the proposal was rejected. IMO, it comes from a misconception about autoloaders, as most autoloaders are path-based, and such a mechanism imposes a restriction of one symbol per file, which makes it useless in practice for functions and constants. So, the idea of extending the autoload *features* was rejected because of current autoloader *implementations*. There may also be a global feeling among core devs that non-OO programming belongs to the past and shouldn't be encouraged... I have the same feeling and I don't really like it as this encourages to treat functions and (static) methods identically (but they aren't). I hope you find more support on this than I had. Technically speaking, it would be easy to extend autoloading to functions and constants. It can even be done without BC breaks, combining 'old-style' and 'new-style' autoloaders without ambiguity (adding a second argument to the autoload hook, and checking the number of args declared by the function). Thats not even required, if you fixate (-- default value) the second parameter to class all existing loaders will behave, like they did before. Ive found my old thread [1] and somewhere in there I suggested something like that as a possible solution [1] http://marc.info/?l=php-internalsm=131166835320805 A summary of the talk we had (6 years ago !) : http://devzone.zend.com/616/zend-weekly-summaries-issue-306/ Regards François -- github.com/KingCrunch
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Why isn't `spl_autoload` called for functions?
2012/11/5 Peter Cowburn sala...@php.net Pushing to internals list. On 5 November 2012 20:41, Levi Morrison morrison.l...@gmail.com wrote: I hear people complaining about this out in user-land all the time, but I've never seen anyone from internals respond. With practically everyone using an autoloader these days, it really borks your workflow to use `require_once` just to load a function. So why don't we call `spl_autoload` for undefined functions? Are there technical reasons, or has this not been discussed? IIRC correctly, one strong point for autoloading classes catching on was because of the existing one-class-per-file practice; folks were already having files named after a class and only containing said class. The same never really caught on for individual functions. Thats not really an argument, because once the autoloader find a undfined function, a custom loader is called anyway and this one can include a file with multiple functions (or classes, or constants, ...). (As a side note: The current autoloader could include files with multiple classes too ;)) I've asked this question for a while (one, or two years ago or so). Must say, that I didn't remember the answer, but I would like to see autoloading for namespace-constants and functions too :) Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Changing the default value of true for CURLOPT_SSL_VERIFYHOST
2012/10/25 crankypuss fullm...@newsguy.com On 10/24/2012 11:34 PM, Sherif Ramadan wrote: On Thu, Oct 25, 2012 at 1:03 AM, JJ ja...@php.net wrote: Hey all - I'd like start a discussion around pull request 221 (https://github.com/php/php-**src/pull/221https://github.com/php/php-src/pull/221 ). In short, there's a high volume of [incorrect] code out there which looks like: curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true); Instead of what, in all likelyhood, the code meant to do: curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); This is due to the convert_to_long_ex call which converts true to 1L. CURLOPT_SSL_VERIFYHOST being set to 1L bypasses common name validation within libcurl. My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is boolean and true, the opt value for libcurl is set to 2L. I understand that engineers should have the proper option value to begin with but weighing the impact of this (MITM attacks) against doing what they probably meant anyways is worth the presumption. Please discuss and adjust the patch if necessary. - JJ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php While I think it's a good idea to set the value of the option to 2, as is recommended for production in the documentation, I think the idea of implicitly converting a bool(true) to 2L internally might lead to unexpected behavior since some people might actually depend on normal PHP behavior to cast a bool(true) to 1 (and that might be what they actually intended). I understand there are people out there that don't read the documentation and aren't aware of the difference between curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a good idea either. We should probably just elaborate on this point a bit more in the documentation. Perhaps add a note and an example to illustrate. I notice that people tend to pay more attention to examples than anything else in the docs. Booleans ought to be 1 and 0. Casting a boolean to 2 is just wrong, a way to fix badly written code a few people have written and in so doing risk the breakage of far more code that is correct. Thats not completely true. Boolean 'false' is equal to 0 and Boolean 'true' is something different than 0, that _may_ be 1 (and in most cases is), but it's not limited too. Just said. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Why is everyone so dead set against read-only and write-only?
my opinion
1.
public read-only $hours {
get { /* .. */ }
set { /* .. */ }
}
And now? That this is even possible is reason enough for me. Especially now
the engine must take care about this inconsistency (over the whole
inheritance tree). It feels unnecessary.
2. This new keyword is unnecessary
3. Don't know, if it's just my, but I find it slightly annoying, that this
discussion even exists. The engine already knows every token, that is
required to implement this RFC, so whats this all about? This way it will
not be ready for 5.5 and I guess not for 5.6 either...
4. It is more readable, ok, but it is not that much and I think it's just
to less to say Lets rewrite everything and make everything more complex
(see 1.) and such!
I could not disagree more with you on what is pretty and readable.
To me:
public read-only $hours {
get { ... }
}
Is infinitely more readable and understandable than:
public $hours {
get() { ... }
private final set($value) { ... }
}
The latter implies that it can be set within the right context
(internally to the class), which is precisely the opposite of what is
desired (read only).
No, it's not the opposite, but only slightly more loosely: It only says It
is 'set'able from within this concrete class, but it is read-only from
_everywhere_ else, what is in most cases that, what is _really_ wanted. If
you don't want to set it, don't set it. It is your class. And for everyone
else, it's really read-only.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Wednesday, October 10, 2012 9:18 PM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This all sounds about right.
In regards to #4 - read-only/write-only:
I think that, from a pretty syntax point of view, private final set() {}
and private final get() {} are definitely our best bets. But... from a
logical point of view, I prefer read-only/write-only.
private final get() {} is technically saying it will always return null.
private final set() {} is technically saying that setting doesn't do
anything - but it still works.
But I don't see any sane scenario where someone would want to do the
above. Therefore, it may just be best to use them in place of the currently
proposed read-only/write-only.
On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest cpri...@zerocue.commailto:
cpri...@zerocue.com wrote:
Okay, I would like this to be the last time there are revisions to this
RFC.
To sum up the last few days of conversations, I have these down as points
of contention:
1. Accessor functions should not be present on the object and callable
directly, for example, $o-__getHours() should not be allowed.
2. Preferred syntax for accessors should be public set($value) { ... }
with no magic $value (with possible type hinting)
3. Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing most everyone.
4. read-only / write-only keywords, keep them or get rid of them? There
is no directly suitable replacement but I believe a private final set() { }
will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors
6. The truth of reflection. Should it reveal details internal to how
PHP works on the inside or should it reflect the way PHP presents it as
options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand and
we can cast our votes and be done with it, then I will finish the project
and get it out the door.
-Clint
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/11 Clint Priest cpri...@zerocue.com
Rather than go to the trouble of finding a reasonable way to hold a vote
on these issues, is there anyone against the following changes:
1) Eliminate the ability for an accessor to be called via
$o-__getHours(), the accessor functions will be completely unavailable for
use except as property references ($o-Hours)
I don't really care, but what were the concrete objections? You can call
__construct() directly too and that is similar ... not useful ^^ Assuming,
that most developers should try to avoid unuseful stuff, wouldn't it be
more complicated to explicitly restrict the access?
2) Change syntax to use public set($value) { }, public get(), etc. (and
along with that means no more magic $value)
2a) If possible, allow for Type Hinting...
3) Eliminate automatically implemented get; set;, no automatic backing
field creation will occur.
4) read-only / write-only keywords will be eliminated
5) Exceptions thrown from accessors will be made more appropriate (I will
also check debug_backtrace information, etc)...
If there isn't anyone against the above changes, I will make the changes
to the RFC and re-present for final agreement...
Or... do ya'll want to vote on the aforementioned changes?
-Original Message-
From: Clint Priest [mailto:cpri...@zerocue.com]
Sent: Wednesday, October 10, 2012 7:36 PM
To: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
Okay, I would like this to be the last time there are revisions to this
RFC.
To sum up the last few days of conversations, I have these down as
points of contention:
1. Accessor functions should not be present on the object and callable
directly, for example, $o-__getHours() should not be
allowed.
2. Preferred syntax for accessors should be public set($value) { ...
} with no magic $value (with possible type hinting) 3.
Automatically implemented get; set; with auto-backing field should be
eliminated as this is not necessary for PHP and is confusing
most everyone.
4. read-only / write-only keywords, keep them or get rid of them?
There is no directly suitable replacement but I believe a private
final set() { } will take care of it, even though it much more verbose.
5. Error handling for thrown exceptions should be made more appropriate
for accessors 6. The truth of reflection. Should it reveal
details internal to how PHP works on the inside or should it reflect the
way PHP presents it as options?
Did I miss anything?
I will come up with some way for people to vote on the issues at hand
and we can cast our votes and be done with it, then I will
finish the project and get it out the door.
-Clint
--
github.com/KingCrunch
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/9 Christian Kaps christian.k...@mohiva.com
Hi,
typehinting should definitely be available for this feature. But I have
another question. Why not go more consistent with the rest of the language?
I have mentioned this previously as the first proposal comes up on the
list. In my opinion the AS3 getter and setter syntax(
http://help.adobe.com/**en_US/ActionScript/3.0_**ProgrammingAS3/**
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
WS5b3ccc516d4fbf351e63e3d118a9**b90204-7fcbhttp://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb)
fits more into the language as the proposed one.
Here are my concerns:
- I do not like the extra indentation level and it's ugly to document (OK,
this is a personal preference)
I guess it's more useful to document the property as a whole and not every
single accessor on it's own.
- It isn't possible to declare a private setter and a public getter, as it
is possible with methods
As far as I understand it it is possible.
- If we ever get return type hinting/checks then we needn't consider how
the syntax has to look
- We must deal with two different syntaxes for the same thing, because both
are methods
For now it seems the only bigger difference is, that the keyword 'function'
is omitted. You can propose to add it :)
- IDE's, documentation tools, static analyses tools or similar tools have
a huge effort to implement this syntax. With the method syntax it's only a
small effort
The tools should not decide how the language should look like, just because
it makes their life easier ;)
- We have to create new rules about how the documentation for this syntax
should look like
Why should the documentation differ from the documentation for regular
properties?
For me the following syntax seems more consistent with the rest of PHP:
public get hours() {}
public set hours(DateTime $dateTime) {}
public isset hours() {}
public unset hours() {}
Or:
public function get hours() {}
public function set hours(DateTime $dateTime) {}
public function isset hours() {}
public function unset hours() {}
Or:
public function get $hours() {}
public function set $hours(DateTime $dateTime) {}
public function isset $hours() {}
public function unset $hours() {}
I don't like how it separate the single accessors from each other. The
benefit from this RFC (imo) -- especially compared to __get()/__set() --
is, that every accessors is directly and obviously bound to the (single)
property: You have a single block with all the corresponding accessors in
it and not several (on the first glance: different) methods, that could be
spread over the whole class.
Maybe it's just me, but I really would like to see this feature in 5.5. As
far as I remember it was first proposed for 5.3 and now (years after)
seeing it delayed, because the syntax looks ugly (just my opinion) makes
me feel a little bit ... ehm ... sad. I think the syntax is fine and it
seems it covers the most important points (even not all). There is a
property and the value of the property are the accessors. I bet we could
find an infinite number of different syntax, that provides exactly the same
functionality, but why?
Regards,
Sebastian
Cheers,
Christian
Am 09.10.2012 05:08, schrieb Jazzer Dane:
While I understand your concern with set being the only keyword using (),
and even agree it's a bit problematic, I see a big problem with using
$value.
Even if $value internally makes sense due to something along the lines of
*
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a good
idea.
If I see $value in the code, I'll logically look for where it was defined,
and when I don't see it anywhere else in the code, things are going to
very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a note in
the documentation. That's not enough.
A similar alternative to using $value that I'd argue would be much more
sensible would be to, as Denis mentioned, use either a magic constant or a
superglobal.
As I mentioned previously, I would rather go with the set($value) {}
syntax.
Now, back to the part where I agree with you - the inconsistency wherein
set has () that denote it is a method but get, isset, and unset do not. I
see this inconsistency as something problematic enough to warrant a
solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which they
are!
If anything, adding parenthesis to all of them makes the implementation *
more* sensible.
2) It's *only* two more
Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
2012/9/19 Tomas Creemers tomas.creem...@gmail.com
Hi all,
If this is going to be implemented as a class, what is the advantage
of instantiation for this? Unless I'm missing it, I would propose that
the functions are made static.
In other words, I would prefer this:
echo Escaper::escapeHtml('btest/b');
over this:
$e = new Escaper;
echo $e-escapeHtml('btest/b');
Regards,
Tomas
Hi,
I guess the reason is the same like the one, why you just should avoid
static methods at all. But only one example: Try to extend the class and
then _always_ use the extended one ;)
Regards,
Sebastian
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site Scripting remains one of the most common vulnerabilities in
web applications and there is a continued lack of understanding
surrounding how to properly escape data. To try and offset this, I've
written articles, attempted to raise awareness and wrote the
Zend\Escaper class for Zend Framework. Symfony 2's Twig has since
adopted similar measures in line with its own focus on security.
That's all. The RFC should be self-explanatory and feel free to pepper
me with questions. As the RFC notes, I'm obviously not a C programmer
so I'm reliant on finding a volunteer who's willing to take this one
under their wing (or into their basement - whichever works).
https://wiki.php.net/rfc/escaper
Best regards,
Paddy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] RFC: alternative callback syntax
2012/9/19 Steve Clay st...@mrclay.org Hello, https://wiki.php.net/rfc/**alternative_callback_syntaxhttps://wiki.php.net/rfc/alternative_callback_syntaxis a proposal for a simple alternative syntax for creating function callbacks. The basics: Given a function/method call, replace the argument list with ::function. PHP would evaluate this as a callback for the function/method, fully resolving any class/function names according to the current namespace and any use statements. In my opinion this syntax would aid readability and benefit users via fewer typos and namespace errors, and via (hopefully) better IDE support. I welcome any feedback. I don't have adequate C skills to offer a patch at the moment, but I generally read everything I can get my hands on about how PHP features are implemented and am not afraid to jump in. Thanks for your time. P.S. I've kicked around this idea around for awhile, but Ralph Schindler's idea for using ::keyword provided a better path to BC, and more attractive/meaningful syntax. P.P.S. I'm unaware if it's customary to throttle the release of RFCs, so I apologize for hogging any attention away from those under discussion. Steve Clay Hi, Beside that I like the idea to get rid of defining callbacks as string (for the same reason I like 'Classname::class' for classes) I don't like, that functions will look like classes with a static property function then ... Regards, Sebastian -- http://www.mrclay.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
2012/9/19 Tomas Creemers tomas.creem...@gmail.com On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs krebs@gmail.com wrote: 2012/9/19 Tomas Creemers tomas.creem...@gmail.com Hi all, If this is going to be implemented as a class, what is the advantage of instantiation for this? Unless I'm missing it, I would propose that the functions are made static. [snip] Regards, Tomas Hi, I guess the reason is the same like the one, why you just should avoid static methods at all. But only one example: Try to extend the class and then _always_ use the extended one ;) Regards, Sebastian Isn't that what late static binding is for? It enables the use of the extending class (if any) from the base class. late static binding is for runtime-resolvement of the class _within_ the class. If you spread the (external) call FooEscaper::escapeJs() all over you code, you'll have much fun changing every occurence of FooEscaper once you extend it. Regards, Sebastian I really don't see what class instantiation would add to this design (if it's going to be a class at all). It doesn't have instance-specific state. Regards, Tomas -- github.com/KingCrunch
Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
2012/9/19 Tomas Creemers tomas.creem...@gmail.com
On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs krebs@gmail.com
wrote:
2012/9/19 Tomas Creemers tomas.creem...@gmail.com
Hi all,
If this is going to be implemented as a class, what is the advantage
of instantiation for this? Unless I'm missing it, I would propose that
the functions are made static.
[snip]
Regards,
Tomas
Hi,
I guess the reason is the same like the one, why you just should avoid
static methods at all. But only one example: Try to extend the class and
then _always_ use the extended one ;)
Regards,
Sebastian
Isn't that what late static binding is for? It enables the use of the
extending class (if any) from the base class.
I really don't see what class instantiation would add to this design
(if it's going to be a class at all). It doesn't have
instance-specific state.
Regards,
Tomas
Oh and just to throw that in: If the additional variable (or the extra
line) is a problem
echo (new Escaper)-escapeHtml('btest/b');
// vs.
echo Escaper::escapeHtml('btest/b');
--
github.com/KingCrunch
Re: [PHP-DEV] an configure option to enable-all
2012/9/17 jpauli jpa...@php.net I'm confused.. --enable-all is already supported, just like --disable-all ? -Hannes AFAIR no :) We have a --disable-all , but no --enable-all. I'm +1 to add such an option if possible :) Julien.P I don't like the idea, because once --enable-all is available every new extension would be a BC, because it would be enabled not by default, but at least and probably unexpected. In worst case no new extensions are possible anymore... Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] an configure option to enable-all
Am 16.09.2012 22:20, schrieb Hannes Magnusson: On Sun, Sep 16, 2012 at 8:50 PM, Michael Felt mamf...@gmail.com wrote: Hi. My apologies if I missed an obvious clue somewhere, but I am looking for a configure option to enable nearly everything - to be supplemented by select disable statements. In the past I have had complex configure scripts that I would like to simply with selective deletes, rather than discover afterwards that I forgot something. configure --help does not convince me it is listing all options (might be wong, might not be reading carefully enough). Thanks (even if just pointing me at what I should have found!). I'm confused.. --enable-all is already supported, just like --disable-all ? -Hannes I think he means something like --enable-all --disable-X --disable-Y. Don't know myself, if this is possible right now. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method
Hi, As far as I can see everything works as expected: Because HEAD-requests should not send any content, you don't get any. Regards, Sebastian 2012/9/12 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net Hello, It is probably me but it seems like the build-in HTTP server does not well support the HEAD method. Here is my following test case. First, the foo.php file: ?php var_dump($_SERVER['REQUEST_**METHOD']); And then: $ # Run the server. $ php -S 127.0.0.1: -t . foo.php /dev/null 21 $ # Test with POST. $ curl -v -X POST 127.0.0.1: * About to connect() to 127.0.0.1 port (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port (#0) POST / HTTP/1.1 User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 Host: 127.0.0.1: Accept: */* HTTP/1.1 200 OK Host: 127.0.0.1: Connection: close X-Powered-By: PHP/5.5.0-dev Content-type: text/html string(4) POST * Closing connection #0 $ # It works, cool. $ # Now, test with HEAD. $ curl -v -X HEAD 127.0.0.1: * About to connect() to 127.0.0.1 port (#0) * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port (#0) HEAD / HTTP/1.1 User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 Host: 127.0.0.1: Accept: */* HTTP/1.1 200 OK Host: 127.0.0.1: Connection: close X-Powered-By: PHP/5.5.0-dev Content-type: text/html * Closing connection #0 I have to admit that I don't understand, even by looking at the source code. Thoughts? Thanks. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- github.com/KingCrunch
Re: [PHP-DEV] Combined assignment operator for short ternary
Am 25.08.2012 18:38, schrieb Ferenc Kovacs:
would this trigger a notice if $foo is not defined?
if yes, then it would be different from the current behavior of the
ternary operator.
Couldn't believe it, thus I tested it myself
snip
Don't know, what you are talking about, but the notice _is_ the
current behaiour and therefore: No difference.
Sorry, I messed up that email. What I wanted to say:
If it accepts unset variable, then I could see usecases for it, but then
it would behave differently than the current ternary.
If it doesn't accept unset variable then it would in line with what we
have, but I don't see any usecase for it, because I would have to set it
before checking that it is falsely or not, in which case I would set it
to the default if not set already.
if no, then I would never use this.
I mean if I have to set the variable before the check, then I
would put
the check into the assignment.
The main thought about it was
function foo ($bar = null) {
$bar = $bar ?: 'default';
}
If you wanted to enforce the 'default' value to be the default if no
argument passed, then you could use $bar = 'default' in the method
signature.
So I guess that you use that construct to handle when the argument is
passed, but it contains a falsely value (0, array(), 0, etc.).
I agree that this can be useful in some cases.
I _always_ use 'null' as default
For me, it isn't always null, sometimes it is boolean true/false, or an
empty array.
- If you want to omit a parameter, but want to set one after that,
you don't need to look whats the default: It's 'null'
my IDE takes care of that problem for me.
Only works on the green field ;) And/or if you are alone ...
- Ive often enough seen something like
function foo ($limit = 10) { /* code */ }
// Somewhere else
function bar ($limit = 50) { /* code */ $foo($limit); /* code */}
// Even somewhere else
bar();
same here.
Same here :p
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Combined assignment operator for short ternary
Am 25.08.2012 01:53, schrieb Nikita Popov: On Sat, Aug 25, 2012 at 1:49 AM, Sebastian Krebs krebs@gmail.com wrote: Hi, It's like with any other compound operator: A _real_ reason isn't there. But saying It's not worth it is something I can live with (even if I don't know how much effort it would take ;)). I just asked myself: '?:' is (a kind of?) binary operator and every other binary operator is available as compound operator, so why not '?:', so I don't have to repeat the variable? No, every other binary operator is not available. If I interpret this right one could say that all short-circuiting operators are not available. E.g. you also can't write $foo = $bar; or $foo ||= $bar. The ?: operator also falls in this category of short-circuiting logical operators. Yes, makes sense... And thinking further I think myself it's better to keep it as it is. So thanks for your time :) Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Combined assignment operator for short ternary
Am 26.08.2012 01:57, schrieb Ferenc Kovacs: So you are saying that your (teams) IDE doesn't tell you the method signature which contains also the default values? I guess that the fact that many of the php core functions have optional arguments and non null defaults must be really a PITA for you. I think what he was alluding to is the problem where one changes the default. All usages of the method/function then need to be updated. Using null today is very much like using the proposed 'default' parameter skipping RFC. true, using null as a default value for your optional arguments means that you don't really need the parameter skipping RFC (at least for the functions that you control) or the named params, because you can pass null for the in-between optional arguments. ofc. most modern IDEs also have some kind of refactoring feature, which would make it easier for you to update the function calls to reflect the change in the default value, but it would be harder to tell the original intention ($limit is 30 here, because it was the default and the caller wanted to set the next optional argument, or $limit is intentionally set to 30 and the next optional argument also happen to be needed). thanks for clearing that one up for me. Having every optional argument defaulting to null means that it can be frequent scenario, when you have a variable, which is guaranteed to be defined, but can be null. But I still think that it isn't that frequent that you want to keep the non falsely values or set a default value otherwise. I mean if you expect a number, then you don't want your passed 0 to be replaced with the default, or if you expect a string, you don't want 0 or maybe even to be replaced with the default, etc.. So you couldn't use the ternary assignment for those scenarios. Yes, it doesn't work in this cases, but I must say - I try to avoid optional parameters whereever useful. The caller should be aware of what he is doing. I prefer to define preferred values as constants instead, that can be used whereever a preferred behaviour is wanted. - I do't implement very much functions/methods, where (e.g.) 0 is allowed and should _not_ be the default (same for strings and so on), thus '$index = $index ?: 0;' is valid regardless wether $index is 0 or null in the first place. Or if I expect a string the empty string '' is most of the time a special cases (or required). If I expect an object is just obvious, that they can never evaluate to false. I don't think we need argue about this, because this two points are more or less personal preferences/opinions. But this said there are only some few edge cases (for me), where I need to distinguish between '', 0, null, ..., and in this few cases, I can still use the good old `$index = is_null($index) ? 123 : $index;` ;). At the end: It works just great to use null as general-purpose-default. I don't care about a special 'default'-keyword, because in my mind something like that already exists in form of 'null': It's either the default primitive value, or no-object (in case an object was expected, but not required). -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
2012/8/24 Peter Nguyen pe...@likipe.se Your argument is a general issue when refactoring code. Whenever you change the name of a method/class, you need to change it in all the places that use it, even in the AOP definitions if you have it of course. The advice is just a PHP callable so it works in the same way. I talked about refactoring the joint points, not the advises, but thats not the point. If I refacter an identifier my IDE (I use PhpStorm, but the others should be that powerful too) supports me by searching for every occurence of the identifier, or even without the need to refactor stuff I can call find usage. With a string like $ 'Classname::method()' or $ 'Classname-method()' I need at least text search, that should work reliable, when no dynamic strings occur, because with $ 'Classname::' . $method it's getting hard, if not even impossible. One default case (it's mentioned in the quickstart of the extension) are the wildcards $ 'Classname::do*() I guess this would take much effort. Just refactoring is not that easy anymore. Don't get me wrong: I like AOP as idea and as concept, but I'm afraid, that it could lead to scary construction, where noone can trace, what happens when and why. Also as I mentioned I don't even have any better idea ;) Regards, Sebastian 2012/8/23 Sebastian Krebs krebs@gmail.com Hi, From my users point of view: I would like to see it. Maybe not in this implementation/syntax, especially because it hasn't a special syntax (but imo it should to make the impact more obvious/prominent). With the joint points as string and the common function call I can imagine it can get hard to find out, where a specific advise where attached, or which were attached at all, or just how many. For example I rename a method/class and I will not recognize, that a security advise gets lost, I may realize it as soon as I find my data on pastebin ;) But I have no idea how it could look like Regards, Sebastian Am 23.08.2012 16:36, schrieb Peter Nguyen: Hi, AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programminghttp://en.wikipedia.org/wiki/Aspect-oriented_programming) when used correctly, can make your application really modular. I've seen several implementations but they all require compiling of code beforehand. There is however a PECL extension now (https://github.com/AOP-PHP/**AOPhttps://github.com/AOP-PHP/AOP) that enable AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
[PHP-DEV] Re: Combined assignment operator for short ternary
Hi, Just want to push my thread ^^ Nobody interested? Too stupid? I need to learn C (:X)? Too complicated? To much impact (on something)? Too less sense? BC? Anything not mentioned here? To point that out: I _don't_ want to change the behaviour, which means | $foo['xy'] ?:= 'bar'; would trigger a notice like | $foo['xy'] = $foo['xy'] ?: 'bar'; would do. Regards, Sebastian Am 17.08.2012 23:41, schrieb Sebastian Krebs: Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; I have many of this default assigments and yes: This is just syntactic sugar. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
