Re: [PHP-DEV] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 3:52 AM, Ilia Alshanetsky i...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1
Re: [PHP-DEV] Re: Quick question about closing PHP tags
On Wed, Feb 4, 2009 at 12:03 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: Hi all. My 2 cents. 1). Major IDE have an option - trim trailing spaces. Atleast ZDE does, i'm using it and I have no problems with spaces (although I tend to use only ?php and don't put ? at the end of file) 2). Extension is really a bad idea because many frameworks tend to use .inc extension for included files. My applications have only one file with .php extension - that's index.php. 3). BOM is a pain, but really parser could just trim it out if it's present. As for me, I use Unicode without BOM (ZDE doesn't place BOM, Visual Studio has an encoding named UTF-8 (without BOM). Most editors also deal with this issue in similar manner, so just see the settings. So, leave it as is. Better spend time on learning PHP, MySQL and related techologies than think about such unimportant and mostly silly things. Arvid. The core idea was *only* to do this if it actually helps speed up things. I am pretty sure than php 5.3++ properly ignore the document's BOM. Of maybe it was meant for 6? Not sure need to test this. G. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] search string problem with special characters in php 4.4.7
On Wed, Jan 28, 2009 at 4:52 PM, Alpár Török torokal...@gmail.com wrote: 2009/1/28 Bipul Agarwal bi...@aphroecs.com Hi all, I have a search string which works just fine with php 4.4.9 and my local host but some how its not working with php version 4.4.7. Search is for a Swedish name with special characters like - åre - I am able to display these characters properly on the browser. the only problem is with searching keywords with special characters like above from the database. In php version 4.4.9 if we search for - åre - we get around 26 records which is correct. but when we search the same in php version 4.4.7 (with same coding and same database) it retracts over 11,000 records - which is not correct. Database version for both servers is - MySQL client version: 5.0.51a I have a deadline tomorrow and wonder if you could please help me out? the problem could be because of php versions or it has to be in my codes? Thanks in advance, Bipul I think your problem is Db related. Try cross testing the databases with the different PHP versions, to make sure where the problem is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alpar Torok Most likely there is something different on your mysql server configurations and most probably that something is charset and/or collation related... Check what set names can do for you. G.
Re: [PHP-DEV] __getStatic
On Sun, Oct 19, 2008 at 3:01 PM, Timm Friebe the...@thekid.de wrote: Hi, First of all, thanks for reviewing and the feedback. I knew this wasn't perfect, and tried to understand what was previously done for __get and __set and transport that to the static counterparts. Unfortunately not all infrastructure like the std_*_property_handler callbacks is in place for static properties so this had to be created, too. Lukas writes: hmm .. i also emailed Timm a few weeks ago and got no reaction. the question now is .. does someone else care enough to work through the issues Stas has noted to get things in shape to be committed? I've been quite busy with personell and budget planning at our company and have thus had neither time yet to shift through my private e-mail nor to do any programming, be it for private projects or for PHP. I was hoping someone else might pick up on this patch and try to complete it, it's been asked for a couple of times in different forums / newsgroups / this list (a Google search reveals these). On the other hand, there's only one really good use-case that pops to my mind for __getStatic(), and maybe the type-safe object properties pattern Sebastian (Bergmann) had in his blog may be another one, but nothing people would care enough for (especially once compared to the feelings around namespaces), so that's probably why this hasn't happened!:-) Stas writes: This patch is definitely not ready, so I'd wait with it unless we get really good one very-very soon. I guess very-very soon is already over, and yes, absolutely, this patch is far from perfection, so I'd also delay it. Maybe someone (Lars from http://wiki.php.net/rfc/static-classes?) might also want to gather some motivation for the __*Static() methods as in good use cases... - Timm Any news on this? :) I don't see this in 5.3 but are there any hopes for pushing this on the HEAD of 6 sometime soon? :)
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 9:14 PM, Lukas Kahwe Smith [EMAIL PROTECTED]wrote:
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all of the
above topics have been discussed quite a lot on the list. So I hope voters
can spare the list needless repetition. Instead if you think that a topic
needs to be discussed, put a short note in your vote under the given topic.
If a number of people also think the topic needs more discussion, then we
can open a new thread dedicated to this topic later this week.
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 +1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
a
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
-1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1 +1
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
b
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mixin RFC
Personally I think that traits is a lot safer than mixing classes.There will
be a lot of things that will need to be considered in order to make it
logical for developers to use.
Quote from the RFC:
Any method or property that already exists in the class or parent/extended
class cannot be changed unless using class_mixin() see below.
I'm pretty sure this is against all beliefs in the php world.
Runtime merging of classes and overriding methods is a no-no for me.
Traits seems much more safe since you cannot initialize a trait and can only
used to flatter other classes.
The proposed way of mixins will create confusion when trying to continue
development on an ongoing project and will need A LOT of extra documentation
just for explaining the hierarchy of the mixed classes.
A very simple case of mixins for php (that allready is implemented) can be
seen in Advogato: Mixins for php.
It has the following example.
***
class Person {
var $job = person;
function show_job() {
echo Hi, I work as a {$this-job}.;
}
}
class Bartender {
var $job = bartender;
function show_job() {
echo BARTENDER: ;
Person::show_job();
}
}
$b = new Bartender;
$b-show_job();
**
If you look at the example you can see that the Bartender class does NOT
extend the Person class, but when using Person::show_job(); the person's
method have access to the $b object's variables as if the bartender class
extended the person class.
IMO this is the safest way we can use mixins without getting into the
troubles of creating too many (complicated) ways to do the same thing.
G.
On Thu, Sep 11, 2008 at 7:07 AM, Edward Z. Yang
[EMAIL PROTECTED] wrote:
Jonathan Bond-Caron wrote:
http://wiki.php.net/rfc/mixin
It seems to me that class_mixin() is a bad idea for the core; it's more
of a runkit type functionality than traits. After all, we don't allow
dynamic inheritance, or dynamic interfaces...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __getStatic
I thought this had allready been denied, or am I wrong? Also can new features still be implemented for 5.3? Isn't that closed? Don't get me wrong, I SO want this feature! :P G. On Wed, Aug 20, 2008 at 7:39 PM, Lukas Kahwe Smith [EMAIL PROTECTED]wrote: On 15.08.2008, at 12:06, Marcus Boerger wrote: Hello Timm, Friday, August 15, 2008, 12:44:19 AM, you wrote: Hi again, Attached you'll find an incomplete patch against PHP_5_3 to add this functionality. If you like it let me know and I can finish it. Darn, seems the list didn't like my text/plain attachment. Well, here we go: http://sitten-polizei.de/php/get-static.diff Patch looks pretty good. Plaease add __issetStatic and __unsetStatic. Then provide tests and submit to HEAD. For 5.3 Lukas and Johannes have to agree but I am sure they first want to see it in HEAD. Hope we havent missed any other we need to make this stuff complete .. But here is the blessing of the two RM's to have this committed before the alpha2 release .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __getStatic
I am pretty sure that it's most common (and weirdest) use will be to have some kind of custom superglobals that will piss a lot of people off. Easier registry patterns etc. registry::$name = 'test'; echo registry::$name; Sounds stupid but since custom superglobals have been denied it's the next best thing ;) G. On Fri, Aug 22, 2008 at 9:32 PM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Fri, Aug 22, 2008 at 15:06, David Zülke [EMAIL PROTECTED] wrote: Am 22.08.2008 um 14:08 schrieb George Antoniadis: I thought this had allready been denied, or am I wrong? Also can new features still be implemented for 5.3? Isn't that closed? Don't get me wrong, I SO want this feature! :P The mail below explicitly states that both release managers have given their okay for implementing any missing __magicStatic() methods... read the mail again! Well... I actually thought this was rejected too until Marcus came out of the blue and then Lukas giving the RMs blessing.. I can't find a single usecase for this, and see absolutely no point with it and hardly consider this making this [__call/__get/__isset magic] complete. However, I could not care less of it gets in or not. -Hannes
Re: [PHP-DEV] Traits for PHP Revisited?
+1 from me too please ;)
Indeed the proposed RFC for traits is a wonderfull thing for things we
currently do using mixins.
What's goining on with traits anyway? Has it been decided if it's gonna be
implemented in 5.3, 6.0, 7.2 or never? :)
G.
On Sat, Jul 26, 2008 at 6:27 AM, Andru Vallance [EMAIL PROTECTED]wrote:
Hi
I just want to add a big +1 from an end user perspective for traits.
I know from my perspective this would be an incredibly valuable tool for
php. I'm essentially already using the functionality this brings (as I'm
sure many other devs are), albeit in an ugly way - either adding
functionality to a single superclass at the bottom of the class heirarchy,
or using interfaces along with composites/delegation, which means a lot of
unnecessary code duplication.
I've been reading through the threads on the subject -- I'm not sure if
discussion has died because of pressure to get 5.3 out of the door, or for
other reasons, but it seems the conversation stopped without any real
resolution, and the wiki seems to be in a similar state.
It's a great idea in principle, but I've noticed a lot of discussion is
focused on preventing collisions by ignoring/aliasing methods. Maybe I'm
misunderstanding the usage case for traits here, but I envision them as
working interfaces. The methods of a trait surely shouldn't change
visibiliy/name depending on which class they appear in? Doesn't that defeat
the whole point?
Regarding collisions, If I try to do the following...
interface i1{ public function foo(); }
interface i2{ protected function foo($a,$b); }
interface i3{ public function foo($a,$b,$c,$d); }
class Broken implements i1,i2,i3{ private function foo($a) }
I wouldn't expect it to work! It's the developer's job to know the
interface they're implementing. Similarly isn't it the developer's job to
know the methods in a trait, and manage any collisions directly in their
code, not in statements for php to process and include/exclude/alias things?
Moreover, surely it's the developer's responsibility to use verbose method
names (eg 'saveOrder', not 'save'), in the knowledge that the code will be
inherited by a class in which his 'save' method would no longer have any
context, and is likely to collide with existing methods of that class...
My use scenario for a trait would basically be a functional interface...
Since most of the code so far in the discussion on traits has been all foo's
and bar's, I'd like to present a few real-life examples that I think show
the potential use of traits while still keeping the code compact...
trait Optionable{
protected $_options;
protected function _setOptions($options){
$this-_mergeArrays($this-_options,$options) }
public function getOptions(){ return $this-_options; }
private function _mergeArrays($ar1,$ar2){ }
}
trait Hookable{
private static $registry;
public static function registerHook($type,$object){
self::$registry['...etc...'] } //if methods are copied, I guess it'd have to
be Hookable::$registry
protected function _runActionHooks($data){}
protected function _runFilterHooks($data){}
}
class Something is Optionable, Hookable{
//$_options is a protected property of Optionable, so I expect to
inherit or have a copy...
//$registry is private so I don't expect to see it here
public function __construct($data,$options){
//the following methods are all protected, so I'd expect to
inherit or have them copied with the same visibility
$this-_setOptions($options);
$this-_runActionHooks($data);
$data = $this-_runFilterHooks($data);
}
}
I know this basically resembles multiple inheritance (please don't cry)...
I think the important distinction is firstly one of use - the keyword
distinction between class and 'trait' should be used to encourage short,
reusable bits of code, where multiple inheritance and the sloppy behaviour
that comes with it is not a problem. Secondly, to prevent it becoming
multiple-inheritance-by-another-name I don't believe traits should be able
to inherit from other traits.
I've read through every message on this subject and I still don't see the
benefit being added by all the complexity of adding loads of extra reserved
words complex include/exclude/alias logic for something which should
surely be a simple fix to a simple problem?
If I'm being naiive and totally missing something, please let me know!
Andru
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Php 5.3 Snap - Lambda functions and $this scope
This is based on a bug submitted at http://bugs.php.net/bug.php?id=45604
Description:
When creating a normal function inside a class and calling it, the
function doesn't have access to $this.
Fatal error: Using $this when not in object context
When creating a lambda function inside a class, $this is visible from
the new function's scope and can be accessed normally.
Wouldn't it be better (and maybe safer) to allow the use of $this as a
closure instead of passing it to the new lambda function?
Currently trying to use $this as a closure dies with a Fatal error:
Cannot use $this as lexical variable error.
Example for the suggestion.
$x = function () use ($this) { return $this-hello; };
Reproduce code:
---
?php
class something
{
public $hello = 'Hello world!';
public function world()
{
$x = function () { return $this-hello; };
return $x();
}
}
$s = new something();
echo $s-world();
?
Expected result:
Not to be able to use $this.
