Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Stan Vass wrote: It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) They do so because it looks like gibberish to them, so it looks unlikely to be a common thing you can Google, nor it gives something recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) Yes, we all acknowledge it's an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly causing support issues. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Makes sense, just alias it and change the error message thus keeping bc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Jonathan Bond-Caron wrote:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is wrong but I was under the impression that the only way to
enforce a signature is using an abstract class or interface?
php allows it:
PHP 5.2.13 with Suhosin-Patch 0.9.7 (cli) (built: Aug 14 2010 16:39:00)
PHP 5.3.99-dev (cli) (built: Aug 20 2010 07:45:44)
?php
class P { function dot(Child $o) { echo .; } }
class Child extends P { function dot(P $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
class P2 { function dot (P2 $o) { echo .; } }
class Child2 extends P2 { function dot(Child $o) { echo .; } }
$t = new Child;
$t-dot( new P );
$t-dot( new Child );
?
perhaps you mean..
$t = new Child2;
$t-dot( new P2 );
$t-dot( new Child2 );
:)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Johannes Schlüter wrote:
On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
Hi!
I was under the impression that, in order for inheritance to provide
proper polymorphism, overridden methods should share the parent's method
signature, although they can have additional optional arguments.
Your impression is wrong. Overriden method should have _compatible_
signature - i.e. accept any argument set that parent object accepted.
Nothing requires it to have the same signature.
Let|s take a look at making it one step more complex:
class A {
public function foo(Foo $a = null) {}
}
class B extends A {
public function foo() {}
}
class C extends B {
public function foo(Bar $a = null) {}
}
Here B::foo() is compatible with A:foo() and as the parameter is
optional C::foo() is compatible with B::foo(). But C::foo() is no more
compatible with A::foo().
So I consider the message good and correct.
what if Bar implements Foo, or Bar extends Foo - surely that should be
compatible given the inheritance chain.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Zeev Suraski wrote:
At 17:04 19/08/2010, Ionut G. Stan wrote:
I can't call Child::foo() with an instance of Taz, but I can call
Parent::foo() with such an instance. So, I can't use instances of
Child wherever instances of Parent would be accepted.
Child should clearly not be allowed to inherit Parent in the code above,
since the signature of Child::foo() is more restrictive than the
signature of Parent::foo(). The other way around could work (although I
don't recall if we allow it):
class Foo {}
class Bar extends Foo {}
class Parent
{
public function foo(Bar $bar){}
}
class Child extends Parent
{
public function foo(Foo $foo){}
}
No issues here - since any Bar object is also a Foo object and would
pass the is_a validation of Foo. Again, I don't recall if we allow such
signature overrides or not.
Zeev
Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a
real example - Zeev I've copied the way you specified above.
class Point2D { // Foo
public $x;
public $y;
}
class Point3D extends Point2D { // Bar extends Foo
public $z;
}
class Point2DManager { // Parent
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
class Point3DManager extends Point2DManager { // Child extends Parent
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
You're saying that makes sense and is no problem? honestly?
Best,
Nathan
ps: no offence / nothing personal just want to get this cleared up
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Chris Stockton wrote:
Hello,
On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham nrix...@gmail.com wrote:
Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a real
example - Zeev I've copied the way you specified above.
I think your misunderstanding his position. To summarize my
understanding: he clearly states that in such a use case a warning is
in order, however currently the warning is overly aggressive. I think
in general this is a small fish in the pond but I see his point.
Perhaps I am, I think his example was wrong - if it was an example of
doing it the wrong way and an example which should trigger a warning
then yes I totally agree.
To clarify, hopefully - given:
class Point2D {}
class Point3D extends Point2D {}
the following is incorrect and should raise a (heavy) warning (Zeev's
example with class names changed for clarity):
class Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
whilst the following is correct, and should not raise any warning:
class Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
If we're all saying the same thing then great and apologies for the
confusion.
Best,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
postmas...@colder.ch wrote:
- Nathan Rixham nrix...@gmail.com wrote:
class Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
This is incorrect. Any class extending Point2DManager should be able to provide
at least as much functionality as the parent class. In other words, it should
not tighten the pre-conditions.
In your case, Point3dmanager will no longer be able to handle 2dpoints, which
is a mistake.
lol, got it - confused myself for a bit there! yes agreed..
incorrect:
class Parent { function equals(Parent $o) {} }
class Child extends Parent { function equals(Child $o) {} }
correct:
class Parent { function equals(Child $o) {} }
class Child extends Parent { function equals(Parent $o) {} }
sorry about the noise,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPKAC support for openssl in PHP
Hi All, Wondering if there is any support for SPKAC [1] in the openssl extension for PHP? If not is it planned, and if not can it be? KEYGEN/SPKAC support is growing in the UA vendors and KEYGEN is part of HTML5, being the preferred way to generate client side SSL certificates since the private key never leaves the browser. Further the need for client side certificate generation will be growing somewhat over the next couple of years thanks to FOAF+SSL - which I believe is about to start going through standardisation. At the minute we have to take a rather hacky approach in PHP [2] and it get's much worse if you want to use x509 v3 extensions, you have to go through a nasty process of using a bash script to gen a custom openssl.conf on the fly to use in the SPKAC request. Best, Nathan [1] http://en.wikipedia.org/wiki/Spkac [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/07ea5534/attachment.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SPKAC support for openssl in PHP
Moving forwards a lot of authentication will be done in an HTTP friendly stateless manner, namely via HTTPS where the user is identified by client side ssl certificates. In order to give the user a certificate, you need to generate one, which you can currently do with openssl in php, and provide the user with a pkcs12 certificate+private key to install. However, pkcs12 has a security flaw in the the application giving the certificates also has the private key. SPKAC addresses this because the private key never leaves the users browser, thus it is the preferred option - and as mentioned there will be an ever increasing need for this in PHP once HTML5 takes off (due to the KEYGEN element which is widely supported already) and FOAF+SSL which as I mentioned will be going through standardisation in the near future. Best, Nathan Sriram Natarajan wrote: I am curious as to why you need this feature within PHP. I would expect that web server administrators typically need such feature but I am missing the context of it within PHP script engine. - Sriram On Tue, May 18, 2010 at 2:05 AM, Nathan Rixham nrix...@gmail.com wrote: Hi All, Wondering if there is any support for SPKAC [1] in the openssl extension for PHP? If not is it planned, and if not can it be? KEYGEN/SPKAC support is growing in the UA vendors and KEYGEN is part of HTML5, being the preferred way to generate client side SSL certificates since the private key never leaves the browser. Further the need for client side certificate generation will be growing somewhat over the next couple of years thanks to FOAF+SSL - which I believe is about to start going through standardisation. At the minute we have to take a rather hacky approach in PHP [2] and it get's much worse if you want to use x509 v3 extensions, you have to go through a nasty process of using a bash script to gen a custom openssl.conf on the fly to use in the SPKAC request. Best, Nathan [1] http://en.wikipedia.org/wiki/Spkac [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/07ea5534/attachment.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Richard Lynch wrote: I have taken the liberty of making an RFC for this: http://wiki.php.net/rfc/url_dots Feel free to add/edit it as fit, particularly since it's my first use of that RFC wiki, and I'm not good at wiki markup, and I probably missed something from this thread. I intentionally left out the ?a_b=1a.b=2 because that seemed to me to be beyond the scope, since ?a_b=1a_b=2 is equally problematic in PHP... That said, I am now leaning towards not trying to be BC, and just dropping 'a_b' entirely. It seems unlikely that anybody doing anything sane to attempt to reconstruct their original keys is going to be hurt by PHP not messing them up anymore. Most likely, their revisionary code is simply not going to find any 'a_b' to blindly revert to 'a.b' anymore, and the 'a.b' is going to just sail through. Of course, their a.b might be a^b or a*b or whatever, but whatever it is, PHP not messing it up will just mean their code won't find anything to un-do any more. I did think of one other issue though: There may be some really funky character that is valid in the URL, but that is not kosher for an array/hash key which is currently being masked... It would still have to be masked if such a character exists... I can't think of any such character, but what with i18n of DNS records and whatnot these days, I am woefully ignorant of what might be in the keys. I put that into the RFC already. Thanks Richard, I was struggling to get to time to write this up - all seems fine to me and just as discussed on-list. Thanks again, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Tim Starling wrote: Stan Vassilev wrote: I hope PHP6 will remove this processing as register_globals will be completely removed at that point. I'd be happy if it stayed like it is, for backwards compatibility. Sometimes forwards compatibility has to take precedence though. Linked data is set to explode around the net over the next year or two; general form fields will soon be replaced with properties from ontologies (such as foaf), people will have personal rdf graphs housed in their browsers and autocomplete will populate forms where the property uri's are known; if these form elements all contain uri's with dots swapped out with underscores then this could be a potentially big problem for the giant global graph and PHP developers specifically. All solved very easily by being able to ini switch this replacement feature on and off. on the server side.. http://example.org/ontology/0.1/some_property becomes http://example.org/ontology/0_1/some_property how do you reverse replace the correct underscore with a dot? if we use the input name=data[http://example.org/ontology/0.1/some_property]; / workaround in userland this is no doubt breaking many future browser extensions looking for input name=http://example.org/ontology/0.1/some_property; / quite sure a small patch and ini switch would cater for both BC and FC in this case; even if it was removed all together then to achieve bc would be a simple for loop and str_replace; hardly major. regards! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Alexey Zakhlestin wrote: On 21.01.2010, at 18:21, Richard Lynch wrote: For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet another php.ini flag (sorry!) to choose the behaviour. -1 from me. I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all. It would be absolutely enough to add optional var-name conversion to extract() any word from anybody on the development team to say if this removal of dot conversion (whether optional or not) can be added to some todo list or suchlike and rolled out at some point soon~ish? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Dots and spaces in variable names are converted to underscores.
Dots and spaces in variable names are converted to underscores. For
example input name=a.b / becomes $_POST[a_b].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
reason, when building linked data / rdf based applications using PHP
it's most beneficial to use subject / predicate URIs (eg
http://xmlns.com/foaf/0.1/mbox) as form input names.
also worth noting that if you send:
input name=a.b[c.d] /
you'll receive the following in php:
$_POST[a_b] = array('c.d' = val)
note no conversion of c.d to c_d
regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need inverted __sleep?
Jonathan Tapicer wrote:
Hi,
Matt's approach works also for your usecase, casting to array returns
all the properties of the class and base classes, but it has some
problems: for private properties the class name is added before the
property name, and for protected properties * is added, both things
added are between null characters, so you can remove the added string
with some regexp.
Another approach that will work is using ReflectionClass and the
method getProperties, it will return all the properties (even
private), but only of the class itself, it won't return the properties
declared in base classes, you have the get the base class
(get_parent_class) and recursively do the same thing for all the base
classes.
Regards,
Jonathan
doh, thanks Jonathan and thanks Matt - completely missed that (array)
even though I'd been using it in a different attempt using Serializable
small note is that you do not need to remove the class names or
suchlike, this works fine (and I assume is faster than recursive reflection)
public function __sleep()
{
$exclude = chr(0) . __CLASS__ . chr(0) . 'notToBeSerialized';
return array_diff(array_keys((array)$this) , array($exclude) );
}
again thanks, and apologies Matt!
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] need inverted __sleep?
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is to
serialize($this) then parse the string, but that's just wrong and what
would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need inverted __sleep?
Matt Wilson wrote:
get_class_vars + array_diff
cheers but nope; as the manual says
Returns an associative array of default public properties of the class
need private and inherited private
On May 31, 2009, at 8:04 PM, Nathan Rixham wrote:
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is to
serialize($this) then parse the string, but that's just wrong and what
would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need inverted __sleep?
matt.. that's public properties on a single class - see the usecase
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
Matt Wilson wrote:
mwil...@mattw-mac:~$ php -r 'class a { public $a, $b, $c, $d; public
function __sleep() { return array_diff( array_keys( (array) $this),
array(b,c)); } } $a = new a; var_dump($a-__sleep());'
array(2) {
[0]=
string(1) a
[3]=
string(1) d
}
On May 31, 2009, at 8:46 PM, Nathan Rixham wrote:
Matt Wilson wrote:
get_class_vars + array_diff
cheers but nope; as the manual says
Returns an associative array of default public properties of the class
need private and inherited private
On May 31, 2009, at 8:04 PM, Nathan Rixham wrote:
Hi All,
hoping somebody can help me here..
I need to implement an inverted __sleep method, by which I mean to
specify what variables should not be included.
use case:
?php
class base
{
private $notToBeSerialized;
public function __sleep()
{
// TODO code return instance properties excluding $notToBeSerialized
}
}
class foo extends base
{
private $bar;
}
class poo extends foo
{
private $baz;
}
$p = new poo;
echo serialize($p);
I've tried using get_object_vars($this), and ReflectionObject($this)
both of which don't include all the properties of the instance.
the only way I can see to get all the properties of the instance is
to serialize($this) then parse the string, but that's just wrong and
what would sleep return on the first call to serialize.
any help greatly appreciated.
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Why does $_REQUEST exist?
Michael Shadle wrote:
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
bc? all the reasoning in the world won't justify it to 1 million
businesses running php 4 code which is reliant on $_REQUEST behind the
scenes.
although it would generate a tonne of freelance work :p
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_class_vars / params / contents
Christian Schneider wrote: Lukas Kahwe Smith wrote: On 21.01.2009, at 12:00, Karsten Dambekalns wrote: On 21.01.2009 11:44 Uhr, Kenan R Sulayman wrote: I did propose the function because the construction in user-land is quite expensive; Reflection is expensive, indeed. The way we solved it for FLOW3 is to create a ReflectionService that caches such information as long as the source doesn't change. yeah its a general problem .. but so far the decision has been that we should move away from adding more and more functions/methods for highly specialized cases (as in not continue in the get_class() etc. approach). now speeding up reflections is a very real issue .. suggestions in this regard are quite welcome. maybe offering a cache service as part of core is one approach .. Yes, please. Keep clutter out of the engine especially for stuff which should not be used often. If you are relying on Reflection to be fast for you everyday code then you're IMHO doing something weird and it is ok that you have to write your own caching for it (-:C seems to me that many of the new requests coming in, including my own stupid ones are because people want to build fast decent orm's in php - a definitive list of what one needs to make an orm in php, the userland approaches possible, what could be implemented in php and what couldn't might be good. address the whole thing in a oner. quite sure the requests and need is only going to grow.. imho it's being encouraged by the increasing numbers using PDO - it kind of suggests building an orm :p also, very unlike me, but a service to cache reflection classes is quick and simple to implement in userland - (although if there is a free speed up to reflection going I'll 'ave some) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_class_vars / params / contents
Christian Schneider wrote: Nathan Rixham wrote: seems to me that many of the new requests coming in, including my own stupid ones are because people want to build fast decent orm's in php - Having built an ORM system myself I can say that you don't need Reflection (or even other fancy features not yet in PHP) for this. Maybe you are trying to use a hammer when the problem is not a nail, - Chris likewise didn't use reflection myself when interfaces and class architecture can be used; but there is the whole persist objects that don't extend or implement you're own classes/interfaces thing - hence the possible reflection need (to get the private/protected properties) depends on the design approach I guess -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: maybe we could all?
Nathan Rixham wrote: Project: PHP Common Objects and Datatypes wrong list - forget; meant for general! sorry - having a good week - and it's monday. *sigh* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
first off; had a rather in-depth (but lacking when it comes to internal
input) over on the general list; has been interesting.
Lukas Kahwe Smith wrote:
On 17.01.2009, at 18:06, Nathan Rixham wrote:
a: Optional Static Typing
I'm finding an ever increasingly need to be able to staticly type
properties, parameters, return types etc (in classes) I know there is
type hinting but it's just not enough to do what one needs.
Additionally support for staticly typing primatives.
I am not a type hinting fan .. then again I think that PPP is mostly
bogus for a scripting language as well. I would not mind this stuff if
it would just all just throw E_STRICT's instead of E_FATAL. To me the
point of a glue language is to keep running until the engine is about to
explode or the request has finished.
After talking this one out (and negating which E_ is thrown) I've come
to the conclusion that optional type hinting in the following places
would suffice:
class Example {
private TypeHint $var;
...
Example $var = new Example();
...
and finally primative/scalar type hinting in all of these places.
b: Object superclass
A base class type which all objects automagically extend, with (if
nothing else) a unique id / hashcode for each object. Failing this
some form of function to get a unique reference string for any variable.
I think this is quite pointless. I do not see any need for magic here.
No need to be able to magically redefine the base class and saving the
few chars to type is also not sensible (and this will not give you MI
through the backdoor either).
I'd be tempted to agree; however while you can currently TypeHint in php
as such:
public function whatever(array $someArray)
and
public function whatever(SomeClass $obj)
*you can't*
public function whatever(object $obj)
which seems rather strange, some people are of the belief/misconception
that stdClass is the superclass of all objects but it just isn't; all in
it means that one can't specify (typehint) that a method param should
simply be an object - seems strange and hopefully the internals will
concider adding this functionality at the very least.
In the above scenario of you adding this functionality I ask you would
the logical and appropriate approach be to perhaps make stdClass or some
other class the super of all objects, and if this was the case surely
adding in the functionality implemented in spl_object_hash or the
discussed spl_object_id may be appropriate.
(reasons why not would be great) - or would the approach be to allow the
aforementioned public function whatever(object $obj)
c: Method overloading
TBH it's something I could live without, whereas a/b aren't, but it
would be an ideal addition to php; Many times I've had to work around
the lack of this functionality with (what could be) unneeded code.
You mean polymorphism? I hope we will never see that in PHP. This kind
of magic is dangerous and just forces PHP even more into a static typed
corner. Maybe you need to whip up a patch for your PHP version that
makes PHP statically typed?
fair enough; stut also raised the point that it makes no sence to
implement this when you can have variable argument lists.
re patch: would love to, considering it, 7 years since I touched c -
otherwise this is the approach I'd be taking! may still yet.
additional:
a magic method __cast may be beneficial to allow users to create there
own primative/scalar wrappers and convert from primative to wrapper and
back.. thoughts?
cheers for the input lukas.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
Hannes Magnusson wrote:
On Sun, Jan 18, 2009 at 17:42, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 17.01.2009, at 18:06, Nathan Rixham wrote:
a: Optional Static Typing
I'm finding an ever increasingly need to be able to staticly type
properties, parameters, return types etc (in classes) I know there is type
hinting but it's just not enough to do what one needs. Additionally support
for staticly typing primatives.
I am not a type hinting fan .. then again I think that PPP is mostly bogus
for a scripting language as well. I would not mind this stuff if it would
just all just throw E_STRICT's instead of E_FATAL. To me the point of a glue
It doesn't throw E_FATAL. It throws E_RECOVERABLE_ERROR which doesn't
do anything.
E_RECOVERABLE_ERROR seems appropriate IMHO
I've reworded my original mail completely maybe this one will have more
feedback (or not)
question: Would anybody else like to see, or feel the need for,
*optional* type hinting of variables and class properties in PHP?
examples (all optional, and syntax may differ):
class Example {
private TypeHint $var;
}
Example $var = new Example();
in addition the ability to type hint primatives/scalars/[type object] in
the existing implementation:
function(bool $flag) {
}
function(object $flag) {
}
This would all be under the assumption and proviso that an
implementation would not break bc, have any markable perfomance hit, or
in any other way effect existing applications or new applications that
did not use the functionality (in the same way the existing type hinting
implementation doesn't)
internals: can anybody confirm if this would even be possible and if so
what the cost would be?
regards, thanks / apologies where needed etc.
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really Need..
Robin Burchell wrote: On Sun, Jan 18, 2009 at 9:39 PM, Nathan Rixham nrix...@gmail.com wrote: I've reworded my original mail completely maybe this one will have more feedback (or not) question: Would anybody else like to see, or feel the need for, *optional* type hinting of variables and class properties in PHP? I was involved on a thread on exactly this some weeks earlier. I (and a few others, though I don't really remember specifics) would very much appreciate the possibilities of proper code structure when working with large teams that this could help provide :) it was a thread q on primatives i think.. guess who started it *ducks* (As to your original proposal, multiple method signatures is something I've come across a need for *occasionally*, though personally, I'm not a big fan of the feature -- the one place I would like having it is __construct(). noted; found the same thing, another specific being that all classes have a default no arg constructor so it can be instantiated prior to calling the setters even if there's a constructor which demands params. Say, you've got an ORM class which is derived for usage: [snip] very interesting that you give an ORM example; this is exactly the area where I've found the need for this class property type hinting (and on web services tbh) - but still, mapping a private bool $flag to a tinyint(1) is so much easier than mapping a private $flag to it (complications multiplied somewhat with other data types) Yes, I realise that this can be done with retrieving arguments and the like, but for such purposes it's not the neatest solution syntactically.) agreed any possible implementation in php feels like more of an inefficiant hack tbh (perhaps a bit strong..)? cheers! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Really Need..
Afternoon all, Recently I've been running in to a lot of frustrations with PHP, don't get me wrong I love the language, but I just can't do what I *need* to in a few situations, specifically when dealing with Classes and Objects. I strongly feel that these need added in to PHP 6, for multiple reasons which I'd be happy to elaborate on. a: Optional Static Typing I'm finding an ever increasingly need to be able to staticly type properties, parameters, return types etc (in classes) I know there is type hinting but it's just not enough to do what one needs. Additionally support for staticly typing primatives. b: Object superclass A base class type which all objects automagically extend, with (if nothing else) a unique id / hashcode for each object. Failing this some form of function to get a unique reference string for any variable. c: Method overloading TBH it's something I could live without, whereas a/b aren't, but it would be an ideal addition to php; Many times I've had to work around the lack of this functionality with (what could be) unneeded code. I can't stress enough what a vast difference the implementation of these three features would make to php, even above many of those currently rfc'd (imo), infact I'd put them on par with the need for namespaces, and additionally they'd compliment namespaces perfectly. Is there any way to get the ball moving with any of the above? (if I was a c dev I'd do it myself.. infact even considered learning c just for this task) Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] open_basedir .htaccess relative path problem - BUG or Expected?
Hi All, Figured this was for internals before opening up a bug report. In php 5.2.8 on windows and linux (only ones tested so far) when you add in a value to open_basedir in either php.ini or a vhosts.conf file; *relative* paths suddenly do not work for the php_value error_log specified in a .htaccess file. thus: with php.ini/vhosts.conf open_basedir NOT set these values in .htaccess WILL work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt === with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: open_basedir .htaccess relative path problem - BUG or Expected?
Nathan Rixham wrote: Hi All, Figured this was for internals before opening up a bug report. In php 5.2.8 on windows and linux (only ones tested so far) when you add in a value to open_basedir in either php.ini or a vhosts.conf file; *relative* paths suddenly do not work for the php_value error_log specified in a .htaccess file. thus: with php.ini/vhosts.conf open_basedir NOT set these values in .htaccess WILL work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt === with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir .htaccess relative path problem -BUG or Expected?
Jani Taskinen wrote: Nathan Rixham wrote: with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific What exactly IS the open_basedir setting value here? Did you leave . out of it..? --Jani when open_basedir is set to the correct value (in this specific case set to the site root directory) eg /var/sites/testsite/ and the full path to the log file is /var/sites/testsite/logfile.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir .htaccess relative path problem -BUGor Expected?
Nathan Rixham wrote: Jani Taskinen wrote: Nathan Rixham wrote: with php.ini/vhosts.conf open_basedir set these values in .htaccess WILL NOT work php_flag log_errors on php_value error_log logfile.txt these values in vhosts.conf WILL work php_flag log_errors on php_value error_log logfile.txt absolute paths to the same file always work. can anybody confirm if this is a big or not before I submit? regards, Nathan please ignore the php_flag log_errors on it always works, included as it was in my test code - don't want to confuse matters. also the bug? appears not to be in 5.2.6 - thus 5.2.8 specific What exactly IS the open_basedir setting value here? Did you leave . out of it..? --Jani when open_basedir is set to the correct value (in this specific case set to the site root directory) eg /var/sites/testsite/ and the full path to the log file is /var/sites/testsite/logfile.txt just a quick one; it's def not a path error; the same config works using vhosts rather than .htaccess; and works completely using htaccess / vhosts on 5.2.6 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] christmas decorations..
I just threw the christmas tree out, came online and noticed that the decorations are still up on the php.net site; any idea when they're coming down? ho-ho-ho etc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
Ilia Alshanetsky wrote: While I whole heartedly agree with the idea, I am not sure its a good thing to do in 5.2 branch. I'd like to hear more feedback on that topic before making the decision. The only mitigating factor is that it will only affect new users since upgrading the release does not modify the INI files, unless people are running without an INI file entirely relying on the built-in defaults. On 6-Jan-09, at 10:52 AM, Lukas Kahwe Smith wrote: On 16.12.2006, at 19:50, Hannes Magnusson wrote: On 12/16/06, Derick Rethans der...@php.net wrote: On Fri, 15 Dec 2006, Andi Gutmans wrote: Time to turn it off in php.ini-dist in addition to php.ini-recommended? I would instead change them to php.ini-development and php.ini-production. In development you'd want to have this stuff on.. I think its time for a vote on that. We've been talking about it long enough. +1 ! ok warming up an old topic. it seems most people are in agreement that the above is a good idea. (so speak up if you think its a bad idea .. otherwise it just might happen ..) so it would be ok with us RM's if someone starts working on this ASAP .. this would essentially entail reviewing the current php.ini files we ship and giving good defaults for development and production. ideally this should be done with the beta1 release, because i envision there will be a bit of a need for discussion (especially from the side of the end users). regards, Lukas Kahwe Smith m...@pooteeweet.org Ilia Alshanetsky 'scuse my ignorance; but having a single well documented ini file rather multiple recommended configurations seems to make sense; purely because it will encourage users to read the file and familiarise themselves with the settings rather than simply load up which one looks best, forget about it, then come looking for help when they don't understand why they can't see error messages. I'd vote a single well documented php.ini with production defaults active. (no -dist, -recommended or suchlike) regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] display_errors = on
Marco Tabini wrote: On 6-Jan-09, at 11:49 AM, Ilia Alshanetsky wrote: I'm ok with doing for 5.3, most people when upgrade rarely look at the INI file especially if the update is done through a distribution's package management system. Not to barge in, but many people won't consider 5.2 - 5.3 a major upgrade. That's what major version numbers are for. Mt. agreed but I'd assume that most (all) distro package makers would notice it was a major version if suitably named. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Robin Burchell wrote:
Just a random thought I have from reading over that:
Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.
'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?
it would break all php code existing so far; the only real way to
implement return value types would be as such
public static function somefunc():int {
this would allow the return type to be optional and leave all existing
code functional; likewise it could be implemented for any style of
php'ing, thus:
#php4 style class method or normal procedural function
function dosumit():int {
type hints are all ready there so adding primitives /should/ be possible
without any bc issues
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Robin Burchell wrote: Hmm. How would it break it? By leaving 'function' to mean variant, it's only adding new functionality by overriding types to replace 'function', which should have no issue with older code, surely? To clarify: current method declaration: function foo() public static function foo() public function foo() because all of those current declarations would no longer work on the new version of php which implemented such change..? and I'm assuming it would be a much bigger change to the php internals than adding in an optional type after the method params..? I do like the type method() syntax though, but don't think it's a php thing..? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
2008/12/18 Dave Ingram d...@dmi.me.uk
Also, what about this case:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
I would argue that the most specific function should be called, but how
costly would that be to determine? What if you have a Baz subclass of
Bar, but no corresponding method? What if Bar itself is a subclass of Foo?
Ideally a most specific first approach, failing that I'd suggest taking
doing it the nearest first way (like we do when catching exceptions) ?
Re: [PHP-DEV] Q on Primitives
Dave Ingram wrote:
I remember that multiple signatures was said to have a possible very
difficult implementation. However, a similar behaviour can be achieved by
some instanceof().
I thought it probably would be awkward, but we do already have some type
hinting that can also be accomplished with instanceof() -- this is just
an extension of that idea. Although it's not my idea as such!
instance of is handy however it isn't the cleanest; consider:
public static function parseByte( $var )
{
$testPassed = false;
if( $var instanceof Number ) {
$var = $var-byteValue();
$testPassed = true;
} if( $var instanceof String ) {
$var = $var-__toString();
}
if( !$testPassed is_numeric( $var ) ) {
$var = 0 + $var;
$testPassed = true;
}
if( $testPassed Byte::MIN_VALUE = $var Byte::MAX_VALUE =
$var ) {
return $var;
}
throw new NumberFormatException();
}
could be:
public static function parseByte( Number $var )
{
return $var-byteValue();
}
public static function parseByte( String $var )
{
if( is_numeric( $var = $var-__toString() ) ) {
$var = 0 + $var;
if( Byte::MIN_VALUE = $var Byte::MAX_VALUE = $var ) {
return $var;
}
}
throw new NumberFormatException();
}
mini-use-case but shows how useful it would be..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Dave Ingram wrote:
Cristian Rodríguez wrote:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
Looks like you are using the wrong language, you need JAVA instead.
Yes, I'll admit it does look like Java (or any C++-like OO language) -
but PHP already does some type hinting, and IMO it can be very useful as
an additional sanity check.
Dave
I am a Java developer :p and PHP and AS3 (they're my primary languages),
some things are good regardless of what language they're from, it's not
exactly a major shift to generics or packages that I'm suggesting, just
natural progression from type-hinting and most useful whatever language
you are in.
I daily switch between PHP and Java and there are only a few things that
make logical sense to have in a language that I miss when back on php;
primitives, multiple method signatures, and the ability to call a class
member function without using this; however I'm well aware the latter is
impossible since PHP is both procedural and OO.
Regards!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Nathan Rixham wrote:
Dave Ingram wrote:
Cristian Rodríguez wrote:
class MyTestClass {
public function blah(Foo $f);
public function blah(Bar $b);
public function blah($v);
}
Looks like you are using the wrong language, you need JAVA instead.
Yes, I'll admit it does look like Java (or any C++-like OO language) -
but PHP already does some type hinting, and IMO it can be very useful as
an additional sanity check.
Dave
I am a Java developer :p and PHP and AS3 (they're my primary languages),
some things are good regardless of what language they're from, it's not
exactly a major shift to generics or packages that I'm suggesting, just
natural progression from type-hinting and most useful whatever language
you are in.
I daily switch between PHP and Java and there are only a few things that
make logical sense to have in a language that I miss when back on php;
primitives, multiple method signatures, and the ability to call a class
member function without using this; however I'm well aware the latter is
impossible since PHP is both procedural and OO.
Regards!
and strongly typed returns.. nearly forgot
public static function parseByte( Number $var ):bool {
or
public static function bool parseByte( Number $var ) {
or such like
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Q on Primitives
Don't want to take up much of you're time, just wondered if anybody
could point me to the reason why some primitives aren't in php.
Would find it very very useful to have byte, short, long, float, double
and char in php. (primarily byte and char).
while I'm here I may as well also ask about further adding type hinting
for the existing scalars and array.
and finally different method signatures such as:
class Whatever {
public function __construct(Bar b);
public function __construct(Foo f);
public function doSomething(Bar b);
public function doSomething(Foo f);
}
Regards!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Q on Primitives
Graham Kelly wrote: Hi, I think the reason there aren't more primitive types in PHP is because of the nature of the language. One of the main features of PHP over say, C (and even Java), is that the memory managment is completely transparent to the devloper. This means that it really shouldent matter to the devloper how an integer is implimented on the machine. Same with doubles and chars. Granted, I can see some reasons why forcing the data to be of a specific length or type would be handy, but I dont know if there would be a wide enough requierment for this to actually impliment it as a language feature. Plus, you usually can find a way around it anyway :). But basically, if your interest in byte and char are for conserving memory then dont be worried... PHP does a fairly good job with your memory and this wouldent actually translate into a memory savings on the machine. mainly it was for the strictness and for the extra speed gained by having a primitive at php level, to implement using say class Byte (which I have done) is seriously heavy processor and memory wise for something so simple.. especially if you consider an implementation of ByteArray.. obviously there isn't much call otherwise this would have been implemented back at v4 or at least 5; however I for one would love to see this simple little bit of support added. Would open up masses of avenues, including the ability to make some decent orm's for php (much easier to map byte to byte than scalar might be a byte but is really an integer to byte if you know what I mean. regards! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Clarifying the resolution rules
Stan Vassilev | FM wrote: Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls). personally not very disruptive, and after a few hours I think it would become second nature. I'm sure there will be a few comments about this, but.. why not move all internal functions and classes to a php namespace so that everything has to be in a namespace by default - ie no code that isn't in a namespace. ie php\file_get_contents(__FILE__); instead of \file_get_contents(__FILE__); major major change but nice and strict -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: namespace separator and whining
Greg Beaver wrote: Hi all, Let me make this brief: there will be lots of complaining about the namespace separator. Stop. Now. It serves no possible useful purpose. If you want to discuss why this was chosen or suggest alternatives, feel free to write me *off-list*. I would be more than happy to answer any questions about the technical aspects of various choices. The decision is made, now I suggest everyone get busy actually trying it out. You will very quickly understand why it is a very viable choice. Thanks, Greg just wanted to quickly say thanks for all you're long suffering hard work on this - and a great decision imho. thanks again :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/socketssockets.c
Jani Taskinen wrote:
1. This should be applied to PHP_5_2 (not big change and in no way can
break anything)
2. You can always simply put a short comment like Fixed in CVS, needs
documenting and reclassify the bug report as docu issue. There's no
need for some fancy shortcuts or such. Just tune your process..
--Jani
nice suggestion I'm gonna do that at work! saved me a headache - cheers :)
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Diogo Galvão wrote:
The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence.
As far as I understand it if your active record references the PDO
instance (say $this-conn) your object gets destroyed before the
connection object.
Perhaps it's a better approach then introducing destruction order for
global or singleton problems.
wbr,
Diogo
Larry Garfield wrote:
On Wednesday 22 October 2008 2:31:38 am Mike van Riel wrote:
I believe the end of your script part is the problem. Imagine you
have some object (say, ActiveRecord style) that writes itself to the
database when it's destroyed if the data has been modified. Now cache
that object in a static variable somewhere for performance. You're
also using PDO, so your database connection is a global or singleton
instance of the PDO class.
Then your script reaches the end. Does your object get destroyed and
therefore saved to the database before or after the PDO object goes
away? I don't actually know.
I'm not saying that manual destructor order is the correct way to deal
with that issue necessarily, but I think that's the sort of use case
it's intended to address.
just to add it in; in ejb3 in java you have PostConstruct and PreDestroy
which are pretty useful; maybe something along the same lines could be
implemented in PHP?
regards!
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Jani Taskinen wrote: Nathan Rixham wrote: just to add it in; in ejb3 in java you have PostConstruct and PreDestroy which are pretty useful; maybe something along the same lines could be implemented in PHP? Or perhaps you should just stick with Java? just a suggestion for some useful functionality - where's the harm? anyhow, apologies if I offended - have a great day :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UltraSimple Namespace Solution
Ronald Chmara wrote:
On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:
*A Simpler Solution*
Force userland / general naming conventions in PHP.
# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();
thoughts, opinions, reasons why it wouldn't work?
Assuming this is a real question:
1. PHP is heading towards broad i18n. How do you uppercase or
lowercase written languages that don't have a concept of case?
2. PHP was designed for wide adoption, and the authors of libraries
often used function and class cases that matched their library. So,
PHP case smashes, to Handle the problem of pg_pconnect (all smashed),
PG_pConnect (EXTENSION_argumentAction), Pg_Pconnect (first letter
ucase), etc. etc. etc.
Right now this all works. Changing it would break, well, darned near
*everything*.
3. The vast majority of user operating systems (and filesystems) out
there do *NOT*, I repeat, do *NOT* all handle case in the same way, a
sane way. Windows boxes are still lugging around DOS/VMS legacy with
UPPERCAS.$1 files, Macs have their own breed of jollies as well, and
anything that autoloads (such as namespace code) needs to handle all
of these.
Assuming that this is A Modest Proposal:
1. It needs to be more over the top to be funny to a broad,
multi-lingual, global, audience.
For example, you might have suggested that we add an include_instead()
operator, so somebody who wants to use a function/method which is
located in '/var/location1/file_class.inc', rather than the already
loaded function/method in '/var/location2/file_functions.inc', can
override an existing function/method, and for giggles, you might
suggest that the operator have the power to override all internal
functions, but just for local execution scope, spawning a new
process/thread for each invocation, so a blog post can have 30-80
thousand processes with different scopes to render a web page.
Okay, I'm shutting up now. :)
-Bop
Thanks Bop,
After more thought I came to pretty much the same thoughts - received
some heavy replies but then that's my own fault for treating the
internals list the brainstorming room at work!
I jump the gun often and write before thinking things through 100%; even
even I can see the namespace problem clearly enough to know that the
problem lies in php being both a procedural and OOP language, unless you
remove one or the other from namespaces there is always going to be a
level of ambiguity somewhere; IMO Greg's solution #2 (introducing ::: to
mark the end of a namespace) and stas' proposal #1 are the best I've
seen. Personally though I'd love to see stas' #1 get implemented and
- used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step-two(); //always function of namespace.
But it's still ambiguous (only in a rarely though) - if an object with a
method two is assigned to the static variable of a class called one
then problem comes back.
I'd love to see a perfect solution; but know enough to realise it
isn't going to come from me (and may well be impossible) so bailing out.
I have to say this; the reason people like me pop on to internals and
give brainstorming not thoroughly thought through (or discussed)
opinions, is because there isn't a public forum for that kind of
thing, if there was a place where userland and the internal's could meet
up to even just discuss or thrash out ideas, get opinions, votes,
whatever then it would alleviate the problem.
Regards Happy Weekend
Nathan
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UltraSimple Namespace Solution
Gregory Beaver wrote:
Nathan Rixham wrote:
seen. Personally though I'd love to see stas' #1 get implemented and
- used for all functions in a namespace so..
one::step::two(); //always static method of class
one::step-two(); //always function of namespace.
But it's still ambiguous (only in a rarely though) - if an object with a
method two is assigned to the static variable of a class called one
then problem comes back.
First of all, this is not going to happen (voted down). Second of all
one::$step
is how static variables are accessed, not one::step. So there is no
potential for conflict.
Greg
right enough; there is no conflict *joy*; and it's not introducing any
new separator's into php, and I think it makes logical sense /ponders/
I've been flittering between java, as3 and php all week and ended up
highly confused, ditsy and using the wrong syntax everywhere - so
apologies for my ramblings!
cheers for the reply; and thanks for all you're hard work on the
namespaces; the RFC you wrote on the wiki really outlined the problem
perfectly and made it more accessible to the masses.
Many Regards
Nath
--
nathan ( [EMAIL PROTECTED] )
{
Senior Web Developer
php + java + flex + xmpp + xml + ecmascript
web development edinburgh | http://kraya.co.uk/
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Marcus Boerger wrote: Hello all, Greg was so kind to give me part of his awesome upcoming Pyrus code. He actually has it running with both ':::' and '\' as namespace separators. So I thought I'd help out a tiny tiny bit by giving you all the choice of having a look at actual working code: http://php.net/~helly/triplecolon.html http://php.net/~helly/triplecolon-colored.html http://php.net/~helly/backslash-colored.html http://php.net/~helly/backslash.html marcus Thanks massively! Those code samples make it vastly clear just how many times we'll all be calling functions in the default namespace - and I for one don't fancy typing ::: for every function or normal PHP class I ever use! + \strpos() etc. just looks and types natural to me. I realise we wouldn't /have/ to type \ or ::: every time we call a 'normal' function, but I for one would prefer to by way of good practise, and those extra chars make a huge difference as far as I'm concerned. I do not want to spend the rest of my life typing ::: in front of every function. note: it type's natural as the \ is right beside zxcv on my keyboard, which I'm ctrl+tapping all the time, so comes natural to my pinky! This is a no-brainer AFAIK. Thanks again (really), Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Marcus Boerger wrote: Hello all, Greg was so kind to give me part of his awesome upcoming Pyrus code. He actually has it running with both ':::' and '\' as namespace separators. So I thought I'd help out a tiny tiny bit by giving you all the choice of having a look at actual working code: http://php.net/~helly/triplecolon.html http://php.net/~helly/triplecolon-colored.html http://php.net/~helly/backslash-colored.html http://php.net/~helly/backslash.html marcus shift+;(x3) vs \ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] UltraSimple Namespace Solution
*The Problem (as defined by Greg):*
foo.php:
?php
namespace one::step;
function two(){}
namespace one;
class step {
static function two(){}
}
?
main.php:
?php
include 'foo.php';
// is this class one::step or namespace one::step?
one::step::two();
?
*A Simpler Solution*
Force userland / general naming conventions in PHP.
# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();
thoughts, opinions, reasons why it wouldn't work?
regards,
nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 'Sanity' tally to date
Steph Fox wrote:
Please can those people who didn't already express a clear and relevant
opinion, express it now? We don't have long to play with this if there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full disambiguation
(:::) and #3 explicit disambiguation ('use namespace').
Method of tally: anything that would be acceptable to the voter gets a
point. (A weighted version is also offered here.)
D/S means 'with different separator'.
NameIssue AIssue B
==
Greg#2 (alt #3, #1)Yes
Guilherme #3 Yes
Kalle #4 Yes
Tony Bibbs #3 Yes
Jaroslav Hanslik#1 (alt #3)Yes
Nathan Rixham #4 (D/S) N/A
Liz #1 or #3 Yes
Andrei- 'agreed with Gregs approach' N/A
Janusz Lewandowski #4 Yes
Steph #3 (alt #2)Abstained
Josh Davies - '#1 and #2 are functionally the same' N/A
Hannes- put in a plea for classes only in 5.3 N/A
Lester- WROTE SOMETHING LOUD N/A
Alexey #3 Yes
Marc Boeren #1 (D/S) N/A
Derick #1 No
Vesselin Kenashkov #3 Yes
Lars#3 (alt #2)N/A
Karsten Damberkalns #1 (alt #3)Yes
Jochem Maas #2 (alt #3, #1)Yes
Richard Quadling#1 (alt #2)No
Issue A:
#1 - 8 (1 with different separator)
#2 - 5
#3 - 11
#4 - 3 (1 with different separator)
Issue A weighted (first choice gets 2 points, rest 1):
#1 - 12 + 2 = 14
#2 - 4 + 3 = 7
#3 - 12 + 5 = 17
#4 - 6 + 0 = 6
Issue B:
Yes - 11
No - 2 (see Richard's rationale tho')
Abs - 1
N/A - 7
you can add me down for a +1 on the solution to Issue B as well
- makes logical sense
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
great work - just one little note that may/may not help.. after much more thought I think you're option #2 is actually best however the choice of ::: separator in the example really confuses things and makes at an instant turn off.. I honestly think that if the option was rewritten as let's say: one::step:two() one:step::two() (or indeed any other double-char operator) then it would make a lot more sense, visually, logically and perhaps be the winner here.. Regards and thanks for the massive amount of patience :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: my last attempt at sanity with namespaces
Edmund Tam wrote: (one::step)::two(); Yes, parenthesis, just like when we want to write (1 + 2) * 3. So my question is: can parenthesis play a part in namespace resolving? see this is the problem and where the solution should be (imo) mynamespace::anotherspace::somespace makes sense class::method() makes sense it's when you join the two together that the ambiguity comes in so the solution should be some way of visually and technically defining where a namespace-path ends only solutions are: parenthesis around the namespace-path: (mynamespace::anotherspace::somespace)class::method() or a separator at the end of the namespace-path (greg's option 2) mynamespace::anotherspace::somespace:::class::method() [:::] mynamespace::anotherspace::somespace:class::method() [:] mynamespace::anotherspace::somespace class::method() [ (space)] mynamespace::anotherspace::somespace..class::method() [..] anything clear and unambiguous visually! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Steph Fox wrote: I think that pretty much disqualifies it as a solution for ns resolution in PHP, sadly. If people on this list aren't able to fully grasp the concept, it doesn't have a hope in user space. agreed; one last little push can't hurt too much though can it? (beats backtracking to ns vs packages or something ridiculous like that weg) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Steph Fox wrote: #1 and then #3. Thanks :) - Steph that is so wrong, you know 3 was better - you're not in my club :'( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Steph Fox wrote: that is so wrong, you know 3 was better - you're not in my club :'( Sorry to disappoint, but I'm collecting votes here, not making them up as I go along. - Steph twas directed at scott; an i typo'd n meant 3, and was misplaced humour - tis 2am here and I really shouldn't be on any lists or anywhere of even vague importance - apologies! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sanity tally #2
Steph Fox wrote: I was hoping to have at least 30 respondees at this stage, but actually have 29 (and that includes Hannes' abstention). However, to keep y'all up to date, here's where we're up to with Greg's proposals. Option #3 is in the lead, but that lead is still pretty fragile; there are only 3 full votes between #3 and option #1. 'Liveability' - ie whether people could live with an alternative option - is therefore becoming more important now. #4 appears to be out of the running completely, and #2 is a long way behind. If option #3 (or #1) gains a clear lead, we could get it down to two proposals (Stas' versus Greg's) rather than three in the final round. - Steph NameIssue AIssue B == Greg#2 (alt #3, #1)Yes Guilherme #3 Yes Kalle #4 Yes Tony Bibbs #3 Yes Jaroslav Hanslik#1 (alt #3)Yes Nathan Rixham* #2 (DS, alt #1 DS, #4) Yes Liz #1 or #3 Yes Andrei #2 (alt #3, #1)Yes Janusz Lewandowski* #4 (alt #3)Yes Steph #3 (alt #2)Abstained Josh Davies #2 (DS)Yes Hannes Abstained Abstained Lester #3 N/A Alexey #3 Yes Marc Boeren #1 (DS)N/A Derick #1 No Vesselin Kenashkov #3 Yes Lars* #3 (alt #1)N/A Karsten Damberkalns #1 (alt #3)Yes Jochem Maas #2 (alt #3, #1)Yes Richard Quadling#1 (alt #2)No Justin Carlson #3 N/A James Dempster #1 Yes Christian Schneider #3 N/A Ben Ramsey #3 N/A Ron Rademaker #3 N/A Luke Richards #1 Yes Stas#3 No Geoffry Sneddon #1 Yes name* = corrected/altered/clarified initial vote DS= 'with different separator' Issue A: #1 - 14 (2 with different separator) #2 - 8 (2 with different separator) #3 - 19 #4 - 3 Abs- 1 Issue A weighted (first choice gets 2 points, rest 1): #1 - 18 + 5 = 23 #2 - 10 + 3 = 13 #3 - 24 + 7 = 31 #4 - 4 + 1 = 5 Abs - 2 + 0 = 2 = 58/2 = 29 people Issue B: Yes - 17 No - 3 (see Richard and Stas' arguments) Abs - 2 N/A - 7 = 29 people just wondering if there are any cut of dates for the tally dates / rounds etc? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Garbage Collection
Evening All, Could anybody either point me to some existing documentation as to the specifics of Garbage Collection in PHP; specifically for multi-process (forked) CLI applications. Specifically when is a variable a candidate for garbage collection (the criteria); what timing can one expect to see memory freed/gc cleanup run; any way's to force or tip's n tricks in this area - basically anything to go off would be very much appreciated. Many Regards! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Kalle Sommer Nielsen wrote: Hi Like Guilherme wrote, I've spend alot of my day reading the emails and trying to understand the namespace issues and after reading your proposal I understand the issues you're bringing up. So heres my votes: Conflict between namespaced functions and static class methods: I don't think it makes much sense to be able to make a class inside a namespace with the same name as another namespace, so my +1 here goes to option #4 (disallow mixing namespaces and classes with the same name). Resolving access to internal classes: I'm a +1 for changing the resolution order. Cheers, Kalle Sommer Nielsen out of the four options I'm: +1 to (disallow mixing namespaces and classes with the same name) +5 to changing the :: namespace operator personally I like period(.) IMO ::: is visually and legibly dire you can't namespace::class:::static_method() [or change the class::static() operator at all] as that would mean every reference to a static method in a class since eternity was using the wrong operator use namespace/use class syntax seems to bloat but certainly isn't disambiguous or use something completely mad like uri scheme's for namespaces! ns://one/step/two() ns://one/step::two() [the last comment should probably be disregarded] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage Collection
Derick Rethans wrote: On Wed, 15 Oct 2008, Nathan Rixham wrote: Evening All, Could anybody either point me to some existing documentation as to the specifics of Garbage Collection in PHP; specifically for multi-process (forked) CLI applications. Specifically when is a variable a candidate for garbage collection (the criteria); what timing can one expect to see memory freed/gc cleanup run; any way's to force or tip's n tricks in this area - basically anything to go off would be very much appreciated. It implements the following algorithm: http://www.research.ibm.com/people/d/dfb/papers/Bacon03Pure.pdf With a root buffer size of 1. regards, Derick perfect thanks! :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Steph Fox wrote: I'd love to see the public reaction if we get it badly wrong. I bet that lasts much, much longer than the five minute huff over withdrawal. +10 to that there are no doubt loads of other fixes, upgrades and necessaries which people are waiting for from the release of 5.3 - they are *more important* than the implementation of namespaces. If you're still debating over which option to go for, then you don't have a perfect implementation yet; leave it out. -- OR -- *totally stupid* release two 5.3's and let the public decide; download 1: PHP 5.3 download 2: PHP 5.3 with namespaces (and indeed swap should the namespaces fail badly) regards, nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Stanislav Malyshev wrote: Hi! Surely everyone can see the very public ongoing discussions on internals@ over the course of this and last year? Surely everyone in PHP world reads internals@ and can follow all the twists and turns of all the discussion. You must be kidding. most of the frequenters of @general do -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
Arvids Godjuks wrote: 2008/9/22 Stanislav Malyshev [EMAIL PROTECTED] Hi! 3. Functions will not be allowed inside namespaces. We arrived to conclusion that they are much more trouble than they're worth, and summarily we would be better off without them. Most of the functionality could be easily achieved using static class methods, and the rest may be emulated with variable function names, etc. Comments? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php That means, that if I have a tiny, 70-100 line script and I use a package in a namespace with some global functionality - it should be 100% OOP? Sorry, but that's OOP for the sake of OOP. It's like writing Hello world! using patterns (here is an example: http://www.phppatterns.com/docs/design/hello_world_in_patterns) -1 on this. my god that's basically a PHP version of the Java Hello World weg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace Question - Simple
Hi All, Can anybody answer the following question for me please. Why not follow (exactly) Java's strong static package/namespace system rather than a home grown dynamic namespace system? It works, it's common, logical, robust, a working model to follow, and ties in well with the PHP on Java movement. Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace Question - Simple
Richard Quadling wrote:
2008/9/26 Nathan Rixham [EMAIL PROTECTED]:
Hi All,
Can anybody answer the following question for me please.
Why not follow (exactly) Java's strong static package/namespace system
rather than a home grown dynamic namespace system?
It works, it's common, logical, robust, a working model to follow, and ties
in well with the PHP on Java movement.
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From what I understand, JAVA is compiled and PHP isn't. PHP can
include namespaces/classes/etc. at run time. Whereas everything has to
be known upfront.
Richard Quadling wrote:
2008/9/26 Nathan Rixham [EMAIL PROTECTED]:
Hi All,
Can anybody answer the following question for me please.
Why not follow (exactly) Java's strong static package/namespace system
rather than a home grown dynamic namespace system?
It works, it's common, logical, robust, a working model to follow,
and ties
in well with the PHP on Java movement.
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From what I understand, JAVA is compiled and PHP isn't. PHP can
include namespaces/classes/etc. at run time. Whereas everything has to
be known upfront.
Thanks Richard, but you know what.. I asked completely the wrong
question (it would appear I as everybody else, has very strong feelings
on this); the problem/niggle here is that namespaces do not help me as a
developer in the way they should; they're a bastardisation of namespaces
to allow people to either - in fact I'm going to stop the ranting as
it's pointless.
Here's what *I* /as an OO developer/ need(?want):
?php
package com.mydom.thispackage
{
import com.anotherdom.MysqlDbHandler as DbHandlerA;
import com.somedom.DbHandler as DbHandlerB; # as makes this easier
import com.mydom.thatpackage.RssParser; # we don't have to as
import net.php.pecl.Tidy into TidySpace; # into namespace
import org.nicedom.alwaysusethese.*; # why not?
public class MyClass # visibility on classes
{
private $dba:DbHandlerA = new DbHandlerA();
private $dbb:DbHandlerB = new DbHandlerB();
protected $xmlString:String;
public function __construct( String $xml ):void #return types
{
if( TidySpace::tidy_is_xml( $xml ) ) { #namespace function call
$this-xmlString = TidySpace::tidy_repair_string( $xml );
}
}
}
}
?
think that handle's everything; encourages a fixed file hierarchy for
classes as well which would save so many headaches; additionally allows
for import instead of the pesky include/require or auto-loading.
*sorry*
php dev's if you can do the above I'll be your best friends forever.
ps: Yep I know I can avoid namespaces if I want (but can't really when
other packages I'm using haven't avoided them..) - namespaces address a
problem, which is there, and thus needs a solution, so will have to use
them :)
Regards Great Work!
Nathan
(bows out)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.3 Namespace resolution rules suggestions
Ryan Panning wrote:
Jessie Hernandez wrote:
Hi Stan,
I made a proposal and patch a few months ago...
The developers should really take a serious look at this issue or it
will come back to haunt them later. I'm not sure why no one seems
comment on your proposal and patch. It seemed like a well thought-out
and good proposal to me.
I'm also wondering what happened to the namespace declaration change to
brackets {}. I've downloaded the latest snap of 5.3 and that has not
changed as of yet.
is it too late to scrap all this and go with Java/AS3 style
base.package.class please?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions
Stanislav Malyshev wrote: is it too late to scrap all this and go with Java/AS3 style base.package.class please? Is it too late to switch to Java/AS3? ;) Already have switched front end design to flex3/as3 which is why I'm asking :o) Nath -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multi-threading
David Coallier wrote: On Wed, Feb 20, 2008 at 10:36 PM, Felipe Ribeiro [EMAIL PROTECTED] wrote: Hello, I've been reading this list for a couple of months and I have a question that might have already been discussed here before and I haven't seen, so please apologize me. My question is if there's any intent to have multi-threading support to PHP in a future version, like PHP7. I know multi-threading is an enormous source of bugs, but I think it does offer a good support for large-scale apps considering the background processes and event-driven programming, and also allowing the apps to be self-content with no needs and no dependency of external daemons like cron. I have spoken to a few people lately about this and to be honest, the opinion I get out of multi threading in php is basically no one cares doing it, no internals need it so badly that he'll implement it, and find people to maintain it Opening this thread is a good idea I think, after this I'll gather all ideas and comments and make a good post out of it. So, what's the opinion of the PHP maintainers? Regards, -- Felipe Ribeiro [EMAIL PROTECTED] http://feliperibeiro.com 83 9979-3161 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php David, hope you don't mind me asking for a bit more info, I was always under the impressions that a thread is defined as (quote wiki) Threads are a way for a program to fork (or split) itself into two or more simultaneously (or pseudo-simultaneously) running tasks. Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads of the same process share some resources while different processes do not. and php supports pcntl_fork along with signal handlers and interprocess communication via functions like or stream_socket_pair. as such if I set up a cli app with parent and child processes (?threads), then isn't this multithreading in php? I know this strictly isn't the place for such questions, but I hope you won't mind enlightening me a little on the matter. Many Regards in advance, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multi-threading
Alexey Zakhlestin wrote: On 2/21/08, Nathan Rixham [EMAIL PROTECTED] wrote: hope you don't mind me asking for a bit more info, I was always under the impressions that a thread is defined as (quote wiki) Threads are a way for a program to fork (or split) itself into two or more simultaneously (or pseudo-simultaneously) running tasks. Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads of the same process share some resources while different processes do not. and php supports pcntl_fork along with signal handlers and interprocess communication via functions like or stream_socket_pair. as such if I set up a cli app with parent and child processes (?threads), then isn't this multithreading in php? I know this strictly isn't the place for such questions, but I hope you won't mind enlightening me a little on the matter. it is not multithreading. multithreading means that a process starts several threads which work simulatenously and share local resources (such as variables, dynamically created functions/classes, database connections, etc.) pcntl_fork creates several processes, which can communicate, but still has their own sets of local resources Thankyou for taking the time to shed some light on the mater for me; I'd missed the all vital sharing resources part of the concept, probably because (if I'm correct in saying) php shares memory of variables/classes/resources between parent and child processes until a write occurs, at which point a new version of the aforementioned is created. [please correct if wrong]. Would I therefore be correct in assuming the following: In PHP we can create mutli-process(tasking) applications that have most of the benefits of multi-threaded applications and less bugs. I'm working on the premise that a processor can only run so fast, so multithreading say 100k calculations would not speed up and application, if anything it would add overhead, and slow it down. The only way to speed up such an application would be to throw more hardware at the problem (be it servers or processors). Meaning that the only time multi-process/multi-threading would have any positive bearing on an application would be when dealing with things such as external resources, due to the slower access times of these external resources we find threads/processes waiting for the resource to be usable (fully downloaded/opened) - in such a situation multi-threading has it's distinct advantages. However forking an app (?multi-process) can already achieve the same results, the only difference being that we may have a few duplicate classes/variables around the application doing it this way (subject to us not taking the time to define all shared resources in the parent process. If I'm correct in all of the above, then I'd personally think that we don't need multithreading in PHP, however a neat(er) predefined method of interprocess communication would be beneficial. Thoughts/Corrections? Regards Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Role model RFC
Lukas Kahwe Smith wrote: Hi, I really like what Stefan did here with his traits RFC. Very solid work, even if there are still some people not convinced if they want this feature in, I have seen little complaints about the way this proposal was made. Quite the contrary actually. I would like this kind of detailed thought to become more the norm. Even if at the very beginning of an idea this quality may not be immediately attainable, it should be the goal. So for every idea we should have at least someone who tries to bring the proposal to this kind of level as the discussions progress. For this proposal I would hope that it would be put on some host we can trust to not disappear and be updated with the feedback. I am still dreaming of a php.net wiki for this kind of stuff. If interested I do of course offer wiki.pooteeweet.org to host these RFC's for the time being. Using php.net/reST has the draw back of requiring cvs.php.net karma for maintenance, which would be problematic for new comers, unless we can do karma on a per file level for this? regards, Lukas What kind of traffic would the wiki attract (rough ballpark) I've got a few high spec dedicated servers, and could possibly donate one to the cause - thats if a single server would be up to the task. regards Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Chris Stockton wrote:
When I think INI I think constants. What happens when I log into some
server I have to debug some app instance and one of the first things I
might do is check the INI and I see.
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
[IF ${valuex} == 1]
setting = 1
[ELIF ${valuex} == 2]
settingx = ${valuexc?1: ${valuexcl?1:2}}
[ELSE]
[ELSE]
setting = 3
[ENDIF]
What is setting and settingx? Do I have to debug within the app with
ini_get? Or can I dump the ini values very easily somewhere, I guess
php_info() maybe?I won't deny it could be useful specially for
cross-platform cross-version INI setup, but it just won't feel like a
configuration file anymore is all. I almost think you should just
allow PHP tags lol..
-Chris
any chance of keeping this functionality out of the ini files either by:
extended config files (like apache conf's), or changing to either an
apache style conf/xml file to support if's; or indeed YAML just to jump
on the YAML bandwagon, (use it as a prototype for future php yaml support?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
0 for me -1 for all the people who'll bug the mailing lists askign where they've gone suggest: E_NOTICE or E_STRICT telling the magic_quotes_runtime has gone BUT in the next php 5.2.X release so peeps get used to it! Pierre Joye wrote: Hi, It seems that there is voices in favor of keeping the GPC related functions in HEAD/php6 but returning always FALSE. I thought the decision was already done but I rather prefer to ask the list a second time and be done with this topic (and be free to bogus any other bug reports about this problem, especially when the reporters begin to spam me and other with all possible funny words ;-) There is not really a need to discuss the removal again, that's why I ask for a simple vote: +1: remove them (as it is now in HEAD) -1: Restore them and always return FALSE (not 0) 0: I don't care, do what you wish, I never use them anyway Feel free to comment the topic but please don't start an endless discussion, we already discuss it to death two years ago (yes, two years ago :-) Thanks, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: json_encode() bug
quick work around for now..
base64_decode(json_decode(json_encode(base64_encode(ab\xE0\ something
Stanislav Malyshev wrote:
Hi!
Right now, if json_encode sees wrong UTF-8 data, it just cuts the string
in the middle, no error returned, no message produced. Example:
var_dump(json_encode(ab\xE0));
var_dump(json_encode(ab\xE0\));
Both strings get cut at ab. I think it's not a good idea to just
silently cut the data. In fact, I think it is a bug caused by this code
in ext/json/utf8_to_utf16.c:
if (c 0) {
return UTF8_END ? the_index : UTF8_ERROR;
}
which inherited this bug from code published on json.org. It should be:
if (c 0) {
return (c == UTF8_END) ? the_index : UTF8_ERROR;
}
Now this is an easy fix but would lead to bad strings silently converted
to empty strings. The question is - should we have an error there? If
so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.
Also filed as bug #43941.
Any comments?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace improvements to be committed very soon -final review
Surely the noise coming from outside are people's valid opinions? I mean
it's the people making the noise who have to live with decisions made on
the internals list, on a daily basis, and for most there income depends
on it.
It's not just php you're discussing, it's thousands of developers
working environment.. think of changes like this as somebody coming in
and cleaning your pc and files structure up for you, yeah they're trying
to help, but you had your files where you wanted them already..
No Offense and agreed on the spam issue!
Nathan
Jani Taskinen wrote:
Nice to hear some work is done but I get very annoyed every time I see
the words behind the scenes (or something alike). I guess it was
because it's impossible to discuss anything on internals without the
noise coming from outside..? Could we finally make this list read-only
for every one but the @php.net people? I get enough spam already, spam
from this list is not something everyone should suffer from.
--Jani
On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple namespaces per file
2) use ::name;
1) multiple namespaces per file
This is implemented as such:
?php
namespace one;
use Blah::A;
// code
namespace two;
use Foo::A;
?
The example above shows that imported names are reset at each namespace
declaration. There is no prohibition on this code:
?php
namespace one; {
use Blah::A;
// code
}
namespace two; {
use Foo::A;
// code
}
?
Users who wish to use brackets may do so. The performance penalty
imposed by using brackets is minor for some cases, and for users who are
following the recommended practice of 1 namespace per file, the syntax
is ideal.
Patch is:
http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
Note that non-namespaced code cannot be present in a file containing
namespaces. For users who are bundling, this will mean you will need to
create 2 files, one with non-namespaced code, and one with namespaced
code. This minor prohibition is a design decision, not a technical
problem in the implementation.
2) use ::name
This code:
?php
namespace Whatever;
use MDB2; // import PEAR's ::MDB2 from global scope
$a = MDB2::connect();
?
is currently impossible, which will make namespacing old code harder.
The patch introduces this new syntax to import names from the global
namespace:
?php
use ::MDB2, ::strlen as len;
?
http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
These patches are for review of both serious technical and serious
implementation issues. In order to help move things along, I'd like to
define serious as something directly related to the implementation
that would cause a failure in PHP's ability to run scripts
deterministically, or some kind of memory leak/crash.
commit is planned for the next 24 hours or so, but of course any issues
found in review can be fixed. The patches are short, so in the worst
case, reverting is not difficult.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespaces Extends?
Hate to bring this one up; I'll be brief!
for instance smarty get's upgraded and has it's own namespace, I have a
class which extends it, soon to be in my applications namespace which
implements an interface in my interfaces namespace.. how does one extend
a class in another namespace and indeed implement?
namespace application::handlers;
{
class class_name extends ::b::class_in_other_namespace implements
::c::iTemplate{
public func...
}
}
or would we..
namespace application::handlers;
{
use b::class_in_other_namespace as other_class;
use c::interface_in_other_namespace as other_interface;
class class_name extends other_class implements other_interface {
public func...
}
}
or..?
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Namespace access modifiers
Would this not do the same thing and perhaps be easier to implement:
namespace Foo;
protected $var;
class Bar {
}
thus allowing use of private public protected before variables, and hell
why not classes aswell.
private = only methods, code, classes in namespace Foo have access
protected = only methods, code, classes in namespace Foo or children
Foo::Too have access
public = everybody
the same inheritance rules etc as classes.. makes sence :) and great idea!
got my vote, especially with the braces in namespaces!
namespace Foo; {
protected $var;
public class Extender {
public function __construct() {
..
}
}
}
Nathan
Ralph Schindler wrote:
Since everyone is in the namespace frame of mind, is there a
possibility of a namespace access modifier?
The way I envision this working is that if for example:
namespace Foo;
class Bar {
nsprotected $_someProperty = null;
}
(or some other equivalent grammer)
Would allow the property Foo::Bar::$_someProperty to be accessed from
any class that has implemented a class from the Foo namespace.
Reaching for straws or is this a possibility?
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Sorry to intrude on this one! It seems that some real hard work has gone into this, and a big thanks from the community for all your hard work. Can the gc patch feasibly be improved any more? If so surely the time scales involved with improving further would mean it'd miss the boat for a 5.3.x release..? Real-life use of PHP has to be the foremost concideration; in the production environment, especially on server farms and shared hosts, how many of them are going to be upgraded to 5.3 anyways, and when so, not for a long time (sadly)! 4 bytes vs the earlier 12 bytes is a significant improvement, and much as this may seem a terrible thing to say.. Roll it out in 5.3, turned on by default (with option to disable at compile time) - that's your test right there, if there are problems then have it disabled by default in the subsequent minor release. My only (and major) concern as an end developer is the 5% slowdown and 3% memory overhead, exactly what benefit am I as an end developer going recieve for this? Andi started this series with : On one hand I think now the effort has been made it's a good thing to offer it as part of PHP; and I for one agree, with the emphasis on *offer*. Many Regards Apologies for the intrusion. Nathan Andi Gutmans wrote: Hi Ilia, I suggest more people test the performance difference because as you can see for us it was negligible. From my experience you see bigger deviations just by moving kernels, compilers, and even small patches which affect where in memory the code segments sit, etc... Maybe some people here who have performance harnesses (I'm sure Yahoo! has one) could test it too. Andi -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Saturday, December 08, 2007 9:35 AM To: [EMAIL PROTECTED] Cc: Rasmus Lerdorf; Stas Malyshev; [EMAIL PROTECTED]; 'Antony Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Richard, zval is such a common PHP structure that in a scope of a single script (even a trivial one) you'd have thousands of them. Therefor even an extra 4 bytes matter, and for people with large application it would matter even more. I wish the patch was such that it had no impact on the people who don't need it, but the reality is that for anyone who does not need gc cycles, it'll be a performance (speed memory) penalty. This is why I had intimately suggested making it a compile time, configuration option. On 7-Dec-07, at 9:25 PM, Richard Lynch wrote: On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: 1. Always compile it in but leave undocumented #ifdefs in place for performance freaks. Those same performance freaks aren't going to care about the binary compatibility issue since they are the same people who build all their own stuff. Note that breaking BC is not only about performance - one your build is not the same as mainstream PHP, you can't use any binary extension which would do anything non-performance-related - like interfacing some external system/library, debugging, profiling, testing, security and so on. Any commercial module won't be available for the user of this switch, and all open-source modules one'd have to build by oneself, which may be serious maintenance issue. I know there are a bunch of companies that compile PHP with their own options but still use commercial modules, including both performance and non-performance ones. They couldn't use this compile switch. Yes, I know what binary compatibility means. Call me crazy, but... Would it be possible to hard-code the bit that adds the 4 bytes to the zval, but make the execution bit a flag so that binary compatibility is always there, but the executable code that does the GC can come or go as needed?... Or am I just talking nonsense due to ignorance? -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Thoughts on Feature Request - Arithmetic
In-Built PHP Functions for parsing of basic arithmetic and if possible fraction to decimal and decimal to fraction $arithmetic_string = 3*5; echo arith($arithmetic_string); // returns float 15 $arithmetic_string = 1/2; echo arith($arithmetic_string); // returns float 0.5 $fraction_string = 1/4; echo fracdec($fraction_string); // returns float 0.25 $dec_string = 0.5; echo decfrac($dec_string); // returns string 1/4 I've used php for years, came accross the need for this today and was suprised such a basic command wasn't there.. currently the only way I can see to do it would be to eval.. which isn't the most secure method for such a basic need. Regards Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
Roman Borschel wrote: I don't agree with that. I think multiple namespaces per file would be fine with the current syntax as this is a feature that would not be used by that many people and if it's used it's not for development purposes (who wants to read a class bundle with no comments, linebreaks etc.?) and therefore the readability/consistency doesn't matter much. It's not that I don't like braces but imho its not a necessity to move to braces just to allow multiple namespaces in a file. Roman On Dec 6, 2007, at 1:34 PM, David Zülke wrote: Am 06.12.2007 um 04:22 schrieb Jeremy Privett: I know I just finished praising you just some hours ago, Stas, but I'm going to have to step in and agree with Larry on this one. It really doesn't make sense for there to be no braces for namespaces (especially if you're going to allow multiple per file). A namespace is a logical grouping of classes/functions and other constructs of this type in PHP use braces. That is very confusing syntax when compared to other areas of the language. +1. If we allow multiple namespaces per file, then braces are an absolute must for consistency IMO. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 1: Braces 2: No Braces 3: Either If this was a question of braces or no braces, then there would be no competition; braces would win hands down. Thus I'd move that it should be taken for granted that braces will be there, and move on to debating whether they be optional or not.. Thoughts? Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
Agreed, PECL or PEAR, some provision should be made, it's worth the extra few bytes of code. Thanks for the opinions Nathan Antony Dovgal wrote: On 07.12.2007 18:05, Alexey Zakhlestin wrote: I doubt this is needed in core, but sounds ok for an extension. Yes, I'm sure a simple extension using re2c to parse the expressions would be gladly accepted into PECL. I don't see any need for this in the core, though. Also, I believe, quite a decent version of this can be written in php (think PEAR) This could be an option either. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] expansion of proc_open fwrite and stream_*
proc_open() pipes: when stdout and stderr are set to file no resource pointers are returned in the pipes array when using fwrite on a pipe to stdin (from proc_open()) fflush() does not work, neither does stream_set_write_buffer(); regardless of whether stdout/stderr are mapped to pipes or files, infact in all my tests I cannot get php to return anything through stdout or stderr until fclose on stdin has occured, even then support for stream_get_meta_data seems to be distinctly lacking. Perhaps there is a method I am missing however support for multiple process read/writes seems a little lacking (impossible?), and in my opinion should/could be expanded. Suggestions/Thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
I've thought about this for the remainder of the day, and I can't see any good reason why this functionality should not be implemented into the core; it's basic fucntionality, a safe way of doing things and couldn't take more than a day or two to add in from a single developer, and surely it'd be no more than a couple of kb's worth compiled, if that! Also, it's a bit of minor piece of functionality to warrent a PECL/PEAR Extension, and even more hassle for somebody to reasearch, find and download it - all to do some basic arithmetic. Can anybody give me an argument as to why this functionality should not be incorporated into the core? Many Regards Nathan Rixham Alexey Zakhlestin wrote: On 12/7/07, Mike [EMAIL PROTECTED] wrote: Yes, an easy way to handle this functionality that is safe to use with user input would be REALLY nice. Specifically for allowing users to specify custom formulas to do all sorts of nifty stuff. Especially in reporting and payroll/commission applications. We're currently working on a reporting class where we would like the user to able to specify custom columns in XML, ie: $col5 = ($col1 / $col2) * ($col3 / $col4) Or in our payroll application where customers want to calculate custom commissions for sales people: $commission = ($gross_sales - $gross_pay - $medical_benefits - $chargebacks) * $employee_commission_bracket In this case, you might find embedding usable… http://pecl.php.net/package/lua http://pecl.php.net/package/python http://pecl.php.net/package/perl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
Daniel and Derick, thanks for the replies.. Daniel first.. ?=3 * 5;? is great :) however $arithmetic_string = 3*5; $arithmetic_value = arith($arithmetic_string); not possible with the method you mentioned. eval() yes this works, however personally I feel a simple arith() (or more suitably named function) would be a great deal quicker and safer than eval($_POST['sum']), the security dangers are somewhat obvious. ps: I must point out that I've still never had a use for this and never would (perhaps the fraction??), but somebody over on a dev forum does, and I was quite suprised this functionality wasn't included! :P Nathan Daniel Brown wrote: On Dec 7, 2007 9:51 AM, Nathan Rixham [EMAIL PROTECTED] wrote: In-Built PHP Functions for parsing of basic arithmetic and if possible fraction to decimal and decimal to fraction PHP already handles half of what you're looking for by default. $arithmetic_string = 3*5; echo arith($arithmetic_string); // returns float 15 ?=3 * 5;? $arithmetic_string = 1/2; echo arith($arithmetic_string); // returns float 0.5 ?=1 / 2;? $fraction_string = 1/4; echo fracdec($fraction_string); // returns float 0.25 ?=1 / 4; ? $dec_string = 0.5; echo decfrac($dec_string); // returns string 1/4 Now I see why you need PHP to do your math for you! ;-P There are functions written that do this now though. I've used php for years, came accross the need for this today and was suprised such a basic command wasn't there.. currently the only way I can see to do it would be to eval.. which isn't the most secure method for such a basic need. Regards Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
