Re: [PHP-DEV] function call chaining
Op 1/19/10 1:27 AM, Stanislav Malyshev schreef:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if foo() returns callable value (which probably
> should be function name or closure) then it would be called. Parameters
> and more than two sets of () work too.
> Of course, this is mostly useful for doing closures, and that was
> primary drive for implementing it - to make working with closures and
> especially function returning closures easier.
> What does not work currently is $foo->bar()() - since it is surprisingly
> hard to tell parser it's not {$foo->bar}()() - which of course is not
> what I want to do.
>
> The patch is here: http://random-bits-of.info/funcfunc.diff
>
> What do you think? If somebody has better idea btw - maybe make
> something like {foo()}() - and make that work for any expression inside
> {} - that might work too. So, what do you think?
cool as ice! :-)
I do worry how many painful edge cases this throw up and
additionally how many beginner coders with a bit of JS experience would
continuely
complain/moan/question why PHP didn't work they [think] JS works, for instance
the
classic JS closure-type tricks, e.g.:
doIt = function(a, b) { return function() { return b(a);} }
func = (function() { var bar = ''; return function(foo) { doIt(foo,
bar)(); } })();
document.write(func(function(a) { return a + '-fooey'; }));
it's quite obvious how easy it is to make javascript code very difficult to
follow,
personally I love it, but using it sensibly requires alot of care and attention,
it's worth considering whether giving PHPer another very powerful gun is wise
choice ... especially given how often they/we/(me!) put holes in feet.
I can imagine you'd be opening yourself up for sleepless night and lots of
unwarranted abuse for having offered a new bit of greatness.
given that Closures are still in their relative infancy (mostly in the context
of
production use) and the fact that this is liable to still of itself be in flux,
and additionally the mountain of work/details (AFAIKT) required for PHP6, that,
maybe,
such functionality should be put on the backburner for now. at some stage all
the new stuff
(most notably Closures) will stabalize to such a degree that it would become
more
manageable to introduce such a thing.
just my 2 cents.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can we call Apache 2 API function from a PHP 5 extension module?
please ignore this if any of the following apply:
1. you name is 'mm w' (I don't care for your response either) - granted this is
reverse psychology.
2. your very busy atm (nothing technical being added here)
3. you abhor off-topic junk
otherwise the following may help to make you smile ...
to start with, let me say that I'm just a lowly php dev who very much
appreciates
being able to follow discussions on the internals list, it's helped & taught me
much
about the tools I use and programming in general. the fact that I'm allow to
occasionally
interject my own questions and comments and that, more often than not, busy
talented people
take the time to offer serious and well thought out replies is a privelege I
value very much.
secondly a 'hat's off' to all of you who are responsible for giving us php, I
personally owe so much to all of you and I know many of my friends, colleagues
and
aquaintances feel the same way. I will not mention names because I'll miss out
too many,
but to all of you: Thank You!
@Brian: your kids look really happy, regardless of anything else that's
probably the best CV a man could have!
now it's time to rip someone a new ***, please forgive me my compulsion :/
I promise not to reply to this thread if the troll decides to take another bite.
Op 1/17/10 7:35 AM, mm w schreef:
> yep nevermind I don't you post this question on php-internal and don't
> understand this ugly suggestion, Brian when I read your cv it seems to
> be something serious ... when I see the line with your type recasting
> I am not sure you understood something during these 15 years.
who the f*** do you think you are? your incessant trolling and abuse offers
absolutely nothing constructive to the community or technology of the php
ecosystem.
I'm very sure you're an absolute coding wizard, but why is it, given that your
so skilled in various programming langauge, that you can't find the time to
learn even
the most basic english language skills before offering your unwanted, useless,
negative and
totally incomprehensible opinions to this list.
you're an idiot with an axe to grind, who openly admits that he like's to
troll, a quick google
gives the following example:
http://php.general.free-usenet.eu/PHP-GURU-NEEDED_T31382161_S2
which is somewhat hilarious or depressing depending on your current state of
mind,
either way you're still an idiot.
here are some simple tips in english an 8 year would understand:
1. look up the word 'Meritocracy' and learn what it means.
2. use your skills to add something to the project rather than abuse people
(see point 1).
3. learn to write english that other people understand.
failing your ability to do any of those, please ... go crawl back into the dark
hole from whence you came ... and stay there until such time that you figure out
how to play nice with the other kids.
> Best
PS - 'Best' is not a 'sign off' by any stretch of the imagination. as a concept
it obviously
doesn't apply to you and in the context you use it, it is totally meaningless.
PPS - before you attempt to reply and critise me for hypocracy let me just come
right out and
admit it. I'm a hypocritic. there, I said, no need for you to take the time to
accuse me :)
PPPS - I'm sure that googling me will bring up a number of examples of my own
online stupidity, as such just refer to the PPS and move on.
S - your wife must have done something really bad in a previous life to
deserve you.
PS - if you feel the need to mention my wife, tough, there isn't one, my
girlfriend left me
(but at least she still invites me over for dinner) ... and as such, again,
please refer to the
PPS and move on.
boy, was that as good for you as it was for me?
> On Sat, Jan 16, 2010 at 10:05 PM, Brian J. France
> wrote:
>> Try this instead:
>>
>> request_rec *r = (request_rec *)(((SG(server_context) == NULL) ? NULL :
>> ((php_struct*)SG(server_context))->r));
>>
>> Apache 2.x server_context is not a request_rec, it is a struct with a
>> request rec in it.
>>
>> Brian
>>
>>
>> On Jan 16, 2010, at 7:25 PM, rwe rt wrote:
>>
>>> Hi all,I compiled php-5.3.1 with apache 2.2.14 as DSO and wanted to test
>>> how to call Apache API from a PHP module:Run ./ext_skel
>>> --extname=helloModified ext/hello.c and the function
>>> PHP_FUNCTION(confirm_hello_compiled) so that it contains
>>>
>>> #include "SAPI.h"
>>> #include "httpd.h"
>>> #include "http_config.h"
>>> #include "http_protocol.h"
>>> #include "ap_config.h"
>>> request_rec *hello_r;PHP_FUNCTION(confirm_hello_compiled) { hello_r =
>>> (request_rec *)SG(server_context); ap_rprintf(hello_r, "Hello world\n");
>>> return SUCCESS;
>>> }Under php root, run ./buildconf and ./configure
>>> --with-apxs=/home/www/bin/apxs --enable-helloIt worked fine. But when I
>>> furhter ran:
>>>
>>> makeI got an error like:ext/hello/.libs/hello.o: In function
>>> zif_confirm_hello_compiled': /home/www/php-5.3.1/ext/hello/hello.c:167:
>
Re: [PHP-DEV] Upgrading to internal DateTime
hi Derick,
Derick Rethans schreef:
> On Fri, 5 Dec 2008, Lester Caine wrote:
>
...
>> Second question.
>> What is the current situation on translating dates? I've tried several ways
>> of
>> using setlocale, but at present I've not been able to get anything other than
>> English out of the code.
>
> setlocale() is the only real solution right now. What most likely is
> your problem is that you don't have the locales for the other languages
> installed.
>
... leaving aside timezone issues (they make my head hurt, kudos to you
for having written that stuff!).
according to my testing DateTime ignores the current locale completely ...
there seems to be no way of cleanly extracting a locale formatted datetime
string from a DateTime object ... there is not even a way to retrieve a
unix timestamp from said object in order to pass it to strftime() or to
an instance of IntlDateFormatter (which doesn't seem to accept a DateTime
object as argument to the format() method.
so the only way I can see of doing it is as follows:
format("U")), "\n";
echo $d->format("D, F Y"), "\n";
?>
which gives me the following on my local machine:
vrijdag, 05 december 2008
Fri, December 2008
having to use format("U") ?> seems wrong, having
something like getTimeStamp() ?> would seem better.
Am I missing something? or is there actually a limitation in DateTime
that should/will be addressed at some time in the future? personally
I just looking to understand ... here's hoping you may be able to
shed some light on the matter.
rgds,
Jochem
--
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
Greg Beaver schreef: > Hi, > > http://wiki.php.net/rfc/namespaceissues > > Read it and discuss. Let's be clear people: the technical problems in > namespaces are limited and solvable. The problems in the political > environment surrounding them may not be. Wouldn't politics be a > stupid-ass reason to remove namespaces? well quite (although removal seems to me better than releasing without tackling the technical issues [those you documented in your latest RFC] ... but that's just me). so far as my +1 - I give my vote to Greg's preferred solution(s) (Greg get to vote with a +2 :-) ... I don't say this lightly, I've been convinced on-list and off- by detailed arguments and stacks of example code that Greg really has thought this through more than anyone else and what he offers is better than anything anybody else has brought to the table (regarding the issues highlighted in his last RFC) rgds, Jochem > > Greg > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Andi Gutmans schreef: >> -Original Message- >> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, October 14, 2008 2:15 PM >> To: Steph Fox >> Cc: Stas Malyshev; PHP internals >> Subject: Re: [PHP-DEV] namespaces and alpha3 >> >> err .. you misunderstood me .. Dmitry wasnt happy with his approach .. >> last I heard Greg also stopped exploring his alternative approaches. >> so dont hold you breath. > > As I said, I talked to Dmitry today and he was OK with it. > I do think there's also a good chance to make progress with Greg. I'd like to reiterate that I gave a +1 on posponing till 6.0. If it turns out that some form of the latest proposal (by Stas) get's an OK from Greg then I'd change my vote (for what it's worth) to align with Greg's ... I followed Greg's analysis and proposed solutions very closely, if he end's up giving an OK to some form of Stas' latest proposal then that would likely indicate a situation/feature that is really worth releasing. basically: if Greg gives a 'thumbs up' all the nay-sayers should take note! he was probably the biggest nay-sayer and he did his homework more thoroughly than just about anyone else I've come accross. > I suggest to give it a couple of more days. In any case, as I said, the > real issues that are being discussed are mostly marginal and I think a > broader alpha/beta when the time comes will help get the necessary > feedback from people who really play around with it and/or bring up > other issues. > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Steph Fox schreef: >>> > On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote: >>> > >>> > 1) rip them out +1 ... I concur with Steph's opinion >>> > >>> > I'm +1 on this. We simply don't have consensus, and I don't see >>> anyway > we >>> > can have consensus by the time 5.3 has to be frozen. Once >>> namespaces > are in, >>> > we're gonna have to stick with whatever we choose, unless we >>> totally > break >>> > BC. >>> >>> I'd agree with this, leave something with such a big impact to >>> version 6. At >>> least it gives time to get it right. >> >> I don't agree to this, many of us are waiting for namespaces and have >> starting to impact some code in prevision. >> >> Don't forget that an annoucement has been done on php.net and a final >> release of 5.3 without namespaces could be interpreded as a regression. > > I'm +1 on ripping out and leaving til 6.0. I don't think there is enough > time between now and the 5.3.0 code freeze to make major changes to the > language syntax. Making -> do double duty and adding E_STRICT messages > to currently legal code really doesn't look like a good option to me, > much less during a point release and even less during the final moments > of a release cycle. Leaving as-is, we already know is problematic. > There's no consensus to pull support for functions/constants, which > would make it less problematic. > > 'An announcement has been done on php.net' simply isn't a good enough > reason to screw up the language; we can write new announcements and even > explanations. And we already have *most* of a working implementation in > 6.0, so it's not like ripping it out of 5.3 means starting over from > scratch. > > - Steph > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_firebird
Pierre Joye schreef: > Hi > > On Tue, Oct 14, 2008 at 12:52 AM, Jochem Maas <[EMAIL PROTECTED]> wrote: >> Lukas Kahwe Smith schreef: >>> On 07.10.2008, at 20:18, Lester Caine wrote: >>> >>>> What is the correct procedure to create a new driver, or rather clone >>>> the existing php_interbase so that we can build a proper Firebird >>>> version that actually uses the fbclient.dll rather than sharing the >>>> now incompatible GDS32.DLL client. Some people are starting to use >>>> Interbase in parallel with Firebird, but the driver can only access >>>> one client :( >> not that I give a about the windows interbase/firebird extension .. but >> .. > > When will you (all) understand that it is not only a windows problem? > The fact that windows is likely to do not have it in 5.3 is only a > side effect of the lack of developers around this extension (zero > developer). And seriously, comments like that do not have their place > in this list. true enough, my apologies. > I could say the same about firebird and simply keep away > from the windows releases and let the firebird users deal with that. > >> I do use firebird and all this talk of dropping firebird support is kind of >> scary >> (well really scary actually) ... I am able to configure php with >> '--with-interbase' >> in 5.3alpha2 so I guess I don't need to worry. > > We are not talking about abandon it but moving out of core. Please > note that it will not happen tomorrow (5.3). But if nothing changes, I > do not see how this extension could remain in core without > maintainers, but that's not something I can decide on my own or for > 5.3 :) understood. my skills are not such that I could take on the responsibility, I would if I could ... as such I can only continue to study until some of C start to 'stick' > I find amazing that so many users are scary about loosing firebird in > core (they can always install it via pecl then) but I do not see too > much love around it (unit tests, bugs reports, patches, attempt to > contact the firebird developers, etc.). understood. I personally have no problem with grabbing it from pecl instead of it being bundled if that's the way it ends up going. >> effectively the extension for firebird already exists ... it just maps to >> the interbase >> function, if the fbird_*() aliases were removed and renamed copies the >> ibase_*() >> extensions functions created that then were built against the firebird >> client iso >> the interbase client you'd pretty much be there. technically the [firebird] >> extension >> would be new but is that really a deal breaker given that the complete API >> (fbird_*()) >> already exists? > > I do not understand this paragraph. um, I don't think I can explain it any better, probably I'm just on the wrong track anyway. I'm going to look at the phpt tests for interbase/firebird and see if I can add something useful. @Lester: fancy giving me a run down of problems/issues/whatevers related to php+firebird offlist? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_firebird
Lukas Kahwe Smith schreef: > > On 07.10.2008, at 20:18, Lester Caine wrote: > >> What is the correct procedure to create a new driver, or rather clone >> the existing php_interbase so that we can build a proper Firebird >> version that actually uses the fbclient.dll rather than sharing the >> now incompatible GDS32.DLL client. Some people are starting to use >> Interbase in parallel with Firebird, but the driver can only access >> one client :( not that I give a about the windows interbase/firebird extension .. but .. I do use firebird and all this talk of dropping firebird support is kind of scary (well really scary actually) ... I am able to configure php with '--with-interbase' in 5.3alpha2 so I guess I don't need to worry. > IMHO new database extensions should not be permitted unless they come on > the form of PDO drivers. in the case of firebird this is a little unfair, the interbase extension provides an alias of every ibase_*() function in the form fbird_*() which were specifically included due to forseen divergence between the interbase and firebird clients. effectively the extension for firebird already exists ... it just maps to the interbase function, if the fbird_*() aliases were removed and renamed copies the ibase_*() extensions functions created that then were built against the firebird client iso the interbase client you'd pretty much be there. technically the [firebird] extension would be new but is that really a deal breaker given that the complete API (fbird_*()) already exists? PS - I've been trying to follow these firebird shannanigans but it's all been a little too UPPER CASE for me to grok. :-/ > Thats also the vibe we send the Microsoft guys > with their sqlsrv extension. > > So if you cannot achieve what you need within the existing extension > while maintaining BC, I am afraid imho you will have to bite the bullet > and all the features into the PDO driver. > > Thats my opinion at least. > > 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] solving the namespace conflict issues between function/static method class constant/ns constant
Derick Rethans schreef:
> On Fri, 19 Sep 2008, Greg Beaver wrote:
>
>> Hi all,
>>
>> There is a problem in the namespace implementation. This code demonstrates
>> the issue:
>>
>> code.inc:
>> > namespace foo;
>> class test {
>> const my = 1;
>> static function bar(){}
>> }
>>
>> namespace foo::test;
>> const my = 2;
>> function bar(){}
>> ?>
>>
>> main.php:
>> > include 'code.inc';
>> foo::test::bar(); // always calls namespace function
>> call_user_func(array('foo::test', 'bar')); // the only way to call static
>> method
>> echo foo::test::my; // always 2
>> $a = new foo::test;
>> echo $a::my; // the only way to access foo::test::my
>> ?>
>>
>> There are 5 ways to solve this:
>>
>> 1) document it and hope no one uses it [this is the current strategy, minus
>> the documentation part]
>> 2) add a fatal error on conflicting names.
>
> Uh, if we don't have functions in namespaces, then the second "function
> bar(){}" would define the bar function in the global scope only and not
> as part of the foo::test namespace... so one more reason to remove
> functions (and constants) from namespaces?
I don't follow the logic. if we don't have functions in namespaces the second
"function bar(){}" would be a parse error, no?
>
> regards,
> Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
[EMAIL PROTECTED]: nothing of technical importance in this email, but it might make you feel better :-) ... even Stas!]] Kevin Waterson schreef: This one time, at band camp, "jvlad" <[EMAIL PROTECTED]> wrote: everything that jvlad wrote was way too vague for me to understand so I couldn't possibly comment on it. May I suggest something in this area? May I suggest something also.. Lets just let namespaces die and let it become a repressed memory as it seems it is more trouble that it is worth. Seriously. why does the ammount of trouble other people take upon themselves matter to you? ... and "repressing memory" is very bad advice (but that's rather esoteric). For 10+ years we have got on just fine without them, and the amount of work to get a second-best implementation that nobody agrees on hardly seems benificial. The gains of namespaces are minimal at best, because a few cannot be bothered with some simple prefixing. the gains are in the eye of the beholder, beyond the issue of symbol name collision avoidance there is big a real issue with very_very_very_very_very_very_very_very_looong_symbol_names ... it's a proven fact it becomes increasingly more difficult to grok lines of code as they increase in length ... namespaces offer a mechanism to mitigate overly long lines (at the cost of some obsfucation). you may decide the gains are minimal and not worth pursuing personally, but plenty of others feel the exact opposite. I'm personally a little ambivelent regard to inhouse code but I do envisage that libs like PEAR and ZF will become much more appealing when they take on namespaces, as such I care about whatever it [namespaces] becomes being 'good' .. because either way, sooner or later, I will be confronted with using them even if I don't use them in code I write myself. (my stance makes sense to me but It's likely I'm not expressing it very well!) PHP 5.3 release is looming, and there is STILL conflict about implementation. 1. conflict is everywhere, even outside of the world of php functionality implementations. 2. that 5.3 is 'looming' has surely not escaped the RMs 3. shouldn't 5.3 be release when it's ready rather because people expect it to be? The current approach is a long way from what was thought of as namespace support and it seems nobody is completely happy with any model that has been put forward. what exactly was thought of as namespace support? whatever it is exactly it is apparent that's it's wide open to mis-interpretation ... this is something to be tackled with documentation. I don't think the 'model' has been under attack, rather a number of ambiguity issues which were not fully foreseen ... issues which I might add are due in no small part to the 10+ years of baggage php has collected. it's easy to throw out the word 'namespaces' and assume everyone is on the exact same page ... it's rather harder to actually build something people are willing to call 'namespaces' ... the fact that it is hard and that the discussions have been long and difficult do not of themselves mean the effort and the impending result are not worthwhile. The current implementation is nothing but a series of comprimses, actually there has been very little comprise, that's one of the things the lead developer has been taking lots of flak for. each one taking away a little of the functionality that was first envisaged. the only thing that has been proposed to be taken away is functions and constants ... both of which can be incorporated at a later date (without the stress of release deadlines and having to deal with additional BC issues, imho), I personally think a phased introduction of namespacing functionality is not a bad thing, granted getting everything in one go would be nicer but at the end of the day you can't shoot yourself in the foot with a gun you don't have. the other major issue revolved around name resolution order upon which consensus has been reached in fact AFAICT (I've read everything that's been written AFAIK). Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. I would offer that bandying about subjective opinions as to what is wanted, what is true, etc, etc as being objective fact is one of the things that needs to die more than anything else. php counts it's user's in the 100,000's if not 1,000,000's ... I'd hazard to say that it's nigh on impossible to get accurate stats regarding namespace support. rgds, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant
Lester Caine schreef: Jochem Maas wrote: in the long run functions and constants will be added to namespaces ... and then the ambiguity issues will have to be dealt with. I believe Greg's namespace member concept will be required even if the syntax is/must/should/will changed to something everyone finds acceptable. Did you really mean to say that. funnily enough yes. Push namespaces out now - incomplete - and then change them again later? it's not imcomplete anymore than autoload() is incomplete (autoload() also doesn't cater for functions). and it's not *change later* but *extend later* whereas if one would roll out the currently implementation with functions/constants you would have to *change it later* to fix the ambiguity issues (which is hard to do in a way that satisfies anyone, see reactions to Greg's namespace member proposal as a perfect example of the ammount of friction that one needs to overcome). changing it later implies that people will have to fix their code upon a new release of php at some point because they have been using namespaced functions/constants. if they can't use something then they don't have to change the code that doesn't use it either. Why should we even bother using them if they don't do the whole job and are going to change again. not *changed* but *extended*. it seems obvious that BC dictates that stuff put out the door shouldn't be broken willy nilly. granted this will probably make it more difficult to come up with an alternative to Greg's proposal that also satisfies the ambiguities issues yet does not force syntax changes on developers using namespaces with released versions of php ... but that's not your f***ing problem is it? that'll be up to people like Stas, Greg, Dmitry et al to actually hammer out a solution. Things like PHPEclipse and phpdocumentor need some major work to support this extra level, and that can't start until the format has been fixed - and now even that is not certain ? ... same argument as above. I'll grant that my argument/opinion may be incorrect but I'll leave it up to the guys who build php to call me out on that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant
hi Dmirty, I really don't see a reason to change namespace syntax into a less intuitive way. I don't think the current implementation is intuitive, the ambiguity issues, (and possibly the name resolution order, although I can't grok what the current state of that is) are rather large WTFs. Your speed degradation argument isn't truth. The ambiguity problem exists, but it is just an ability to use php in a wrong way. Just don't create conflicting names. which begs the question, what was namespaces created for? (that's a serious question because your statement has me truly confused) you didn't answer the question (and AFAIC the readme doesn't either). The main reason of namespaces is resolution of name conflicts and ability to use the same names in different scopes. thank you for confirming this explicitly. README.namespaces was committed into PHP_5_3 about year ago. a 14 month old document which doesn't cover the status quo, and begins with a disingenuous statement about the problem namespaces try to solve (is that really all there is to namespaces? to avoid typing long class names? Yes, you are right. It's need to be adopted to current situation which might be changed once again... okay :-) ... I did actually promise Lukas that I'd write a guideline/best-practices doc regarding namespaces ... I still intend to give that a shot, It will require that people like you and Stas (amongst others) give a little time to vet the doc for accuracy, do you see this as a problem? most people have auto-complete features in their editor to take care of that 'problem' and it really doesn't explain why constants or functions exist in namespaces at all.) I see you point, and you might be satisfied with decision which is going to be final, however from my point of view function and constants must be allowed in namesapaces just because they are parts of the language. I would prefer to have functions and constants in namespaces, but I think the current implementation requires greg's patch in order to make it work. additionally I think autoloading for functions (and actually anything namespace related) should be seriously considered. the fact that it's only classes that can be autoloaded and namespaced is of itself consistent. there is something to be said for this kind of clearly defined 'limitation' - you know where you are! that said I think dropping functions (and constants) is the only real alternative to allowing greg's patch. dropping them may mean an incomplete namespace implementation, but in this case it's a good thing ... it allows people to start using namespaces and allows you (php devs) to work out a means to solve the ambiguity issues surrounding NS funcs/constants without worrying (as much?) about BC issues and without a barrage of 'wtf' type bug reports and questions (users will push namespaces to the edge and beyond if you give them the chance, not introducing funcs/constants means they can't simply can't do certain things for now) in the long run functions and constants will be added to namespaces ... and then the ambiguity issues will have to be dealt with. I believe Greg's namespace member concept will be required even if the syntax is/must/should/will changed to something everyone finds acceptable. rgds, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
Stanislav Malyshev schreef:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax for namespaces will be:
a) namespace foo;
should be first (non-comment) statement in the file, namespace extends
to the end of the file or next namespace declaration.
b) namespace foo {}
can appear anywhere on the top scope (can not be nested).
Mixing both syntaxes in one file is not possible. The semantics of both
syntaxes will be identical.
super. mixing of syntax is a parse error, right?
fancy taking a sportsmans bet as to which will be used more in the wild?
my 'money' is on syntax B. ;-)
2. Simplify resolution order for classes in the namespace: unqualified
names are resolved this way:
a) check "use" list if the name was defined at "use", follow that
resolution
b) if not, the name resolves to namespace::name
Consequence of this will be that for using internal class inside
namespace one would need to refer to it either as ::Foo or do use ::Foo
prior to its usage.
again super ... by the sounds of it (I have a sneaking suspicion that
some edge-case resolution pains may still crop up but that's what edge-case are
all about ... if you could spot them all they'd call you :-))
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.
given that the general distaste for Greg 'namespace member' proposal this
seems like the only other suitable option to resolve current ambiguity issues.
using abstract classes to 'namespace' functions has been a quite wide spread
practice for a while now anyway. it is likely that function() proponents will
balk at the idea of not being able to namespace them but that's less painful
to explain than having to deal with the current situation, imho.
which leaves the question of namespaced constants ... they suffer the same
problems as functions and can also be achieved via classes, I request that
you therefore remove them as well as functions.
rgds,
Jochem
PS - pity Greg's patch was so disliked, I rather liked it myself and would
have allowed constants and functions inside namespaces ... guess that's life :-)
Comments?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant
Dmitry Stogov schreef:
Lukas Kahwe Smith wrote:
On 22.09.2008, at 16:37, Dmitry Stogov wrote:
Returning to the original debate, if you really believe this conflict is
not an issue, then why was the first user note published last December a
note about this conflict?
http://us3.php.net/manual/en/language.namespaces.php#80035
I could add nothing. The problem exists, but proposed solution make
language even worse. Having A::B->foo() and ->foo() or ::foo() and
A::B->C::foo() is much more inconsistent from my point of view.
it's unfair to call it inconsistent, the syntax is consistent in it's own
right and uses an operator which is known to mean 'member' in a pre-existing
context.
if it truly can be considered inconsistent then that is only because Greg
proposal avoids BC breakage, inconsistency was inherent because two different
operators were chosen for class scope operator ('->' and '::') which your
following
comment demonstrates is technically unnecessary.
It would be better to change static class separator from :: to ->, but
it's a BC break
>>
Again, not speaking as an RM, I personally feel we really do have to
solve this ambiguity problem. I do not agree that this only affects
"namespace abusers".
That being said we have to stay realistic. What Greg proposes is
realistic imho. Its essentially reusing an existing OO syntax. The same
is what we have today with the double colon. While I agree that it would
not be my natural choice, it seems it solves our real problem of the
frequently mentioned ambiguity problem. So from that perspetive its a
step forward from the current syntax.
Yes. Changing :: into any other separator solves the functions/static
methods and constants ambiguity, but it also breaks intuitive syntax.
a, it doesn't actually solve all the ambiguity issues, Greg has tried to
point this out. I actually hammered Greg a number of times about the
:: seperator and the fact that changing it fixes the ambiguities ... after
careful consideration he came back to me and pointed out that *most* of
the ambiguities are resolved but not all, simply because (for one) it's still
not
possible to distinguish between an aliased namespace and an aliases namespace
name.
b, the presumption that the current syntax is intuitive is completely
subjective. imho it's not intuitive specifically because it's
open to intepretation as to what code refers to (aka ambiguous).
Thanks. Dmitry.
I know we are getting dangerously close (or are we already back in it?)
to the namespace separator discussion. I remember back then a lot of
people were saying lets get the implementation done first and then worry
about the syntax. I guess we are more or less at this point now.
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] solving the namespace conflict issues between function/staticmethod class constant/ns constant
hi Dmirty, I really don't see a reason to change namespace syntax into a less intuitive way. I don't think the current implementation is intuitive, the ambiguity issues, (and possibly the name resolution order, although I can't grok what the current state of that is) are rather large WTFs. Your speed degradation argument isn't truth. The ambiguity problem exists, but it is just an ability to use php in a wrong way. Just don't create conflicting names. which begs the question, what was namespaces created for? (that's a serious question because your statement has me truly confused) you didn't answer the question (and AFAIC the readme doesn't either). README.namespaces was committed into PHP_5_3 about year ago. a 14 month old document which doesn't cover the status quo, and begins with a disingenuous statement about the problem namespaces try to solve (is that really all there is to namespaces? to avoid typing long class names? most people have auto-complete features in their editor to take care of that 'problem' and it really doesn't explain why constants or functions exist in namespaces at all.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant
Dmitry Stogov schreef: Hi Greg, Greg Beaver wrote: ... I really don't see a reason to change namespace syntax into a less intuitive way. I don't think the current implementation is intuitive, the ambiguity issues, (and possibly the name resolution order, although I can't grok what the current state of that is) are rather large WTFs. Your speed degradation argument isn't truth. The ambiguity problem exists, but it is just an ability to use php in a wrong way. Just don't create conflicting names. which begs the question, what was namespaces created for? (that's a serious question because your statement has me truly confused) we can "Just not create conflicting names" without namespaces and Stas has mentioned numerous times that namespace were not designed just to avoid having to repeatedly type long symbol names. another thing, the ability to use php the wrong way is an argument that has been used lately both to: 1. advocate leaving functionality as it is and putting the burden of responsibility on the developer to do the right thing. 2. advocate changing functionality (or making the functionality illegal) in order to protect the user from doing something stupid. .. not exactly consistent. BTW, not creating conflicting names doesn't make the problem completely dissappear, code is still vulnerable breakage due to addition of new functions or classes in future version of the engine. I would recommend option #1 (stay it as is + document) It would seem that it's yours' and Stas' responsibility to properly document how namespaces should be used because everyone else either doesn't care much about it or has, according to you, completely the wrong end of the stick with regard to the how/why/what of namespaces. Can we at least count on you [both] to provide that documentation? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Steph Fox schreef: Hi Jochem, It seems to hav escaped everyone that Greg's latest proposal doesn't change the namespace seperator token, instead it comes with a new concept of namespace member [token]. No, that didn't escape me at all. oh, good! I was responding to the OP. To be clear, I have worked with Greg. The experience left me with large amounts of respect for his creativity and analytical abilities. They exceed mine by a number of quadzillions. I've been conversing with him over the last couple of weeks regarding namespaces off-list and have every reason to second that thought. That doesn't mean Greg's always in the right, but it does mean he's always worth hearing. I know for sure I'm not the only person on this list who sees him that way, and most of the others have far more influence than I do. which makes it all the more sad that the only person taking a real interest in his [latest namespace] proposal is the one person who's completely adamant that there is nothing in the current namespace implementation that needs addressing (all issues come down to 'your using it wrong') Next time, perhaps you and I should both let sleeping dogs lie ;) I don't get the use of that idiom in this context. I think the 'namespace' dog has been up and about for a while already, granted some would like to see it put down permanently :-) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
Steph Fox schreef: Seems like a winner. Just a whole ton of BC though for those using # for comments. Yep, so forget it. Or were you doing a Jani? ;) It seems to hav escaped everyone that Greg's latest proposal doesn't change the namespace seperator token, instead it comes with a new concept of namespace member [token]. ambiguity related to the 'use' statements remains regardless of what the namespace seperator is ... therefore the proposal for a new operator that allows to explicitly reference namespace members: and obviously BC dictates that '#' cannot be considered, but that's moot anyhow. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaced function vs static method in global class
Stanislav Malyshev schreef:
Hi!
1. include.php
I would advise you to avoid calling your classes and namespaces by the
same name, for the sake of clarity - especially if you are going to have
identically named static functions in both. You can always have My::Test
instead, etc.
essentially good advice, but completely dismissive of the underlying issue.
2. How should I call the static method
baz of class Bar in namespace Test with call_user_func
call_user_func(array('Test::Bar', 'baz')). Remember, the true name is
always the full name.
3. Is there no possibility to change your minds and replace the double
colon with
something else, likes a simple colon?
With simple colon - not likely.
what about a simple new concept then?
I find it very confusing to
figure out what is what and the way I should call it.
You should always use full name with call_*, reflection, variable class
names and other runtime constructs. You can use shortcuts with static
constructs - where you specify the class name explicitly.
now that last point is darn good raw material for an upcoming namespaces
guideline, don't mind if I pinch it do you?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] make fails due to ext/iconv/php_have_ibm_iconv.h missing (5.3 including alpha2)
Karl Pflästerer schreef: Jochem Maas <[EMAIL PROTECTED]> writes: Alexey Zakhlestin schreef: On Mon, Sep 8, 2008 at 12:11 AM, Jochem Maas <[EMAIL PROTECTED]> wrote: if anyone knows of some details info on how to keep multiple installs of php around (including apache modules) and being able to switch between them with minimal fuss then I be very happy to learn! the easiest option is to use different prefix-paths for php default installation: ./configure --prefix=/usr/local some custom installation: ./configure --prefix=/opt/php53-test I do this already, only the apache module, if compiled, is always installed where apxs2 says it should be put ... ergo it overwrites the version that I consider/use as default/production. I use symlinks for that. I have a symlink /usr/local/php-active which points to e.g /usr/local/php-5.2.6 (the stable version) (php is compiled with --prefix=/usr/local/php-5.2.6) /usr/local/bin/php is a symlink which points to /usr/local/php-active/bin/php. So I am sure if I call php from the commandline that the right php version gets called. For the apache module my makefile with which I compile php renames the .so file to another name and I have another symlink libphpactive.so which points to that lib. is it safe to use a different make file? are there gotchas? care to share the make file (or the changes you make/made)? thanks anyway for your explaination .. It makes it very clear how I'll go about it from now on :-) So if I want to upgrade I compile a new php version, test it from the command line and fpr apache I use a test process which has the same docroot as the production server but uses the newly build php lib. If all goes well I change two symlinks, restart Apache and am finished. If I saw later problems I could easily jump back to an earlier version by changing these two symlinks. (I compile php as DSO; if you compile PHP as statically bound Apache module it's the same. Just put every Apache version in an own directory and have a symlink which points to the version you want for production.) Bye KP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
Stanislav Malyshev schreef: Hi! Hi, I'm not going to do this offlist with you, guns are dangerous yet they are sold by the bucket load. either don't sell guns or let people decide how to use them, don't sell'em then dictate that they can't pull the trigger. I think it would really help if we avoided discussing issues of gun control, legalizing marijuana, marrying people of the same sex, and another very fascinating issues and concentrate on the namespaces. Can we? it's a metaphor, and you know that. apart from the intended metaphor there was not discussion whatsoever, merely a statement of fact. I don't give a hoot about gun control or any of the other so-called fascinating issues (as you put it), I do care about the fact that namespaces are pretty borked atm. That, and the fact that you seem to be dictating exactly what is right and what is wrong regardless of any evidence people put infront of you. I won't be using namespaces in 'real life' code at all. I've never Then I'm sorry but why you have an opinion on them at all? Sorry if I sound somewhat blunt, but if you aren't going to use them why you care so much about them? somewhat bluntly: because I *want* to use namespaces, but the implementation is not good enough to be usable. but really the issue of why I care is irrelevant, it is apparent that I do, that is enough. you may consider my opinions invalid or unimportant, obviously that is is your perogative ... but you haven't mentioned that (and neither have you ignored my post, which would imply it) ... your merely insinuating I don't have a right to an opinion ... well I certainly do, and you have the right to ignore it, but not to question my right to it as such. We want to accommodate all users as much as possible, but if you are not going to be a user - why you want to take part in designing them? I play with it, but I'm not going to risk production code with it thanks. And regardless of whether I will or will not use namespaces in *my* code I will still be faced with having to deal with them sooner or later when incorporating other people's libraries and/or hacking the code on some CMS/Blog/forum app (as I do have to now and again) It might surprise you that my interest lies in php's improvement, even though I'm merely a joe-nobody-php-coder without the skills required to code for the engine (which I'd love to do, as the books on C/C++ on my living room table attest to). It is very hard to find a common solution satisfactory for all if you start with the premise that no solution would be satisfactory for you because you just not going to use any. your merely twisting my words to satisfy your own position. Aparently I have an opinion on this matter, please just accept that ... I've being reading, thinking and worrying about the namespaces for a long time and I've decided to speak up. it really is important that you start to deal with the issues being presented rather than trying to undermine and second-guess the validity of everyone else's opinions and critisisms. I didn't start with the premise that nothing would be satisfactory, merely the premise that the current implementation has major issues. I'm sorry is that a function in namespace Utility or a static method of class Utility? Who cares, except for the engine internals? we'll it will break my IDE, so I'll have to go hunting for the definition by hand (which I won't know what to look for), for starters, but mostly because I like to be able to know what code is supposed to be doing, what it is supposed to be calling by reading it and not by guessing and having to run it (and hope I got my includes in the right order.). do I understand you correctly in that you seem to think being able to understand code just be reading it is pointless? I understand your concerns about performance, of course namespaces need to be performant in order to be truly usable in production BUT clear, usable functioning needs to take priority before performance is considered ... No, not really. If the solution doesn't work (i.e. makes your code order of magnitude slower) nobody will use it however good it is in theory. something that is slow can still be considered correct. you've completely mixed up the concepts of 'theory' and 'practice' and also incorrectly concluded that slow code equates to non-working code. I have never suggested that performance is not important, merely that to use the performance argument as an excuse to avoid taking any critism of the current implementation seriously is very bad form. make it work THEN make it work fast. otherwise you'll end up with something very fast that never quite lives up to expectations and additionally continually causes pain/confusion, how ever much you hack into it (nevermind all the BC issues you'd have created for yourself by letting the status quo implementation into the wild [in an official release]). frankly I am quite sure that you are capable of fixing
Re: [PHP-DEV] make fails due to ext/iconv/php_have_ibm_iconv.h missing (5.3 including alpha2)
Antony Dovgal schreef: On 08.09.2008 00:11, Jochem Maas wrote: --with-xmlrpc This extension requires iconv. aha. well at least that allows me to build 5.3alpha2 with all the extensions I require to I have to admit there is a mess with iconv. I'm glad it's not (just) down to my incompetence, I was starting to pull out hair trying to compile on MacOS (whereas I've never had a problem on linux) .. not that I want to insinuate anyone else is incompetent! it's just that I'm rather on the edge of what I'm capable of when it comes to massaging make run into doing what I want (in fact I can't remember ever having make [for php] fail on me on linux, so it was rather shocking to see it blow up on MacOS where everything is suppose to be 'fantastic' ... note that there *were* loads of problems with shipped libs on MacOS10.5 that made compiling [php] 'impossible' for quite a while, these were issues that had nothing to do with php ... although ironically enough they had everything to do with lib_iconv) IMO configure should fail if one tries to build xmprpc with iconv disabled instead of silently enabling it. my current (working) build of php5.2.6 lists xmlrpc as an extension BUT not iconv ... so iconv is not silently enabled (at least not from a php user's POV) the error message from make is: In file included from /Users/jochem/src/php-5.3.0alpha2/ext/standard/info.c:47: /Users/jochem/src/php-5.3.0alpha2/ext/iconv/php_iconv.h:42:42: error: ext/iconv/php_have_ibm_iconv.h: No such file or directory Should be fixed in CVS, thanks for noticing. okidoki. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
Stanislav Malyshev schreef: Hi! for the same reason you would want it with classes?? because you can do it with classes, no? and that seems acceptable to you, no? then functions should have the same privilege. Functions and classes are rather different things. Class represents, as you know, group of data and behavior, function is much smaller. You have maybe two dozens of built-in classes in PHP that reside in global space, and many of them (like SPL) can be moved out relatively easily to own namespaces. You have hundreds, if not thousands, of internal functions, most of them can't be moved anywhere. So having functions imported into global space is much less useful and much more dangerous than the same for classes. guns are dangerous yet they are sold by the bucket load. either don't sell guns or let people decide how to use them, don't sell'em then dictate that they can't pull the trigger. It is also much less useful from one more perspective - when you import a class, you get a bunch of functions which represent functionality unit. With single function you probably get only a small piece, so if you use a library you probably have dozens of functions there. If you think importing all of them into global space through "use" is a good idea, I think you need to do some refactoring there. I won't be using namespaces in 'real life' code at all. I've never encountered a symbol clash on a class, function or constant in my code and the day I do I'll rename, search and replace to fix it ... as it stands namespaces offer me nothing but obtuse abstraction, increased code brittleness and general stress ... I can do without that lot, which is a pity because conceptually namespaces are a good idea, I'd love to be able to reduce my symbol pollution in the global scope and logically 'package' various functionality inside some a defined space. It would grow to be unmaintainable rather fast. I'd recommend putting them into a namespace (if for some reason you have classes) and then just use Utility::func() I'm sorry is that a function in namespace Utility or a static method of class Utility? - it's really not that bad. no it really is that bad, namespaces as they stand have merely moved the goalposts of symbol clashing somewhat whilst at the same time making code less understandable when reading/auditing [php] source code (e.g. load order dictating what exactly will be instantiated, the function-or-static-method WTF). I understand your concerns about performance, of course namespaces need to be performant in order to be truly usable in production BUT clear, usable functioning needs to take priority before performance is considered ... otherwise your putting the horse before the cart so to speak. Elizabeth and Greg have both stipulated the issues clearly - they need to be tackled or you will end up with something that is going to make the language less usable and not more so. as it stands now prefixing class names with a project specific string and using abstract classes to fake namespacing of functions is still a more usable way to go than implementing namespaced code. I don't supposed that's the intention? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
Elizabeth M Smith schreef: Stanislav Malyshev wrote: Hi! Personally I don't see the point of of having functions in namespaces if you can't "use" them in a global scope. You mean, if you can do foo() it has a point but if it's F::foo() it doesn't? Then I think your point was purely cosmetical from the start and wasn't real either way. Saving 3-4 keystrokes was never a major goal. namespaces weren't really meant as mechanism to replace functions in code without anybody noticing - they are not that hack. It might be a neat hack for some uses - but I just don't think it has anything to do with namespaces. Depends on what you think namespaces are for. For me they are ways to "package up" code without interfering with built in PHP functions or other libraries I wish to use. I don't want to retrain myself or others to call all functions in my code as though they were static methods. I want to be able to have functions with the same names as php functions without prefixing or other extra typing - not because it saves keystrokes, but because it's confusing - is that a function call or a method call? ofcourse that whole issues actually arises from the brilliant decision to use '::' as the namespace resolution operator. not that functions shouldn't be fully aliasable if classes can be. Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
Stanislav Malyshev schreef: Hi! This doesn't work at all The closest you can do is That's the right way to go. If you want functions in global space, put them there. If not, then use namespace syntax. BTW, what is so bad in F::myfunction that it makes it absolutely useless? because it reads like a fucking static method call, truly not an absolute reason, but none the less totally not KISS. which kind of defeats the purpose of having functions in namespaces at all, why not just use a class with static methods at this point. I didn't see a lot of use of having functions in namespaces from the start, but if you could explain what your point is - i.e. why do you want functions that are declared in namespaces and still are in the global space - I could maybe understand the concern better. for the same reason you would want it with classes?? because you can do it with classes, no? and that seems acceptable to you, no? then functions should have the same privilege. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] make fails due to ext/iconv/php_have_ibm_iconv.h missing (5.3 including alpha2)
Alexey Zakhlestin schreef: On Mon, Sep 8, 2008 at 12:11 AM, Jochem Maas <[EMAIL PROTECTED]> wrote: if anyone knows of some details info on how to keep multiple installs of php around (including apache modules) and being able to switch between them with minimal fuss then I be very happy to learn! the easiest option is to use different prefix-paths for php default installation: ./configure --prefix=/usr/local some custom installation: ./configure --prefix=/opt/php53-test I do this already, only the apache module, if compiled, is always installed where apxs2 says it should be put ... ergo it overwrites the version that I consider/use as default/production. I am not sure how it relates with apache. would fastcgi work for you? I don't see why not, but I've never really grokked fastcgi. I'll go searching/reading again, I have noticed people on internals stating it to be faster (than the apache module) ... official documentation on fast-cgi setup is a bit thin on the ground. thank you for your feedback. rgds, Jochem P.S. is the missing ext/iconv/php_have_ibm_iconv.h a problem with the src bundle or something specific to MacOSX? either way it seems to be the only thing stopping me from building 5.3 with all extensions I use. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] make fails due to ext/iconv/php_have_ibm_iconv.h missing (5.3 including alpha2)
In an attempt to do some testing of 5.3 I have being trying to compile it on my Mac (MacOSX10.5) with the same configure line[1] as I use for my 'current' version (5.2.6), this is turning out to be impossible because (so far) of a missing file ext/iconv/php_have_ibm_iconv.h the configure line I want to use is as follows (note that it specifies '--without-iconv'): './configure' '--with-config-file-path=/etc' '--sysconfdir=/private/etc' '--prefix=/usr/local/php5.3alpha2' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-xsl=/usr' '--with-tidy=/opt/local' '--enable-mbstring' '--with-gd' '--enable-gd-native-ttf' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local' '--with-zlib-dir' '--enable-sockets' '--enable-exif' '--with-mcrypt=/opt/local' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/private/tmp/mysql.sock' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--with-freetype-dir=/opt/local' '--with-xpm-dir=/Developer/SDKs/MacOSX10.5.sdk/usr/X11' '--with-ldap' '--with-xmlrpc' '--enable-soap' '--enable-sqlite-utf8' '--enable-ftp' '--enable-sockets' '--with-bz2' '--enable-zip' '--enable-pcntl' '--enable-shmop' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-bcmath' '--with-gettext=/opt/local' '--with-curl' '--with-mcrypt=/opt/local' '--with-interbase=/opt' '--without-iconv' '--enable-cli' '--with-sqlite' the error message from make is: In file included from /Users/jochem/src/php-5.3.0alpha2/ext/standard/info.c:47: /Users/jochem/src/php-5.3.0alpha2/ext/iconv/php_iconv.h:42:42: error: ext/iconv/php_have_ibm_iconv.h: No such file or directory I have (just now) been able to build a very minimal install of 5.3 using the following configure line, which does give me enough to be able to test some stuff related to namespaces/LSB/etc: './configure' '--with-config-file-path=/usr/local/php5.3alpha2' '--sysconfdir=/private/etc' '--prefix=/usr/local/php5.3alpha2' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-all' '--enable-cli' it does seem that the file ext/iconv/php_have_ibm_iconv.h really is missing and that it should be there (although I have no idea why iconv is referenced given the '--without-iconv' ... there is probably good reason, but it's over my head, so to speak. rgds, Jochem [1]minus the apache module for now ... as I'm afraid 'make install' will break my current install, which I really can't afford to break ... I'm no wizard but I do need to be able to do my job :-/ ... if anyone knows of some details info on how to keep multiple installs of php around (including apache modules) and being able to switch between them with minimal fuss then I be very happy to learn! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace RFC
Lukas Kahwe Smith schreef: On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote: Hello all, All the recent discussions about namespaces, have left many of us wondering if our implementation is rock solid or not. However the discussions were not really well organized. This is why I am thankful that Marcus and Felipe have spend the better part of this Sunday to write an RFC [1] that hopefully summarizes all the key concerns. Also they have created a patch that they feel addresses the concerns. [1] http://wiki.php.net/rfc/namespacecurlies I have also asked in my blog about practical experiences from people using PHP 5.3.0 with namespaces in development: http://pooteeweet.org/blog/1288 The gist in the first 2 responses seem to be that they are ok with the current state of things. they both admit they don't do (or are not interested in) the major point the RFC tries to tackle (i.e. file concatenation). subsequent posts do point out problems: 1. "non-deterministic" (a.k.a error prone) __autoloading issues - IFAIC Greg's arguments are sound, Stanislav's performance arguments are bogus (imho) simply because, up until the point that the new functionality is stable, complete and devoid of the WTF-factor it's performance should be ignored ... make it work, then make it fast? 2. namespaced constants/functions not autoloadable 3. namespaced functions not aliasable 4. the abiguity with static methods and namespaced functions - Elizabeth states this very succinctly. 5. inordinate number of use statements 6. internal classes being 'favored' over user classes. - which is likely to mean people will either avoid namespaces, avoid use statements or worse still miss a use statement now and again ... see point 1. If you ask me a major issue stems from the fact that the namespace scope operator was chosen to be the same as the class scope operator, even if this incurred no technical problems (which, I think, point 4 is), it still incurs the potential for major WTF when simply reading code - at the very least having to constantly check the 'use' statements at the top of a file to determine the actually referred to 'element'. Lukas, you stated a while back you were nervous about the namespace functionality, I believe you are right to be so. what there is currently will most likely do the opposite of what it is intended to ... the intention being, I assume, to increase php's 'enterprise level' functionality & appearance (in terms of suitability). rgds, Jochem PS - please be a Dictator! currently it seems that the dev that shouts the loudest gets to shove his opinion/implementation down everyone's neck regardless of anyone's objections (however sound) ... even when those objections come from other devs, which makes a farce of the concept of meritocracy, besides nothing about open source suggested it's development process needs to be done by commitee. the more I think about it the more I believe php would benefit from a benevolent dictator ... who that might be is a more difficult question to answer, one steeped in politics. I could offer about 3 names that I think would suit the position, but I doubt anyone of 'importance' has read this far and if they had they probably attribute about as much weight to my opinions as they do to the average life of an ameoba. Anyways, anyone who cares should make their opinion known on this list as clear as possible by Monday (if someone is aware of a good discussion outside of internals please also let us know), so that Johannes and I can make a decision no later than Tuesday without having to feel like dictators. Personally at this point I would leave things as is for now, move to beta and hope that this also increases the number of end users testing and giving feedback. While I hope that we dont have to do big changes after going to beta, if feedback makes it necessary, we obviously have to accept it. 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] Re: ini-parsing, double quotes, windows in 5.3
Jani Taskinen schreef: Hannes Magnusson wrote: On Thu, Sep 4, 2008 at 22:43, Jani Taskinen <[EMAIL PROTECTED]> wrote: Johannes Schlüter kirjoitti: ... php.ini-recommended, 5.3: ; ; Paths and Directories ; ; ; UNIX: "/path1:/path2" ;include_path = ".:/php/includes" ; ; Windows: "\path1;\path2" ;include_path = ".;c:\php\includes" As you can see, Windows users are explicitly told to use foo\bar\ inside double quotes. This has been like this for years and is also documented in the manual. It looks to me that the old behavior was very intentional, logical or not. Ini files are not documentation. it's got 'recommended' in the filename ... you betcha it's documentation. that said 1. change the contents of php.ini-recommended, et al 2. change the ini parser to scream an error (and a solution?) if it comes across the problematic syntax 3. stick a popup at the end of the windows installer (or even at the beginning, allowing someone to fix the error in their current php.ini before 5.3 is installed ... for seemless upgrade) 4. put a big notice in the CHANGE_LOG 9 out of 10 users installing windows binaries do it for their local dev environment ... not critical if it breaks due to ini settings ... and for the rest, any admin who manages to avoid all the warnings and install php5.3 on a production server and break the install (very temporarily) probably deserves the earful (s)he'll get from PHB. sometimes BC has to be broken ... it's not as if it's the first time BC broke in a 'minor' release is it? and in this case you've actually introduced great new functionality to the 'ini system' ... well worth the slight pain it might cause a few windows admins, no? And as / works also for winblows, that should be used JUST for the sake of consistency anyway.. Anyway, the fix is quite easy: Only allow \" and no other escapes. And doing "foo\" should cause a syntax error. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM
redirecting to generals mailing list ...
Diogo Neves schreef:
php -r 'class B { private static function a() {} public function
__callStatic($method, $parms) { echo $method, "\n"; } } $a = new B;
$a::a();'
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in Command line
code on line 1
Ok, i found the error, but anyway... a what?
it's hebrew for 'double colon' (::), google could have told you this.
please note, the internals mailing is for php engine development/developers,
I don't think they look forward to this kind of question (t)here.
...we're lucky enough that they tolerate lurkers (*cough*) :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP vs PHP NTS benackmark (win32)
Thank you everyone for you replies, apparently I know a little more than I thought in general and also a little more than this morning. :-) rgds, Jochem Andi Gutmans schreef: There are some things I mention in this blog entry re: why I think ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strange autoload behavior
Marcus Boerger schreef:
Hello Jochem,
...
I just posted another mail to internals in which I attempt to detail the
__autoload behaviour 'issues' ... it includes something that wants to be a
test suite when it grows up ... it might help someone to investage/determine
what __autoload() does/should do:
http://iamjochem.com/autoload_behaviour_tests.zip
Great! More tests :-)
It is quite a lot of stuff and I'd like to see this turned into .phpt's.
it looks more than it is, the runtests.sh script makes viewing the results
of the variations in settings/code easier.
if you unzip the file and execute ./runtests.sh with no args it goves you
all the options ... at this stage I wrote primarily to figure out what
actually happens under any number of conditions.
I'd love to take a shot at converting them to .phpt I see 3 problems
1. I don't know .phpt (I can solve this)
2. I have no idea what to expect and therefore test for
(this needs to be determined/clarified!)
3. In the case that I need to test for an uncaught Exception I wonder
how to determine a pass (ie uncaugh exception thrown as expected) given
that the exact output is dependent on the full path of the relevant script
any advice as to how to proceed, especially with regard to point 2.
rgds,
Jochem
marcus
That is they
are simply ignored.
and so I thought :-) which is why some of my test's output "wtf!" :-)
as always, thanks for your feedback,
regards,
Jochem
And once all __autoload work is done and the class
still doesn't exist an E_ERROR is issued. The work around for cases where
the class must not exist (e.g. when no E_ERROR is needed would be
collecting the exceptions. That is the base Exception class would get an
additional property and getter:
private $previous_exception;
function public getPreviousException();
That way we could let the exceptions bubble up (though some smaller engine
changes are necessary).
currently you can throw an exception out of __autoload() unless __autload()
is triggered by the 'new' syntax or by a static method call (e.g.
MyClass::myMethod()),
with other 'triggers' (e.g. call_user_func()) the exception comes through ...
in cases that it doesn't you can get an exception out of __autoload() via the
eval() trick [see below] ... I don't suppose there is anyway of asking the
engine
which way __autoload() was triggered from inside the __autoload() code?
marcus
Thursday, July 10, 2008, 7:14:33 PM, you wrote:
Derick Rethans schreef:
On Thu, 10 Jul 2008, Gergely Hodicska wrote:
exceptions thrown during autoload are ignored.
And one more thing, this is in the manual:
"Note: Exceptions thrown in __autoload function cannot be caught in the catch
block and results in a fatal error."
I think your explanation makes much more clear what happens, maybe it would
worth to upgrade the manual. While the quoted text suggests that that if throw
an exception I just can't catch it and will bubble up to top level and this
cause the fatal error.
You can actually catch it *in* the autoload method, it just wouldn't
bubble out of it.
the manual could do with that tidbit, maybe also the hack for 'getting the
exception out' of __autoload() ...
function __autoload($class)
{
try {
throw new Exception('foo');
} catch (Exception $e) {
self::handleDebug($e);
if (!class_exists($class, false))
eval(sprintf('
class %1$s
{
public function __construct(){
throw new AL_Exception("Class %1$s not found: %2$s"); }
public function __call($m, $a) {
throw new AL_Exception("Class %1$s not found: %2$s"); }
public static function __callStatic($m, $a) {
throw new AL_Exception("Class %1$s not found: %2$s"); }
}', $class, $e->__toString()));
}
}
which works best when __autoload() isn't triggered by class_exists("Foo", true)
regards,
Derick
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP vs PHP NTS benackmark (win32)
David Zülke schreef: Am 17.07.2008 um 11:36 schrieb Mario Brandt: I made a test on my console (cmd.exe) ENV: WinXP SP 3 all updates, PHP 5.2.6 / PHP 5.2.6 non thread safe (NTS) Intel Celeron 2.4 GHz 1 GB DDR Ram It showed that the non thread safe is faster than the thread safe version. And your point/question is...? hmmm. can't speak for Mario but reading this caused a few questions to pop up in my head. Im an average joe php'er trying to write secure and fast code, I am aware of threads and processes and the general issues but don't understand the gritty details of implementing reentrant [C] code (is that the right word??) I know that running php in a threaded env is a no-no due mostly to certain extension being [probably] not thread safe - an uncertainty factor not suitable for production, at least so I have been led to believe by comments made by core php devs. (is this [still] true?) now the question part ... a, what are the ramifications of having to run php without threading when we live in a world that's increasingly moving towards multi-core/multi- CPU systems? b, Is php not missing out here big time? d, Will threads ever become recommended in/for php? e, If threads become the norm, will php code have to be written differently to account for threads? f, are there things I can/should be doing to my [production] systems/software-stacks to leverage extra performance for my php code from CPUs with multiple cores (and/or machines with multiple CPUs)? g, am I worrying about nothing? :-) David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strange autoload behavior
Hi Marcus,
Marcus Boerger schreef:
Hello Jochem,
seems like we have quite some nice additions to the manual here in this
thread. Now to the real issue, Exceptions don't bubble up.
The thing is under quite a few circumstances the Exceptions do bubble up,
and there is another issue with __autoload() causing [other] errors not
to trigger the user defined error handler ... behaviour or php5.2.6 and php5.3
are the same in this regard.
I just posted another mail to internals in which I attempt to detail the
__autoload behaviour 'issues' ... it includes something that wants to be a
test suite when it grows up ... it might help someone to investage/determine
what __autoload() does/should do:
http://iamjochem.com/autoload_behaviour_tests.zip
That is they
are simply ignored.
and so I thought :-) which is why some of my test's output "wtf!" :-)
as always, thanks for your feedback,
regards,
Jochem
And once all __autoload work is done and the class
still doesn't exist an E_ERROR is issued. The work around for cases where
the class must not exist (e.g. when no E_ERROR is needed would be
collecting the exceptions. That is the base Exception class would get an
additional property and getter:
private $previous_exception;
function public getPreviousException();
That way we could let the exceptions bubble up (though some smaller engine
changes are necessary).
currently you can throw an exception out of __autoload() unless __autload()
is triggered by the 'new' syntax or by a static method call (e.g.
MyClass::myMethod()),
with other 'triggers' (e.g. call_user_func()) the exception comes through ...
in cases that it doesn't you can get an exception out of __autoload() via the
eval() trick [see below] ... I don't suppose there is anyway of asking the
engine
which way __autoload() was triggered from inside the __autoload() code?
marcus
Thursday, July 10, 2008, 7:14:33 PM, you wrote:
Derick Rethans schreef:
On Thu, 10 Jul 2008, Gergely Hodicska wrote:
exceptions thrown during autoload are ignored.
And one more thing, this is in the manual:
"Note: Exceptions thrown in __autoload function cannot be caught in the catch
block and results in a fatal error."
I think your explanation makes much more clear what happens, maybe it would
worth to upgrade the manual. While the quoted text suggests that that if throw
an exception I just can't catch it and will bubble up to top level and this
cause the fatal error.
You can actually catch it *in* the autoload method, it just wouldn't
bubble out of it.
the manual could do with that tidbit, maybe also the hack for 'getting the
exception out' of __autoload() ...
function __autoload($class)
{
try {
throw new Exception('foo');
} catch (Exception $e) {
self::handleDebug($e);
if (!class_exists($class, false))
eval(sprintf('
class %1$s
{
public function __construct(){
throw new AL_Exception("Class %1$s not found: %2$s"); }
public function __call($m, $a) {
throw new AL_Exception("Class %1$s not found: %2$s"); }
public static function __callStatic($m, $a) {
throw new AL_Exception("Class %1$s not found: %2$s"); }
}', $class, $e->__toString()));
}
}
which works best when __autoload() isn't triggered by class_exists("Foo", true)
regards,
Derick
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] autoload somewhat broken? or do the docs need more info?
hello people, I believe there is something wrong (or inconsitent) with the way __autoload() behaves. at the least the current docs don't reflect what I'm seeing. 1. the docs state: "Exceptions thrown in __autoload function cannot be caught in the catch block and results in a fatal error." this is not exactly true, I can catch exception throw from __autoload() IF __autoload() was triggered via call_user_func*(), class_exists() & is_callable() 2. if a user error handler is set with set_error_handler() any errors (at least upto and including E_WARNING) that occur in a function that triggers (e.g. call_user_func()) __autoload() will not be given to the error handler function (it never recieves a call) if the __autoload() it triggered throws an exception (that is not caught inside __autoload(). 3. I suspect that point 2. is the reason that in some real-world situations even Fatal Errors are not logged at (to screen or file, regardless of error_reporting/display_error settings), resulting in a blank screen and no idea as to the cause ... I have seen this happen repeatedly on different versions/machines/etc since php5 was in beta ... I have still not be able to reproduce the vanishing Fatal Errors in a simple test script ... that said on all occasions where nothing was logged for such Fatal Errors (which in my case are always the result of a class that cannot be found) I could run the same script via a debugger which then always did show the Fatal Error message ... why would running the script via a debugger show [Fatal Error] output in the browser window where as running the script normally [in the browser] results in no output whatsoever? Anyway I don't really know if anything is wrong, whether the docs need updating, or whether someone should really look at the situation. I have written a little 'test suite'[1] with which one can observe __autoload() behaviour in various configurations ... it comes with little shell script called 'runtests.sh': $ ./runtests.sh usage: ./runtests.sh [--set-err-handler] [--display-errors] [--gen-class] [--no-autoload|--no-throw [--spl-autoload]] must be one of: new new2 static class_exists call_user_func call_user_func_array is_callable OR all --set-err-handler = define a user function to trap php errors. --display-errors= sets php ini setting display_errors on. --no-autoload = skip autoloader function definition. --no-throw = tell the autoloader not to throw the exception. --spl-autoload = use spl_autoload_register() instead of __autoload() --recurse-autoload = trigger __autoload from within __autoload --gen-class = to have autoload auto-generate the class (exception will still be thrown) classes will have __construct(), __call() and __callstatic() methods 1. you may export an environment variable $PHP_TEST_BIN to control which php binary used to run the tests 2. errors logs are recreated on each run for each in ./logs/.log rgds, Jochem [1] http://iamjochem.com/autoload_behaviour_tests.zip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Phar ... brilliant, a couple of questions?
Scott MacVicar schreef:
On 12 Jul 2008, at 12:36, Jochem Maas wrote:
to Greg and his cohorts a hearty bravo!
Phar is a really great addition, I'm very impressed with
the finesse of the initial implementation ... it's quite
rare to see [imho] a new feature appear in such a mature
and well thought out manner, good work 'smith. :)
...
3. are there technical reasons for not being able to create/access
an sqllite db inside a Phar?
I have plans to add support to the various SQLite extensions to some
extent, I've yet to see how much is possible.
If creating a VFS driver for sqlite is simple then they'll be full read
/ write support else it will be mounting and read only.
I see, I think even readonly would be a real boon. in the case of readonly
mounting would it be possible to do read/write to an sqlite db file that
exists on the FS but is referenced via a 'symlink' in the Phar?
e.g. that code would reference phar://myphar/mydb.sqllite
and that the Phar ('myphar') has 'mounted' the file
/home/jochem/stuff/mydb.sqllite at phar://myphar/mydb.sqllite
this would allow a phar to self-extract it's DB if/when it
needs read/write access and reference the DB file in code at
the same path regardless of whether the DB file is actually inside
the Phar at the time.
this all assumes self modifying Phars are to be encouraged, which
given the leanings towards signed code, is probably not the case ...
a pity from a usability perspective ... I'd love to be able to
reduce the production file count down to 2 for small sites (the vhost.conf
& the .phar)
4. Am I crazy to think of building a dynamic website, cms, including
all user [uploaded] files, installation config .. complete with
command line interface for updates, upgrades, module/config
management, etc, etc ... all in one Phar? is that feasable?
what kind of read and/or write concurrency could one expect?
if building self updating Phars is okay, then maybe an example
in the manual could be done to emphasis a few do's, dont's,
limitations, etc.
well am I? :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Phar ... brilliant, a couple of questions?
to Greg and his cohorts a hearty bravo! Phar is a really great addition, I'm very impressed with the finesse of the initial implementation ... it's quite rare to see [imho] a new feature appear in such a mature and well thought out manner, good work 'smith. :) I have a few questions, some of the answers may deserve a few lines in the docs. 1. to what extent is Phar capable/designed to handle self updating Phars .. especially with regard to multi-user access (I'm thinking in terms of a website+CMS+userdata in a Phar updated by a few people 'concurrently') 2. is there a (quick) way to reference a Phar object of the current (as in Phar::isRunning()) Phar file - I figure the engine can do new Phar(Phar::isRunning()) faster/better, no? 3. are there technical reasons for not being able to create/access an sqllite db inside a Phar? 4. Am I crazy to think of building a dynamic website, cms, including all user [uploaded] files, installation config .. complete with command line interface for updates, upgrades, module/config management, etc, etc ... all in one Phar? is that feasable? what kind of read and/or write concurrency could one expect? if building self updating Phars is okay, then maybe an example in the manual could be done to emphasis a few do's, dont's, limitations, etc. kind regards, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] persistent sockets need help
Lukas Kahwe Smith schreef: On 10.07.2008, at 14:43, Richard Krehbiel wrote: Here's the big part: I was thinking that a semantic change to persistent sockets might make it easier for scripts to work "correctly" without bothering them too much. The change is this: If a script doesn't "fclose" it's "pfsockopen"ed socket, it gets closed *for real* when the script ends. I suggest this because I think it would make scripts "just work" in the presence of failures, even if the script coder doesn't completely understand the principle; it makes the transaction boundaries "automatic". The down side is that, if a script forgets the fclose, things work but it doesn't recycle sockets, it makes new ones all the time. The other down side is that for old scripts that never had an fclose in them, they stop getting recycled pfsockets until the fclose is added. I'm going to do *something* about this myself, anyway. I'd really like it if a solution were adopted into the main code base. I think this might generally be a solution to make persistent connections less error prone in PHP. This includes database extensions as well. However it does strike me as something that should be done in a major PHP version .. would it not be less intrusive to offer a pfclose() in a combination with something like use_pfclose()? where by any persistent handles opened after a call to use_pfclose() would require a pfclose() or other be truly closed as per Richard suggestion. In this way the "just works" principle is upheld, and there is no need to change anything in the current behaviour. A developer can actively choose to implement persistence state protection or whatever it might be called outside my kingdom :-) In addition this allows for a possible semantic change of fclose() to allow actually closing persistent connections? [sorry for the noise.] 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] strange autoload behavior
Derick Rethans schreef:
On Thu, 10 Jul 2008, Gergely Hodicska wrote:
exceptions thrown during autoload are ignored.
And one more thing, this is in the manual:
"Note: Exceptions thrown in __autoload function cannot be caught in the catch
block and results in a fatal error."
I think your explanation makes much more clear what happens, maybe it would
worth to upgrade the manual. While the quoted text suggests that that if throw
an exception I just can't catch it and will bubble up to top level and this
cause the fatal error.
You can actually catch it *in* the autoload method, it just wouldn't
bubble out of it.
the manual could do with that tidbit, maybe also the hack for 'getting the
exception out' of __autoload() ...
function __autoload($class)
{
try {
throw new Exception('foo');
} catch (Exception $e) {
self::handleDebug($e);
if (!class_exists($class, false))
eval(sprintf('
class %1$s
{
public function __construct(){ throw new
AL_Exception("Class %1$s not found: %2$s"); }
public function __call($m, $a) { throw new
AL_Exception("Class %1$s not found: %2$s"); }
public static function __callStatic($m, $a) { throw new
AL_Exception("Class %1$s not found: %2$s"); }
}', $class, $e->__toString()));
}
}
which works best when __autoload() isn't triggered by class_exists("Foo", true)
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] simple solution to another namespace conundrum?
Greg Beaver schreef: Derick Rethans wrote: .. The real WTF comes into play when you have a static method that resolves to the same name as a namespaced function, something that absolutely must be worked out prior to PHP 5.3's release. I know a few ideas are percolating about on this one from the people I've talked to on and off-list, I am looking forward to the ultimate resolution. is it just me or does that come down to choosing the wrong namespace delimiter? anything other than '::' would allow both the engine and user code (e.g. __autoload()) to differentiate when a namespace is used or not, no? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Etienne Kneuss schreef:
Hello,
On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.
thoughts?
Didn't we discuss that already? Adding magic to parent:: is not a good
idea, it's very basic language construct and should work simple.
yes!
LSB is
an advanced feature, which probably would be used deep inside library
guts
and thus can use more elaborate syntax.
like static::foo() or if you're really feeling brave fix 'self' so that
it does LSB like it 'should' have done from the start.
changing self:: is not an option as it would break BC.
and the same is not true of parent::? besides which I doubt any same code
would actually break if the semantics of self:: changed, much less than
if parent:: changed at any rate.
It seems natural to think of LSB as a language feature, and so it
doesn't feel right to have it partly implemented as a keyword, and
then fix the problematic part as function.
We already see how call_user_func is painful to use (i.e. with methods
that use references), that same burden will be put on
forward_static_call.
and ironically call_user_func*() is quite often used in hacks that work
round the lack of LSB. forward_static_call() would relegate LSB to a second
rate feature, whilst 'comparable' languages treat it as a core OO feature.
I know that other languages are not the measure of things, but in the case
of
LSB I believe it should be a first class feature of an OO language.
On top of that, by making parent:: forward called class name, you remove
the possibility of doing non-forwarding call to the parent class.
Why would that be no longer possible ? If you want to make a
non-forwarding call to the parent class, you can use
TheParentClassName::foo();.
I certainly don't expect 'parent' to end up making a call to a method
defined in a sub-class.
Also don't we use 'parent' for much the same reason we use '__construct' ?
i.e. so we don't need to know which class is actually the parent defining
the requested method.
rewriting parent::meth() into parentClassName::meth() is like rewriting
class Foo {function __construct() {}} into class Foo {function Foo() {}}
no?
not really, for now, parent is simply an alias of the parent class.
but certainly not an alias for any child class.
please reconsider a either a new explicit keyword (e.g. 'static') or even
making 'self' LSB. I doubt much code would be affected if the semantics of
'self' changed.
another possibility is the keyword 'child', fits in nicely with 'parent'
and 'self' and describes nicely where in the class hierarchy a search
for the method/property will begin.
static::foo() is already implemented in HEAD and 5_3, it references
the class found with runtime information.
child is not a good keyword as LSB may not be to the direct child, it
can go through multiple childs in the inheritance branch, or it can
also reference the current class if no fallbacks occurred.
I understand that, the same is true for self:: and parent:: in that they
go though multiple ancestors (starting at the current class for self::) in
the anscetral inheritance branch, so I find the argument against 'child' weak,
but at the same time not important. I can live with anyname one cares to give
it.
Is this whole discussion pointless? given that you say 'static' has already been
implemented ... doesn't that negate the requirement for forward_static_call()
and
also the need to repurpose parent::?
As for it being slow - how slow it is? Does it really so slow that it
makes real-life application that otherwise would be fast to be slow? Or
it's just "couple more CPU cycles" slow? I suspect the latter - and thus
I don't think speed optimizations belong there.
It's about 85% slower than a direct call. Sure it's not that slow when
measuring absolutely, but we're talking about a feature that will be
typically used in frameworks and libraries, so the amount of calls may
be quite big.
--
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
Re: [PHP-DEV] LSB forward_static_call()
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.
thoughts?
Didn't we discuss that already? Adding magic to parent:: is not a good
idea, it's very basic language construct and should work simple.
yes!
LSB is
an advanced feature, which probably would be used deep inside library guts
and thus can use more elaborate syntax.
like static::foo() or if you're really feeling brave fix 'self' so that
it does LSB like it 'should' have done from the start.
It seems natural to think of LSB as a language feature, and so it
doesn't feel right to have it partly implemented as a keyword, and
then fix the problematic part as function.
We already see how call_user_func is painful to use (i.e. with methods
that use references), that same burden will be put on
forward_static_call.
and ironically call_user_func*() is quite often used in hacks that work
round the lack of LSB. forward_static_call() would relegate LSB to a second
rate feature, whilst 'comparable' languages treat it as a core OO feature.
I know that other languages are not the measure of things, but in the case of
LSB I believe it should be a first class feature of an OO language.
On top of that, by making parent:: forward called class name, you remove
the possibility of doing non-forwarding call to the parent class.
Why would that be no longer possible ? If you want to make a
non-forwarding call to the parent class, you can use
TheParentClassName::foo();.
I certainly don't expect 'parent' to end up making a call to a method
defined in a sub-class.
Also don't we use 'parent' for much the same reason we use '__construct' ?
i.e. so we don't need to know which class is actually the parent defining
the requested method.
rewriting parent::meth() into parentClassName::meth() is like rewriting
class Foo {function __construct() {}} into class Foo {function Foo() {}}
no?
please reconsider a either a new explicit keyword (e.g. 'static') or even
making 'self' LSB. I doubt much code would be affected if the semantics of
'self' changed.
another possibility is the keyword 'child', fits in nicely with 'parent'
and 'self' and describes nicely where in the class hierarchy a search
for the method/property will begin.
As for it being slow - how slow it is? Does it really so slow that it
makes real-life application that otherwise would be fast to be slow? Or
it's just "couple more CPU cycles" slow? I suspect the latter - and thus
I don't think speed optimizations belong there.
It's about 85% slower than a direct call. Sure it's not that slow when
measuring absolutely, but we're talking about a feature that will be
typically used in frameworks and libraries, so the amount of calls may
be quite big.
--
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
Re: [PHP-DEV] Re: How to build a real Trait thing without exclusion and renaming
Hi,
I had a thought about recursion (and self referencing) inside trait defined
functions and the possible issues that might occur due to explicit/implicit
conflict resolution and or aliasing/renaming (i'm not completely
following what the status quo is regarding conflict resolution and/or
aliasing and/or renaming, but it seems all share issues to some degree)
if you wish to ensure that a trait's method specifically *always* calls
a method also defined in the same trait maybe syntax like the following could
be used:
trait Foo {
function A($x) {
if ($x > 0) trait::A($x--);
}
function B() {
trait::A(2);
}
function C() {
self::B();
}
}
here 'trait::' would tell the compiler to always use the actual method
from the trait in question (no idea how this would work in the guts of the
engine ... apologies for my ignorance :-) and 'self::' would refer to whatever
the method in question is as defined in the flatten, resulting class ...
so that 'self::B()' would call 'B()' as defined in the trait only if it wasn't
aliased/renamed/overloaded in the flatten, resulting class using said trait.
again I'm a little lost as to where the concept is at/going with regard to
aliasing/renaming/conflict-resolution ... but afaict the idea for 'trait::'
possibly offers a way out of potential problems (for the developer of a trait)
in any case.
thanks for listening ... sorry for the noise (if it is noise ... Stefan, Lukas
please
be the judge :-)
rgds,
Jochem
Stefan Marr schreef:
Lukas Kahwe Smith schrieb:
class Talker {
use A, B, C, D {
smallTalk = A::smallTalk; // this says that if B, C or D implement
smallTalk, it is ignored
talk = A::bigTalk;
}
}
Well this is not just a different syntax, but an entirely different
approach. In Stefan's proposal one had to explicitly handle every
conflict manually. in your proposal you do not have to do this.
I share this objection. Maybe a somewhat handier solution of my proposal
would be the option to leave out the method name, but I'm not quite sure
whether it is really readable:
class Talker {
use A, B, C, D {
B::smallTalk instead A, C, D; //to be read like: use B::smallTalk
// instead the implementations form A, C, D
}
}
BTW Stefan: Whats the syntax for when you want to override a trait
method with one inside the class definition?
I guess one would use "self::" like so:
class Talker {
use A, B {
B::smallTalk instead A::smallTalk;
self::bigTalk instead B::bigTalk, A::bigTalk;
A::bigTalk as talk;
}
function smallTalk() {
}
}
Hm, personally, I would leave this out. The notion is that class
definitions will override trait methods in any case (even/especially if
traits methods are conflicting). So it would be fine to have this one
implicit. This would also avoid construction attempts like: A::bigTalk
instead self::bigTalk, A::bigTalk;
Kind Regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
John Campbell schreef: On Tue, Feb 19, 2008 at 3:54 PM, Jochem Maas <[EMAIL PROTECTED]> wrote: how about 'possesses' or 'exhibits' - both these words are closer to the natural language usage of 'trait' with regard to a subject. John exhibits a trait Jack possesses a trait a person coming accross 'use' or 'include' in the context of trait attribution may either make assumptions or become confused as to possible changes/additions to the use and/or include functionality, a new keyword that aptly describes the intention will more likely force users to actually find out what it means. IMO, the keyword should be a verb because the code is instructing the class to add a behavior. "possesses" and "exhibits" are adjectives which doesn't make much sense. My vote would be something like "acquire". that's a good point - someone else mentioned 'consumes' which also seems to fit quite nicely. my main point was to use a different keyword to either 'use' or 'include' to avoid misconception, assumptions and basically get anyone not familiar with the syntax to actually RTFM (I'd probably be guilty of glossing over it, if I saw 'include' myself ... ;-) personally I like 'exhibits' ... it sounds right, to me. I don't agree with the argument that non english speaking users would have problems with such a word any more than most other keywords already in use (e.g. 'implements') ... although the spelling of 'possesses' could indeed be rather annoying :-) Regards, John Campbell -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Lars Strojny schreef:
Hi Jochem,
Am Mittwoch, den 20.02.2008, 00:06 +0100 schrieb Jochem Maas:
[...]
if a trait would could contain all the methods required to implement
an interface and a class uses it (the trait) and implements the
relevant interface would it (the interface) be satified?
Yes. The following should work:
interface IFoo {
public function method();
}
trait TFoo {
public functin method() {
echo "Hello World!";
}
}
class CFoo implements IFoo
{
use TFoo;
}
This would be fine.
also might it be an idea to allow a trait to specify that it
implements an interface for the purposes of development (errors
triggered due to incorrect/incomplete implementation)
BUT not have the interface be carried to any classes that use the
trait?
I don't see any sence in it. Why should one generalize an interface of a
trait?
I don't suppose you would, I thinking more along the lines of having it
a developer tool - using implements on a trait would force the developer to
put in the correct methods, it might help a team that had say 1 interface, 2
traits
(which both contain a set of methods that satify said interface) and a large
number
of classes that implement one or other of the traits ... having the trait state
that it's capable of handling an implementation might save some WTF because
compile time errors would happen on the trait if it broke the interface
signature,
rather than on the class ... an interface related error on the class it might
not be
obvious to the developer with regard to the fact that the/a trait the class is
using
was for the purpose of satifying an interface the class states it is
implementing.
I'm thinking that it will proably occur quite often that a fairly simple
interface
will be 'covered' by a trait and that said trait would be used solely for
satifying
said interface implementation and used as such for classes that wish to
implement
said interface.
to quote Troels:
"Class inheritance (The ``extends`` keyword) inherits type
+ implementation. Interface inheritance (The ``implements`` keyword)
inherits type (but not implementation). Traits fill the missing hole
by allowing inheritance of implementation, but not type."
that sounds more than reasonable, but it might be worth offering an aid
to developers during the compile time phase, with regard to the 'link' between
a trait and an interface (assuming you would agree that it's not unlikely that
the two would be used in tandem on occasion) without imposing/implying anything
at run time (i.e. a trait may implement an interface to ensure correctness but
that has no effect on any class that uses it, classes must explicitly state it's
intention to implement an interface)
I may have said something stupid - but given the ability of your average php
user
to stupid things with the functionality offered to him/her, my comments might
aid in thrashing out such details in order to limit a user's ability to do
stupid
things :-)
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Hi,
Lars Strojny schreef:
Hi,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::
trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}
class MyHelloWorld {
use SayHello;
}
$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)
We have discussed that in IRC a bit and a lot of questions remain. The
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
I would propose to not overcomplicate things here and I see no real
advantage in allowing traits to implement interfaces. I think also for
the sake of conceptual integrity separating interfaces clearly from
traits is a good idea: interfaces define structure while traits are
function buckets. A class may use traits, may implement interfaces and
may extend another class. This paradigm is pretty easy to explain to the
user.
if a trait would could contain all the methods required to implement an
interface
and a class uses it (the trait) and implements the relevant interface would it
(the interface) be satified?
also might it be an idea to allow a trait to specify that it implements an
interface
for the purposes of development (errors triggered due to incorrect/incomplete
implementation)
BUT not have the interface be carried to any classes that use the trait? ...
classes
would have to explicitly state that they implement the interface and the fact
that they
use a trait to do so would be irrelevant as far as 'where' the method came from.
interface iFoo {
function doFoo();
}
// causes a compile time error due to missing function
//
trait tOneFoo implements iFoo {
function doBar() { echo "hello"; }
}
// no compile time error
//
trait tTwoFoo implements iFoo {
function doFoo() { echo "hello"; }
}
// using a trait that implements something without actually
// taking on the implementation
//
class cOneFoo {
uses tTwoFoo;
}
// any iFoo method exclusion, aliasing, renaming
// in the following class would cause a compile time error
// due to missing iFoo function unless the class itself
// defined the method(s) in question
//
class cTwoFoo implements iFoo {
uses tTwoFoo;
}
$one = new cOneFoo;
$two = new cTwoFoo;
// outputs: false, true
var_dump( ($one instanceof iFoo), ($one instanceof iFoo) );
something like the above might offer developers desired OO strictness
without actually blurring the boundaries between trait and interface
conceptually.
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
firstly, I'd like to reiterate the general sentiment
that Stefans RFC is blinding! (that's a good thing in this context ;-)
Marcus Boerger schreef:
Hello Lars,
we could even go for include here if we wanted to avoid use as much as
adding a new keyword. Personally I don't mind using keywords for different
stuff as long as it cannot conflict. That is in this case true for both
include and use.
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
a person coming accross 'use' or 'include' in the context of
trait attribution may either make assumptions or become confused as to
possible changes/additions to the use and/or include functionality, a
new keyword that aptly describes the intention will more likely force
users to actually find out what it means.
an another alternative might be 'applies' - which doesn't fit the
natural language usage of 'trait' but does succintly describe what is happening.
just a thought.
marcus
Tuesday, February 19, 2008, 9:31:29 PM, you wrote:
Hi Stefan,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
I'm not sure if the use-keyword is a good idea as namespaces are already
"used". If we use "use" for traits, maybe going back to "import" for
namespaces would be the way to go.
cu, Lars
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Lukas Kahwe Smith schreef:
On 14.02.2008, at 10:07, Lars Strojny wrote:
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Thanks for your support, but this seems counter intuitive. Why should
*set*_include_path() be used to *append* or *prepend* to the include
path? Also learning another mouthful of constants is maybe suboptimal.
Getting used to prepend_/append_...() is easy from my point of view, as
the name is derived from what's currently present (set_include_path()).
Yeah, I agree that if at all I would go with Lars's original proposal.
point taken, I was just thinking out loud really, I didn't even know of
set_include_path() before yesterday. I happily use ini_set('include_path') and
have
no need for the extra functions ... but someone wrote them, someone might like
them
and I figure offering an idea (however stupid - heck of got so many ;-)) can't
hurt
(anything apart from my meager reputation)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Strojny schreef:
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye:
[...]
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
[...]
I don't think we need two new functions for:
Sure?
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
See: prepend_include_path('/some/path');
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path' );
See: append_include_path('/some/path');
Think about reading the code. What's easier to grasp for you?
Introducing this functions is meant to make a) code better readable, b)
easier to write the code, as most of the time, include path adjustments
are include path appends, so the roundtrip
set_include_path(get_include_path() ...) is not suboptimal.
On the other hand, introducing this functions will not very likely
introduce a lot of new bugs, so the maintenance overhead is lower than
the value this functions bring (of course this is my POV, as I wrote
that patch :-)). And, for the record, I promise to provide fixes for
each the related bug (everyone heard that?).
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] expose PHP version details as constants
Pierre Joye schreef:
Hi Jochen,
On Feb 12, 2008 12:22 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:\
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:\" is the root directory on the
volume?
this is what I thought, kind of, but I was just proposing what the OP
was expecting.
the OP?
it does make one think a little about the small discrepancy with regard to
whether the slash is 'appended' or not depending on whether the dir is
the root or not:
php -r ' echo dirname("/Users"),"\n", dirname("/Users/foo"),"\n"; '
/
/Users
You ask the directory name of a path. In the first case, you ask the
directory name of the path /Users (or /Users/), it is "/". The
directory name of the path "/Users/foo" is "/Users". Everything works
as expected as far as I can see.
I agree, I was merely pondering out loud, no problems as such.
which means one cannot blindly say:
include __DIR__."/somefile";
Little notice: OSes without volumes will work smoothly. For those with
volumes (windows, novell afair) willl use the current volume.
although that's probably moot because my experience is that extraneous slashes
in a path are, afaik, always ignored. i.e. /foo//foo//foo == /foo/foo/foo,
so really there is nothing to see here.
Yes, PHP is very tolerant (and brought us some headaches too in the
pasts :). It is also tolerant with \ or / usages.
I can imagine it has caused headaches for dev's working with the underlying
implementation ..
I for one am grateful it's so tolerant ... more than once have I noticed some
badly defined
paths working without a problem, months after the code was originally written.
3 cheers for tolerance :-)
Cheers,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] expose PHP version details as constants
Sebastian Bergmann schreef:
Jochem Maas schrieb:
Output:
C:\
Is this intended?
Yes, or what would you expect?
possibly 'C:' ?
Is "C:" not the volume whereas "C:\" is the root directory on the
volume?
this is what I thought, kind of, but I was just proposing what the OP
was expecting.
it does make one think a little about the small discrepancy with regard to
whether the slash is 'appended' or not depending on whether the dir is
the root or not:
php -r ' echo dirname("/Users"),"\n", dirname("/Users/foo"),"\n"; '
/
/Users
which means one cannot blindly say:
include __DIR__."/somefile";
although that's probably moot because my experience is that extraneous slashes
in a path are, afaik, always ignored. i.e. /foo//foo//foo == /foo/foo/foo,
so really there is nothing to see here.
good idea btw having __DIR__, it makes sense and rounds off the other magic
constants nicely.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] expose PHP version details as constants
Pierre Joye schreef: Hi Edward, On Feb 12, 2008 4:30 AM, Edward Z. Yang <[EMAIL PROTECTED]> wrote: Hello all, I was documenting the __DIR__ patch, and I ran across some curious behavior when the PHP file was in the Windows filesystem root: C:\test.php Output: C:\ Is this intended? Yes, or what would you expect? possibly 'C:' ? Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a "final" decision
-1 Pierre Joye schreef: 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
Re: [PHP-DEV] Location in php's source for ini-values
ehl lhe schreef: I've run into the same thing in the past, ended up moving to virtual machines in order to circumvent ... BUT ... I found something which can apparently work in this particular case. have a google for 'mod_macro' ... from what I read it will do what you want and it'll save you having to hack the php source. well, I know about mod_macro - and also have it in use, but it doesn't really help, since it does not solve the problems I've got here. funny, a chap in the forum on the following URL states that he is using mod_macro to do exactly what you want (afaict) namely set open_basedir on a per request basis in a dynamic vhost: http://www.apachelounge.com/forum/viewtopic.php?p=7863 I require mod_vhost because I've got several if the above url is not telling the truth then maybe an alternative is mod_vhs: http://www.oav.net/projects/mod_vhs/ I don't know it personally but a quick scouring of the page reveals some php specific stuff for setting per request ini settings, mod_vhs itself being, it seems, an alternative to mod_vhost thousand vhosts in my config, which slow down apache everytime it reloads it's configuration, which is required about 3 times every hour since the configuration changes in this period. So mod_vhost can solve that problem, because in my case no apache-reload is required then. This reload makes the server unreachable for about 1-2 minutes, that's just way too much downtime - 3 times a hour.. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Location in php's source for ini-values
ehl lhe schreef: hi steph, well, i'm trying to use apache's mod vhost_alias, which doesn't allow to use e.g. php_admin_value open_basedir /some/path/%2 ...which means that %2 is usually replaced with a part of the requested URI, but that does not work, such variables like %2 are interpreded for vhost_alias-values such as VirtualDocumentRoot only. I've run into the same thing in the past, ended up moving to virtual machines in order to circumvent ... BUT ... I found something which can apparently work in this particular case. have a google for 'mod_macro' ... from what I read it will do what you want and it'll save you having to hack the php source. I'm modifying php's source anyway for other purposes and so i thought it might be a pretty good solution to do so for this issue too, by taking that ZEND-variable which defines the location of the php-script it's beeing executed from. if it is for example: /var/www/users/tom/index.php then I thought to take the part between users/ and the following / to identify the user (tom in this case) - and then to set a static open_basedir-value at the location where php finally sets it in it's source. as far as i figured out, main/main.c sets the default values and main/php_ini.c seems to read them from the php.ini. as far as open_basedir is not overwriteable by .htaccess later, this might be the right location to modify it... regards, ehl _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] nowdocs again
Pierre Joye schreef: On Jan 30, 2008 3:00 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote: On 30.01.2008 16:41, Dmitry Stogov wrote: The final nowdoc patches are attached. I'm going to commit them on Thursday in case of no objections. So the current syntax is $var = <<<'TEXT' text 'TEXT'; am I right? I believe it's far from readable and clear and I suggest not to add it until we have a better syntax. What do you suggest? :) someone suggested this: $s = <<<~TEXT foo bar qux TEXT; which does seem more readable and/or less confusing than quoting the delimter. or maybe use an unbalanced single quote: $s = <<<'TEXT foo bar qux TEXT; which could have a complement of $s = <<<"TEXT foo bar qux TEXT; the '"' being optional and having the same meaning as heredoc syntax as it stands now. having an unbalanced quote would leave less room for someone to ask why a string literal was used (because it's not a string literal without the second quote), additionally using single/double quote identifiers likens the here* syntax to the behaviour of single and double quoted strings with regard to variable interpolation. just a thought. Also looking at the discussion, I can see only 6 people involved (including Dmitry), which most likely means nobody is really interested in that "nowdoc" and this is yet another reason not to add it. P.S. I personally see no need in such thing at all. I'm pretty sure there is more people interested. I find nowdoc very handy and is the perfect complement to heredoc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Protected static props redeclared as public share value across classes
Marcus Boerger schreef:
Hello Robin,
I checked it out in more detail and it is indeed broken as in it is not
consistent:
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class B extends A
{ protected static $p=2; } ReflectionClass::Export("B");'
-> works == 2 properties
-> but should fail because of changed value
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { protected static $p=1; } class B extends A
{ public static $p=2; } ReflectionClass::Export("B");'
Fatal error: Cannot change initial value of property static protected A::$p in
class B in Command line code on line 1
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { public static $p=1; } class B extends A {
protected static $p=2; } ReflectionClass::Export("B");'
Fatal error: Access level to B::$p must be public (as in class A) in Command
line code on line 1
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class A { public static $p=1; } class B extends A {
public static $p=2; } ReflectionClass::Export("B");'
-> works == 2 properties
-> but should fail becasue of changed value
So we need to fix this.
I don't get the 'but should fail because of changed value' - isn't the changed
value akin
to overloading a method - where the body of the method changes (obviously)?
I also surmise that the issue becomes more tricky if you consider late static
binding,
which I am assuming is still scheduled for php6, and as such it may be worth
holding back
making a fix until it is clearer what the larger ramifications are?
marcus
Monday, January 28, 2008, 4:18:50 PM, you wrote:
Hi Marcus,
Thanks for the prompt reply and explanation. I have some further
questions though:
If the base class had the property defined as private
then the property is private to that specific class and not directly
accessible by derived classes that is it's name gets prefixed with the class
name.. So in:
class A { private static $p; } class B extends A { private static $p; }
we have two different properties:
Understood. But if we have two separate properties for the reason that
A::$p is not visible to B, then how about these cases?
class A { protected static $p; } class B extends A { protected static $p; }
class A { public static $p; } class B extends A { public static $p; }
In both of those cases, A::$p is visible to the derived class, but the
re-declaration results in A::$p and B::$p being two separate
properties (see pastebin.com/fca2cd5b and pastebin.com/f4f94b32d for a
demonstration). This is one of the reasons I find the case where we
end up with only one property value to be surprising.
Another reason is that, as illustrated in my previous post, PHP's
behaviour doesn't seem to correlate with the inheritance rules of
other languages I'm familiar with: you always end up with two distinct
static properties in Java, C++ and C# (though of course I understand
this fact on its own is does not mean PHP is wrong :).
Lastly, with overridden static methods, PHP always yields two distinct
methods, regardless of the visibility modifiers. See
http://pastebin.com/f27f009c4 . Granted, with methods any other
behaviour would be very odd indeed, but it does emphasize an
inconsistency between method and property inheritance rules in PHP.
So for now I continue to feel this is a little strange. Any further
explanations would be greatly appreciated. :)
Thanks,
Robin
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP]
Tomas Kuliavas schreef: me, I'm all for dropping unicode.semantics - Antony makes strong points and it can only help the quality of the product if exceptions and switchable functionality is kept to a minimum. from a developers POV the same is true, additionally 'forcing' unicode on the masses will increase awareness and speed up the uptake of the necessary skills (imho). +1 for Antony's proposal over noisy standard string functions that require strict unicode/binary type checks - worse than php5 locale functions that report success even when locale is invalid - worse than php5 php6 is not even alpha stage yet AFAICT. lets give the devs a chance before jumping on these kinds of issues, no? can't use same code in php5 and php6 - bad. Instead of making your code backwards compatible, you are forcing others to maintain two incompatible codebases. unicode.semantics is not php.ini only, it is PHP_INI_SYSTEM. same difference. I don't see how 'having' to maintain two incompatible versions for different [major] php versions is effectively any different to maintaining two incompatible versions due to the unicode.semantics switch. given past experience with attempts to offer users a compatibility switch (as Antony pointed out) it is very likely that the result will be that you'll actually end up maintaining 3 incompatible versions: php5, php6 US=on and php6 US=off. another point to consider is that more than likely the take up of php6 will not be very fast - comparable to php5's take up in the face of php4. given that this is likely to be the case you will probably have a long grace period where you'll only need to support php5 - time which can be spend developing towards php6 without the hassle of having to deal with production users, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array syntax []
-1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Stanislav Malyshev schreef: >> In a way this is true, but I look at it this way. Some languages are >> strictly typed, some are dynamically typed. PHP can have the best of >> both worlds by having optional strict typing where desired, as well as > > I do not believe trying to both eat cake and leave it intact would do us > well. Mixing strict and non-strict code would be a nightmare. possibly like the nightmare that namespaces will give us in there current form? I mention it because use of typehinting seems alot more voluntary and less intrusive (when one encounters it in 3rd party code) than namespaces will be. > Absence of > static type control (necessary for interpreted language) would make > strictly typed code less, and not more stable. Add performance penalty > from type checking and effort would be required from PHP newcomers to > understand two code models instead of one - and you get the worst of newcomers? or newbies? the level of entry is being raised in all sorts of areas whether you like it or not as a by product of making php more suitable to enterprise level development. it's merely a case of not being able to please everyone all of the time (or of not having your cake and eating it) > both worlds, not the best. why do we then have typehinting for objects? and more recently arrays? I also seem to remember (forgive me if Im mistaken) that you we're a proponent for the increases in strictness surrounding various things related to OO. that feels rather hypocritical at some level. > >> Strict typing allows very little room for type conversion. This is >> optionally hinting the desired type of a function parameter. > > That's not what I am hearing here on the list. you implied in another post that php should have some kind of structured direction. how about a language spec and a formal functionality proprosal/acceptance mechanism? (preferably one that didn't allow major changes like the inclusion of namespaces into a minor release) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
Tomi Kaistila schreef: >> Broken record perhaps? I am getting a bit tired of this "just use Java >> argument", it's perhaps even a bit arrogant. From what I read there is >> plenty of people that want type hints for static types - there's a few >> patches out there, it doesn't slow down the general case. So why should >> we *not* add it? (And yes, I changed my mind) > Same here. I am getting generally tired of the attitude some > politically-correct people seem to have about writing "javaish" code. What > the heck is "javaish" code anyway? Most features that exist in both PHP and > Java can also be found in myriad of other languages and it has so far not > stopped the development team from adding a feature when it is clearly useful > and (most importantly) desired an uncounted number of people. > > In fact those who oppose the feature seem only capable of doing so with > hair-splitting rhetorics. > >> am I the only one to consider E_FATAL (as generated for class typehints) >> makes type hinting useless - given that there is no compile stage at which >> to catch typehint related mistakes > In principle you are correct. But E_FATAL errors should not happen in a > program that is in production use. If they do, it seems someone was not doing > their job properly. you are right, they shouldn't - but who can say that every execution permutation has been tested and hammered shut in their code (let alone someone else 3rd party lib or extension)? in practice mistakes do occur - and saying someone has not been doing their job properly is little consilation to the end user, client or manager (who gets a white screen of death) ... there is no reason not to let the application try to gracefully handle a mistake like this ... besides I was under the impression that E_FATAL meant the engine was in an unstable state and was unable to continue execution - I don't see why a typehint failure would cause an unstable engine state (rather the engine is presuming that the code is *going* to create an unstable state if it were to continue ... which is not very helpful in my book). > > I am not convinced throwing an exception is the best course of action. If it > was, you might make the argument that all errors should be exceptions, while > traditionally it is the other way around and changing that is beyond the > scope of this thread. I actually like the current "division of labor" when it > comes to error handling. > > When PHP detects an error, it should actually be an error. Exceptions are > convenient for the code that you as a PHP developer can throw. They are > especially a blessing when writing library code. That way exceptions work for > the error management, instead of competing with it. > > I say use E_WARNING at this stage. If there is some large redecorating with > PHP's error handling in the future, it can be changed then. that is a very sane arguement. I'll have to concede :-) > > Tomi Kaistila > PHP Developer > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
am I the only one to consider E_FATAL (as generated for class typehints) makes
type hinting useless - given that there is no compile stage at which to catch
typehint related mistakes. which means there is no way to trap the issue and
offer some useful/user-friendly feedback to the user (in practice it usually
means the white page of death for a site visitor)
E_WARNING also is not much better given that one would assume the
function/method
that was passed incorrect variables (according to type) wouldn't run.
would an exception not be the most suitable thing to generate on a typehint
error?
to me anything else makes typehinting in production environments pretty much
unusable
unless one write code like so:
function foo(Foo $f) { /* do foo stuff */ }
$f = getFoo();
if ($f instanceof Foo) {
foo($f);
}
now the issue with such code is not that it is alot more verbose than might
strictly be needed but that the instanceof statement makes the typehint rather
superfluous.
Tomi Kaistila schreef:
> Yes it seems PHP will omit E_WARNING if you omit an argument.
>
> (Had to actually check.)
>
> Not a bad choice for an error and probably also easier to manage when you are
> dealing with complicated error handling in large applications.
>
> I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
> simple fact that they are ignore by a major portion of PHP developers and to
> use them would prompt a high risk of people writing bad code.
>
> Also, now that you mentioned abstract classes, type hinting might also be
> useful with interfaces.
>
> Tomi Kaistila
> PHP Developer
>
> On Thursday 03 January 2008 19:21:21 you wrote:
>> I think E_WARNING would be appropriate. That's what happens when you
>> omit an argument to a function right?
>>
>> And about function return type hinting, I don't think it would be as
>> useful as parameter type hinting, but it would be useful. Mostly for
>> stuff like declaring an abstract function in a parent class that must
>> return a certain type.
>>
>> class a {
>> abstract public function getNumber() returns int ;
>> }
>> class b extends a {
>> public function getNumber() {
>> return rand() * 3463 ;
>> }
>> }
>> class c extends a {
>> public function getNumber() {
>> return 'I\'m going to mess everything up by returning a
>> string.' ; //
>> Would cause error with type hinting.
>> }
>> }
>>
>> On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
>>> Hello everyone
>>>
>>> I figured I would bring my opinion in to support of Sam's request for a
>>> more complete type hinting feature. Namely I am interested in the support
>>> for hinting scalar types on function and method arguments and I am sure
>>> it is safe for me to say that I speak for a lot of people. Most people
>>> that I know find the current type hinting, while useful, ridiculous
>>> because it looks like the job was left unfinished for whatever abstract
>>> reason.
>>>
>>> In my opinion type hinting should definitely be allowed for scalar
>>> values. As for return types, I am not so sure. So far I have found no use
>>> for such a feature in my own code, so I won't comment on it. If it is
>>> added, I welcome it for those who find it useful but if it is not added I
>>> will not loose sleep over it.
>>>
I was thinking at something along the lines of objects also for
instance: $i = new Integer(33);
>>> After my own experiments with the subject I concur that while it can be
>>> made to work, it is not only a bad idea (for the reasons mentioned
>>> earlier) it is also redundant and just unnecessary. There is a lot better
>>> way to accomplish the same and that by allowing scalar values to be
>>> hinted. It is simpler, cleaner, and easier to implement.
>>>
What if type hinting just generated an E_NOTICE. Nothing more for the
time being.
>>> Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
>>> if I write a piece of code that hints that the argument for a-whatever
>>> method needs to be an integer it seems useless if the user of my library
>>> can avoid the issue just by supressing lesser errors and those who do not
>>> need to write extensive error handling code to respond to this sort of
>>> error (if they indeed deem it necessary to do so).
>>>
>>> While hinting is, and should remain, optional, when it is used it should
>>> be enforced. After all the user of my library has the option to dump it
>>> and go for another library that does not force types. That is the beauty
>>> of having options.
>>>
>>> Tomi Kaistila
>>> PHP Developer
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Maybe a problem? undetected name clash makes static method unaccessible through outside static reference
Greg Beaver schreef:
> Martin Alterisio wrote:
>> Consider the following code:
>>
>> foo.php:
>> > class test {
>> public static function foo() { echo "I'm foo in class test\n"; }
>> public static function foo2() { self::foo(); }
>> }
>> ?>
>>
>> foo2.php:
>> > namespace test;
>> function foo() { echo "I'm foo in namespace test\n"; }
>> ?>
>>
>> test.php:
>> > include 'foo.php';
>> include 'foo2.php';
>> test::foo(); // I'm foo in namespace test
>> use test::foo as dummy;
>> test::foo(); // I'm foo in namespace test
>> test::foo2(); // I'm foo in class test
>> $test = 'test';
>> $test::foo(); // I'm foo in class test
>> call_user_func(array('test', 'foo')); // I'm foo in class test
>> ?>
>>
>> Please review the following observations:
>>
>> There's a name clash that goes undetected: test::foo refers to both a
>> namespaced function and a static method.
>>
>> Once the clash occur there's no way to refer to the static method through a
>> static reference, except when within the class scope where you can refer to
>> the method through self::
>> The static method remains partially hidden by the namespaced function.
>
> Don't forget about ::test::foo() which refers to class test, method
> foo(). However, this is an issue, and one of the main reasons I dislike
> putting functions and constants in namespaces, as this ends up sort of
> like OO without inheritance and confuses the issue of static methods as
> you pointed out.
>
> However, having said that, in my experience, developers either use
> functions or OO, very rarely mixing the two on an extensive basis, and
> so name collisions become much less likely between static methods and
> namespaced functions.
why exactly should we need to have this ambiguity and possible naming collision?
I thought namespaces are about avoiding naming collisions?
>
> Greg
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: [PHP] php with threaded MPM problem ?
Brian Moon schreef: > Rashmi Badan wrote: >> The test was trying to load mod_php between graceful restarts, i.e start >> apache without mod_php, then modify the config file to load it and do a >> graceful restart. This clearly fails because mod_php loads only on the >> second load within apache. It does this by setting some pool user data in >> the beginning of sapi_apache2.c:php_apache_server_startup(). So I'd >> have to >> do two graceful restarts for it to take effect. > > PHP has never worked well with graceful restarts. Frankly, there are > some Apache things that never seemed to do well either. I gave up on > graceful restarts 8 years ago. Maybe they are better now. could anyone else confirm/deny that this is [still] the case? (i.e. avoid graceful restarts when using php) > > Just do a full restart and all will be fine. If this is so mission > critical that you can't be down for 2 seconds, you need more servers and > load balancing. Or if you are restarting your server that often, > something else is likely wrong. > > As for changing the code, a patch that does not break anything would be > the way to approach the list. It was probably done the way it is done > for a reason. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internals read-only
Richard Quadling wrote: > On 13/12/2007, Jochem Maas <[EMAIL PROTECTED]> wrote: >> 1. most people reading the internals list already subscribed to general >> 2. general is in no way suitable for the kind of discussion currently >> occuring on internals - the difference between internals and general is akin >> to the difference between fine art and drawing with crayons. > > I'm SURE you are not implying that those that use the PHP language > (rather than the developers of the PHP language) are some how more > infantile and can only use crayons rather than wielding the fine > brushes that create the art of the language itself? no not at all, I was implying that the gross of the traffic on generals are questions related to problems people have with stuff like register_globals - aka full-on noobs, nothing wrong with that and actually I quite like to help most of them (as do a fairly small but very active group of experienced, well-armed phpers) ... it's just not the place to discussion the finer/complex details of php functionality implementations. imho. the crayon metaphor was actually an in-joke for the guys who are regulars on the generals list. > > I would say that we (those that write PHP code) are your clients and > as the client is __ALWAYS__ right, you should drop namespaces, add in this context I am the client - and I have been proven wrong many a time, even then I'd rather not have my voice taken away completely ... and you never know if I might one day say something useful. ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internals read-only
Jani Taskinen wrote: > On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans wrote: >> To to get back to the point of the noise on the lists - it's getting out >> of hand, and I am afraid that if we don't solve this any time soon, the >> lists will be useless for any sort of decent discussion and promoting >> even more secret cults. > > There's already public list, it's called "php-general". So just > unsubscribe all people from this list and subscribe all @php.net addies > only. that's doesn't seem like a good idea imho. 1. most people reading the internals list already subscribed to general 2. general is in no way suitable for the kind of discussion currently occuring on internals - the difference between internals and general is akin to the difference between fine art and drawing with crayons. if the consensus amongst devs is that no-one other than devs have any right to offer input to internal implementation discussions then make internals readonly for every other than the devs. personally I think that just doing that is not good for the cause at all - there are plenty of people using php that do offer worthwhile feedback to implementation discussions, excluding them will just lower the quality and usefulness of the stuff your releasing. my suggestion would be to split internals into 2 lists internals - readonly except for devs internals-discussion- anyone may post of course this would only work if devs actually took the internals-discussion list seriously which given the current sentiments floating about seems unlikely, don't get me wrong I understand your sentiment! alternatively moderation could be applied to internals, whereby dev can post unmoderated and everyelse has to go through a filter - ofcourse you have to find a couple of people to do the moderation, my guess is that it would not be too hard to find a few intelligent, interested & knowledgable people from within the php community who would be willing to help the devs in this way. I would hazard to say that php is becoming a victim of it's own success in this regard - to really tackle the issue would probably require the implementation of a more structured proposal/implementation/release process ... I will grant that that is a mammoth task to undertake! > > Another solution is to simply stop discussing things and just commit. :) somehow I doubt that that strategy will help to improve php's reputation for stability and usefulness (percieved or otherwise) especially with regard to the 'enterprise market' which is increasing being aimed at. > > Same worked for bugs: my blood pressure got normal again since I've > ignored the reports. :D > > --Jani > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Namespace resolution
Stanislav Malyshev wrote: >> You would now have to go through all ten autoloaders before you can >> decide that no userspace class DateTime exists in any namespace, and >> thus the PHP internal class DateTime may be used. > > Even one autoloader is bad enough to not even have to consider the case > of ten autoloaders. Remember, autoloader is filesystem access. > Filesystem access on each class mention is a disaster. it's just slow. regardless namespaces need to work in conjunction with autoload in a perdictable and understandable manner ... I get the distinct impression that namespaces+autoload is going to introduce a serious wtf factor. given that autoload is 'out there' and the raison d'etre of namespaces is, amongst other things, to enable better leveraging of third party code namespaces must concede to autoload if only for the reason that one is garanteed to have to deal with both together at some point if one is ever to seriously make use of third party namespaced code. as an aside, is autoload becoming the new 'magic_quotes'? > >> like a fool when you're tired of coming up with arguments. You very >> well know I meant "import". Reply to the suggestion in a respectful >> manner, or give it a miss. > > I'm afraid I still do not understand what did you mean. Could you > explain in more detail? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
Stanislav Malyshev wrote: >> based on the reactions it has been recieving I would disagree. that is >> not to say >> that completing the baking process would not result in a wonderful >> functional addition >> to the language. I'm just advocating putting it on the backburner >> until the cooking >> time is complete. > > So far I have yet to see an improvement proposal except for: > 1. Let's do it with braces > and > 2. Multiple namespaces per file. > > Neither of these doesn't make the concept "half-baked" if it's decided > on either side - first being tiny syntax detail blown entirely out of > proportion and second being technicality of little use for most people > except for sites engaging in exotic performance practices they better > didn't. Both do not have much to do with the conceptual level.\ even after I explained my [possibly dubious] use of the word "half-baked" you seem to feel compelled to focus on the negative emotions the word triggers. "half-baked" was the wrong word. you can't use a concept unless it's implemented - and we are arguing the implementation [details] not the concept. I believe that the implementation needs a little ironing out ... what's the harm in taking the time to do this? or at least taking the time to let consensus take hold? > >> you have metrics to back that up? of course not because it's a >> completely subjective > > Metrics of what? metrics that support your argument that namespaces will make code more maintainable, offer better structure and cleaner code. it was a rethorical question obviously because what consitutes better structure, code cleaniness and maintainability are subjective to say the least. I don't expect you to come up with any and I agree that namespaces do have the potential to help in this area. > >> I agree that namespaces pontentially offer a tool that allows >> developers to create >> clearer structure in their code but given that it's only a potential >> why not take a time > > Sure it's only a potential - there's no released PHP version with > namespaces. Only way to hammer out practical namespaces issues is to > start using them, and that doesn't happen until - well, we start using > them. it remains nothing more than a pontential even after release. in the same way that php itself has the potential to enable web developers to be fast and flexible in their implementations. this thread is proof enough that practical issues can be raised and hammered out before release .. granted the chance that you cover every edge case is unlikely. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
Stanislav Malyshev wrote: >> +1 for putting namespaces on the backburner and taking the time to >> get it 100% right ... > > What's "100% right"? Any proposals (besides braces)? I'll take a guess that you put alot of effort into the namespace implementation, that's the only reason I can think of that your taking it all so personally and being rather vitriol. for the sake of your health take a step back and breath my friend. you are not the car you drive, the clothes you wear or the namespace implementation you created :-) > >> apparently people keep 'flogging this horse to death' because they are >> not >> convinced by your wisdom with regard to this decision - they may be >> idiots (me included) > > I never talked about "idiots". I know smart people can have different > opinions, and - oh horror! - some may have wrong or mistaken opinions > too, and that doesn't make them idiots. How about you? it was a self effacing comment. I think it's safe to say that compared to most of the php devs, I, and people like me could be considered idiots at least as far as developing is concerned .. it's all relative besides which the key words were "may be". > >> actually that is not true - a halfbaked concept is pretty much >> garanteed to give you >> and the users of your product more headaches than no implementation at >> all. and > > This concept, however, is not "halfbaked". based on the reactions it has been recieving I would disagree. that is not to say that completing the baking process would not result in a wonderful functional addition to the language. I'm just advocating putting it on the backburner until the cooking time is complete. "halfbaked" is probably the wrong word - it has negative conatations that I didn't mean to imply. > >> besides possibly having to type a little less, there seems to be >> nothing namespaces would >> give us [in it's current form] that we cannot achieve already ... with >> the bonus that > > Yes there is. More structured and clean code. you have metrics to back that up? of course not because it's a completely subjective point of view - and many people seem to think that there is no real gain in this respect, besides there is nothing to stop me writing namespaced spaghetti. I agree that namespaces pontentially offer a tool that allows developers to create clearer structure in their code but given that it's only a potential why not take a time out to hammer out more details, get more consensus and work out the details of where namespacing should go in terms of functionality with the hassle of having to worry about BC. > >> conversly - when namespace functionality is released, every developer >> will be confronted >> with any problems they might bring with them, at some stage, because >> there will be third >> party code out there that uses namespaces (code which for the sake of >> argument one would >> be required to use under some circumstances). > > These problems being? no longer having the option of bundling files for performance reasons is one example, personally I have never done anything like that but apparently other people do and with positive results for their applications - to me it seems that forcing such a restriction on these people is against the pragmatic philosophy that [hopefully still] drives php, and is rather artificial. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
+1 for putting namespaces on the backburner and taking the time to get it 100% right ... Stanislav Malyshev wrote: >> some people like a "misguided" implementation of namespaces. The idea >> of namespaces is to prevent collisions in USER land code, not turning >> internal PHP classes into a pile of goo. > > Yes, idea of namespaces is not to turn PHP classes into a pile of goo. > But what's your point? > >> I don't quite understand why allowing multiple namespaces is such a >> big issue, however - it won't solve the naming collision issue. > > I'm sorry, I don't understand what you mean by "multiple namespaces" - > multiple namespaces per file? I object to allowing it for reasons having > absolutely nothing to do with naming collisions, as anybody bothering to > actually read what I wrote would immediately know. this implies that your objections to multiple namespaces per file is valid whereas objections to the limitation are invalid. apparently people keep 'flogging this horse to death' because they are not convinced by your wisdom with regard to this decision - they may be idiots (me included) but they are the majority of your users, so it seems. > >>> That's because namespaces are not executable blocks. >> >> Neither are classes. > > Your point being? that therefore your argue that "namespaces are not executable blocks" doesn't hold up unless your willing to state the inconsistency is one of your design goals. > >> No, but, do you really need to have such long names? And besides that, > > Yes. Such names are hard fact of life, I have seen them in many > applications and libraries, and I have heard developers to complain > about it. developers will complain, it's in their blood, nothing anyone will ever produce will change that ... somewhere in the future when all code is created without the intervention of man .. even then there will still be a compiler complaining. > >> you *have* to keep repeating them in every file you'd want to use them - > > Once per file, yes. Much better than having to spell out all the long > names every time. > > > Just saying "Yes, they are" is not a very good argument - actually, it's >> not an argument at all. > > No more and no less than "I wonder if they are useful, let's just delete > them". actually that is not true - a halfbaked concept is pretty much garanteed to give you and the users of your product more headaches than no implementation at all. and once the genie is out of the bottle your stuck with it - with all the BC implications of having to support functionality people would rather see changed. besides possibly having to type a little less, there seems to be nothing namespaces would give us [in it's current form] that we cannot achieve already ... with the bonus that users are currently not restricted in the way they organize/rollout their code, at least with regard to 'bundling' of files. > >> Actually, it's exactly the opposite, as I avoid naming colissions >> (point 1), I don't need to import every class I want to use (point 2), >> and can group all my classes together in one file (point 3). > > Of course, if you don't want to hear about namespaces, nobody can force > you. However, all of your points (avoiding naming collisions, not > needing to import every class you want to use and ability to group > classes together) is exactly how namespaces work right now. If you > refuse to learn about it, it can't be helped, however that just means > you deny yourself a very useful tool. conversly - when namespace functionality is released, every developer will be confronted with any problems they might bring with them, at some stage, because there will be third party code out there that uses namespaces (code which for the sake of argument one would be required to use under some circumstances). > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] late static binding php6
Stanislav Malyshev wrote:
>> Rest assured that this is not the bad kind of 'more complex' I believe
>
> I'm afraid I must disagree. The feature that was missing was to know the
> true calling class name. That was implemented. You can build from it,
> there's no need to add further complication to the language. You can
> easily find out the calling class for static call, you can easily find
> it's parent, provided one exists, you can easily call any method of this
> class.
class A {
static function find($id) {
// lets try and find a 'something'
}
}
class B extends A {}
// I'd like a 'B' please bob.
$b = B::find( 1 );
are you saying that A::find() can tell that it was called as B::find() ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Dmitry Stogov wrote: This is an implementation of Stas idea. 1) Look for existent class in current namespace 2) Look for existent internal class 3) Try to autoload class from current namespace both ways have a wtf factor in that class with names matching 'internal' class names behave differently. afaict you would not be able to autoload class Exception from within namespace Foo in the example below. currently one cannot create classes named the same as 'internal' classes ... obviously. I would consider making internal class names illegal in namespaces. this would be consistent simple and clear. also I don't see what would be gained from being allowed to do: Thanks. Dmitry. -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Monday, August 27, 2007 9:49 PM To: Dmitry Stogov Cc: 'PHP Internals List' Subject: Re: [PHP-DEV] Namespaces and __autoload() In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to __autoload() that say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions. There's two problems here: 1. On each access to internal class, like Exception, SPL classes, DateTime, reflection classes, etc. - we'd have call to autoload and subsequent disk access, maybe more than one if we have include path. Performance of it would be awful. 2. All libraries having autoloaders would have to rewrite them to support the new mode. I would propose different solution. When we have unresolved unqualified name, we do the following: 1. Check if we already know such class in namespace at compile-time. If so, it's resolved. 2. If not, will be resolved at run-time. 3. At run-time, check if we know such class in namespace now. If yes, it's resolved. 4. If not, check if we know internal class with such name. If yes, it's resolved to internal class. 5. If not, try to autoload this class. If autoloading fails, it's the undefined class error. This rule is a bit more complex, but allows to resolve common cases without extra filesystem accesses and allows to keep autoloader without modification. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
Jochem Maas wrote: > Lukas Kahwe Smith wrote: >> Jochem Maas wrote: >>> Pierre wrote: >>>> On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote: >>>> >>>>> There must be a reason to upgrade to a new PHP version (usually >>>>> features, maybe performance increase etc.). But there also must be no >>>>> reason not to upgrade. But you all know this, it has been said before. >>>> Namespace is one _very_ important reason. If we need a "marketing" >>>> argument for PHP6 outside unicode, it is the one. I would also like to >>>> do not backport it (but we can backport it as well, my main problem is >>>> only this flag). >>> late static binding is another reason (are we still going to get that?) >> well .. last I heard we are still stuck on this one, since it would >> require expanding the general zval structure. > > oh, I see (well kind of), does this mean it may get taken off the table? > or is it slated as definite (assuming a satisfactory implementation can be > created)? I'll answer myself, as I've just come across Derick's meeting notes ... it's seems LSB is in and Marcus has the honor of suggesting an implementation. I wish him well with that and hope he succeeds! if he does I'll have to make him my hero for day. :-) and if he doesn't then at least he tried to do what I wish I could. > > sorry to be a bore about LSB, it's just that it's the thing I look forward to > most :-), I have missed it since php5 was still in RC and I really believe > that > LSB would improve php's OO model. > > thank you for your feedback, > regards, > Jochem > >> regards, >> Lukas >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
Lukas Kahwe Smith wrote: > Jochem Maas wrote: >> Pierre wrote: >>> On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote: >>> >>>> There must be a reason to upgrade to a new PHP version (usually >>>> features, maybe performance increase etc.). But there also must be no >>>> reason not to upgrade. But you all know this, it has been said before. >>> Namespace is one _very_ important reason. If we need a "marketing" >>> argument for PHP6 outside unicode, it is the one. I would also like to >>> do not backport it (but we can backport it as well, my main problem is >>> only this flag). >> >> late static binding is another reason (are we still going to get that?) > > well .. last I heard we are still stuck on this one, since it would > require expanding the general zval structure. oh, I see (well kind of), does this mean it may get taken off the table? or is it slated as definite (assuming a satisfactory implementation can be created)? sorry to be a bore about LSB, it's just that it's the thing I look forward to most :-), I have missed it since php5 was still in RC and I really believe that LSB would improve php's OO model. thank you for your feedback, regards, Jochem > > regards, > Lukas > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
Pierre wrote: > On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote: > >> There must be a reason to upgrade to a new PHP version (usually >> features, maybe performance increase etc.). But there also must be no >> reason not to upgrade. But you all know this, it has been said before. > > Namespace is one _very_ important reason. If we need a "marketing" > argument for PHP6 outside unicode, it is the one. I would also like to > do not backport it (but we can backport it as well, my main problem is > only this flag). late static binding is another reason (are we still going to get that?) rgds, Jochem PS - as an average joe this whole unicode semantic debate is confusing to a tee and scary with a capital S. :-) > > --Pierre > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] late static binding (please break BC?)
Bart de Boer wrote:
> Ken Stanley wrote:
>
...
> That's not right. Accessing the child class would only be possible from
> within an instantiated object. Unlike parent::, you will never be able
> to use static:: in a purely static context. Imagine there are multiple
> child classes which all inherit from the same base class. If there's no
> instance, PHP won't be able to know which child class to target with
> child::, static:: or whateverkeyword:: since it can be any one of those
> child classes.
huh??? the 'child' class would refer to the class that was actually named
when then call to the method was made (thats what late static binding means,
does it not?):
class Data {
static function getTableName() {
throw new Exception('WTF');
}
static function findRange() {
$t = child::getTableName();
}
}
class Prod {
static function getTableName() {
return 'PRODS';
}
}
Data::findRange(); // child = Data class
Prod::findRange(); // child = Prod class
if you require a class instance in order to use 'child' then
the whole point is moot - because you can already do
$child = get_class($this);
inside the relevant function (assuming the function is not declared static,
and why would you declare it as such if your requiring an instance to use
'child'?).
maybe 'child' should be called 'callee' or even 'lsb' (that would make people
hit the docs for sure :-)). alternatively maybe 'this' could be used as the LSB
keyword:
this::foo();
the samentics for determining what class is referred to with 'this::' is akin to
that used for determining what class is referred with '$this->', no?
MAYBE php6 should do late static binding for 'self', akin to other OO oriented
scripting langs .. and just live with BC. I seriously wonder whether much code
would
break ... given that 'self' is not currently late binding how often would
people have actually
overwritten static methods ion child classes that are being called via the
'self' syntax
in [parent] classes?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Callbacks bug/change request
Stanislav Malyshev wrote: >> You'd probably do something along those lines if it were possible: >> >> ((ParentClass) $child)->virtualMethod(); > > Looks like bad style to me - why not call child's method and it would, > if needed, pass control to parent? yeah, although I could imagine a situation where your stuck needing to calling parent::method() it smells like bad OO - the same kind of bad smell that people have been told they should avoid when it comes to wanting static interface methods, function signature changing, etc. personally I don't mind the smells, I'm not from the straight-jacket OO side of the street. that said I do feel consistency is a worthy goal and therefore it seems correct to enforce straight-jackets all round - given the general direction/mindset of php's OO functionality it seems that calling parent::method() from outside the relevant $child->method() should be illegal inline with other 'strictness enforcements'. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] late static binding
Richard Lynch wrote:
> Maybe I'm just confused (well, I'm always confused...) but if a Class
> has multiple children, how the heck would PHP know which child:: to
> call?...
the use of the name 'child' is very confusing, I would prefer 'super' or
'static' ...
regardless the concept is actually quite simple:
interface DOInfo {
static function getTableName();
}
abstract class DataObject implements DOInfo {
static function findRange() {
$table = super::getTableName();
return $foo; // $foo is a collection of whatever (e.g. Product
objects)
}
static function getTableName() {
throw new Exception('be a dear and implement '.__METHOD__.' in
your subclass'); }
}
class Product extends DataObject {
static function getTableName() { return 'PRODS'; }
}
$products = Product::findRange();
excuse me if I've just committed a grave sin against the OO Codex in writing
something
that either isn't 'correct' or is syntactically incorrect according to the
current
state of php - hopefully the idea is clear anyway.
>>
>> - Ken
>> --
>> It looked like something resembling white marble, which was
>> probably what it was: something resembling white marble.
>> -- Douglas Adams, "The Hitchhikers Guide to the
>> Galaxy"
>>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] http arrays
sorry for the noise - having gone back and tested again I can
no longer reproduce my original problem (the OP seemingly had the
same issue).
whatever problem I was having, related to encoding of square brackets,
seems to have disappeared. sometimes I feel like I'm living in the twilight
zone :-P
today there is no spoon.
Michael Wallner wrote:
> Jochem Maas wrote:
>
>> I'll take your word on it (although I can't be sure exactly what it is that
>> you expected),
>> which means the change has been reverted, or the input parsing stuff has
>> been changed to
>> recognize escaped square brackets as if they were not escaped - I know for
>> sure
>> that http_build_query() did escape quare brackets in 5.1.6 and that url
>> query strings
>> that included escaped square brackets were not parsed into [nested] arrays.
>
> "expected" means that I get
>
> array(1) {
> ["a"]=>
> array(1) {
> [0]=>
> string(1) "1"
> }
> }
>
>
> for get.php?a%5B%5D=1
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] http arrays
Michael Wallner wrote:
> Jochem Maas wrote:
>
>> $args = array('foo' => array('bar' => array(1,2,3), 'quz' => array(1,2,3)));
>> echo '/foo.php?'.http_build_query($args);
>>
>>
>> foo.php --- 8< ---
>>
>> var_dump($_GET['foo']);
>>
>>
>> the var_dump() output used to be a neat nested array, but since 5.1.3
>> [although I remember
>> it as 5.1.6] http_build_query() makes htmlentities of the square brackets so
>> therefore
>> the var_dump() gives you a string.
>
> Works as expected here with v5.2
I'll take your word on it (although I can't be sure exactly what it is that you
expected),
which means the change has been reverted, or the input parsing stuff has been
changed to
recognize escaped square brackets as if they were not escaped - I know for sure
that http_build_query() did escape quare brackets in 5.1.6 and that url query
strings
that included escaped square brackets were not parsed into [nested] arrays.
a bug closed bug shows that this was changed for 5.1.3:
http://bugs.php.net/bug.php?id=36656
>
> Regards,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] http arrays
Antony Dovgal wrote:
> On 04/27/2007 04:35 PM, elias wrote:
>> Hi,
>>
>> why has the support for http arrays (bracket syntax) been removed in
>> PHP 5.1.3 ? Yes [] not allowed by according RFC, but is that a
>> reason for an BC break? Is it an accident or harassment?
>
> What are you talking about?
probably a reference to the 'correct' but rather annoying BC break in
http_build_query()
countless php apps make use of the ability of php to automatically convent
get/post args
whose names are suffixed with square brackets into [sub]arrays in the relevant
superglobal
array ... some of those app also make use of http_build_query() to 'cleanly'
create
url query parameter strings that e.g.
$args = array('foo' => array('bar' => array(1,2,3), 'quz' => array(1,2,3)));
echo '/foo.php?'.http_build_query($args);
foo.php --- 8< ---
var_dump($_GET['foo']);
the var_dump() output used to be a neat nested array, but since 5.1.3 [although
I remember
it as 5.1.6] http_build_query() makes htmlentities of the square brackets so
therefore
the var_dump() gives you a string.
the workable 'fix' I have been using was to postprocess http_build_query()
output
with the following - a 'solution' which makes my skin crawl just a little:
function http_build_query_unborker($s)
{
return preg_replace('#%5[bd](?=[^&]*=)#ei', 'urldecode("\\0")', $s);
}
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simulating require_once within an extension
I suspect you could implement the desired functionality
using http://php.net/manual/en/function.stream-wrapper-register.php
although I can't find any info on whether include/require
actually work with registered stream wrappers .. maybe one of the
devs could confirm/deny whether this is possible.
which would allow you to do something like this (assuming it is possible to do):
require_once 'momcr://foo/script.php';
Mo McRoberts wrote:
> Hi list,
>
> Apologies if I'm sending this to the wrong list; I couldn't see another
> which was more appropriate on the PHP Mailing Lists page.
>
> I'm developing a PHP extension for which part of the functionality can
> be described in a nutshell as:
>
> * at request start-up time, build a map of identifiers to path-names, read
> from a configuration file;
>
> * whilst a user script is being processed, a function provided by the
> extension can be called to add, remove or modify items in the mapping;
>
> * a user script can call a function, passing it an identifier in the map,
> and the extension should simulate require_once being called with the
> corresponding pathname (with some transformation applied).
>
> For example, if the configuration file specified that 'foo' mapped to
> /www/common/foo, calling the above function with a parameter of 'foo'
> might simulate require_once('/www/common/foo/script.php') (where the
> transformation applied in this case is appending 'script.php' to the given
> pathname). A prototype implementation written in PHP itself works well enough,
> but obviously there are scoping issues with such an implementation (i.e.,
> any scripts included are included within the scope of the function, not the
> caller) which I want to avoid through the use of an extension.
>
> Obviously, much of this is pretty trivial and straightforward. My problem is
> the actual simulation of require_once itself. As it's a language intrinsic,
> there's no simply-exposed API for performing the same action. Digging through
> the PHP sources, I've come across zend_execute_scripts(), which seems to
> fit the bill, although there's no documentation and very few examples of it
> being used outside of the PHP engine itself.
>
> From skimming as many bits of the PHP sources that actually use
> zend_execute_scripts() that I could find, the code I've come up
> with isn't hugely dissimilar to this:
>
> static int
> do_required(const char *filename TSRMLS_DC)
> {
> int r;
> zend_file_handle zh;
>
> if(SUCCESS != (r = zend_stream_open(filename, &zh TSRMLS_CC)))
> {
> return r;
> }
> if(NULL == zh.opened_path)
> {
> zh.opened_path = estrdup(filename);
> }
> if(zend_hash_add_empty_element(&EG(included_files),
> zh.opened_path, strlen(zh.opened_path) + 1) == SUCCESS)
> {
> r = zend_execute_scripts(ZEND_REQUIRE_ONCE TSRMLS_CC, NULL, 1,
> &zh);
> }
> zend_stream_close(TSRMLS_CC);
> return r;
> }
>
> Simple enough, right? Wrong.
>
> I'm hoping at this point that somebody who knows the Zend internals pretty
> well will immediately spot which things I'm not initialising,
> saving/restoring,
> or happen to be double-freeing at this point, because I'm at a loss. My
> symptoms are this:
>
> * If calls to this function are nested, and an inner call results in
> zend_stream_open() failing, I get faults in zend_get_executed_lineno(),
> suggesting corruption somewhere.
>
> * If I save, reset and restore return_value_ptr_ptr, active_op_array,
> opline_ptr before doing anything, things seem better, but the Warning
> message reported when the file can't be opened gives the error location
> as [no active file] on line 0, which is less than ideal.
>
> * If I only save/reset/restore around the call to zend_get_executed_lineno()
> itself, things seem to work until I get as far as installing the extension
> for my Apache 2.2 module build of PHP: at which point, as soon as there's
> some nesting things start to go bad (errors reported or not). Removing the
> final zend_stream_close() call stops Apache from dying, but I strongly
> suspect that I'm just masking the problem rather than fixing it.
>
> So, my questions are: what am I doing wrong, and is there a better way to
> accomplish the same thing? I considered evaluating a script instead of
> trying to simulate require_once itself, but that seemed incredibly kludgy.
>
> Any help appreciated.
>
> Thanks,
>
> Mo.
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RCs explained (draft)
Antony Dovgal wrote: > On 02/16/2007 04:00 PM, Jochem Maas wrote: >> I would make the whole sentence above ALL CAPS > > This text should appear at qa.php.net, so no need for CAPS (which are > difficult to read), we can just use . indeed - I was merely stressing that you probably cannot highlight the fact that RCs concern non-production code enough :-) bold is just as good if not better than all-caps. > >>> Although, you might encounter some problems during the installation and >> >> I would replace 'Although, you might encounter' with 'If you encounter' > > Agree. > >>> Test engine. >> >> the header 'Test Engine' might not be understood and/or frighten off >> beginners >> (whilst doing the tests is actually very easy). >> >> you might encourage more people to run the test engine if you named >> the header >> for this section something like one of the following: >> >> Test Your New Installation. >> Check your Installation with the Integrated Test Suite. > > Agree. > >> you may wish to stress how valuable this information is to you and how >> much >> you appreciate that people send them. > > Any certain suggestions? > Somehow I've lost the inspiration I had in the morning =) something like this?: the php group would like to thank you in advance for taking the time to perform and send us the results of the test suite. AND/OR Each and every report goes towards helping us provide the best software we can, your feedback is a valuable resource and the PHP group would hereby like to extend their gratitude for your effort. > >> I would remove 'obviously' and change 'cannot' with 'does not yet', >> this would invoke more of a feeling of 'being in good [dev] hands' ... >> which I feel is not completely out of place :-) > > The point is that any real-life test is better than a test suite, > because a test suite will never cover everything. indeed - nothing like real world apps to really push php to it's limits - no doubt that your average php'er sometimes does such crazy things that an experienced dev would often not even imagine doing such things :-) > But I do agree with the wording, yes. maybe something like this: Currently the test suite does not completely cover all code in the php software (this is something we are working on!), regardless of this fact it is our experience that testing pre-release versions of php against real-world [php] software - this is due to a number of reasons: 1. end users often push the envelope of what is possible farther than the original developer intended. 2. end users' creative use of the language can lead to as yet unforeseen cases being brought to light. 3. real-world software environments are highly diverse, custom/exotic configurations sometimes bring problems to light that developers often have no way of pre-empting. we therefore kind request that you try out your own software with RC versions of php and report any problems to bug.php.net, issues that you bring to light will help to improve php itself and often your discoveries will lead to improvements in the test suite as well. we would like to make a special appeal to developers of large/successful (e.g. phpMyAdmin) php projects to test against pre-release versions, your input is of great importance due to the highly visible nature of your application and the large users bases they support. the PHP group recognizes the importance of large/successful [php] software projects in continuing/promoting the success of the [php] language - your success is important to us, please help us in our mission to provide as high quality platform as possible for your software! the PHP group extends their gratitude to everyone who offers up their valuable time to help with the testing effort. > ... just some thoughts :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RCs explained (draft)
Antony Dovgal wrote: > On 02/16/2007 01:21 AM, Antony Dovgal wrote: >> We also can add a detailed description of what is release candidate, >> what's the difference comparing to a release etc. to qa.php.net and >> add a link to that page in the block. Actually, I'll try to write >> something tomorrow. > > Please comment and correct (if needed). I offer a few small ideas/comments below - I hope they are not considered out of place. > > Release Candidates > -- > > Release candidates are development packages released to check if any > critical > problems have slipped into the code during the previous development period. > Release candidates are NOT for production use, I would make the whole sentence above ALL CAPS. you might also consider correlating the concept of 'UNSTABLE' with that of 'Release Candidate' given that 'UNSTABLE' is often used in other projects and is widely, implicitly understood to mean 'not for production use'. > they are for testing > purposes only even though in most cases there are (almost) no > differences between the general > availability (GA) release and the last RC. > You can help us detect problems by installing and testing release > candidates > on your own (non-production!) server. > > Installation problems. > First of all, make sure the build process (on *nix only) and > installation went fine for you. > PHP supports quite a number of operating systems on different platforms > and we continue > to work on increasing this number. > Although, you might encounter some problems during the installation and I would replace 'Although, you might encounter' with 'If you encounter' > we would > like to know about them. > > Test engine. the header 'Test Engine' might not be understood and/or frighten off beginners (whilst doing the tests is actually very easy). you might encourage more people to run the test engine if you named the header for this section something like one of the following: Test Your New Installation. Check your Installation with the Integrated Test Suite. > When done with the build, please run the test engine by using the 'make > test' command > and send us the results (hit 'Y' when it asks you whether to send the > report). > This way we'll receive the required information about your system to fix > the problems > detected by the test suite (if any). you may wish to stress how valuable this information is to you and how much you appreciate that people send them. > > Real-life tests. > We would also appreciate if you install the RC on your development > server and run > your software. This would help us to detect any (unintentional) changes > between > the release candidates and general releases. > Such real-life tests are the most valuable because our test suite > obviously cannot I would remove 'obviously' and change 'cannot' with 'does not yet', this would invoke more of a feeling of 'being in good [dev] hands' ... which I feel is not completely out of place :-) > cover every possible use case (but we're working on that). > kind regards, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Objectified Request Parameters
Dmitry Stogov wrote:
> +1
>
> I like this solution and I don't think that BC break is important for many
> applications.
> Not a lot of them use is_array($GET), and I believe no one use
> is_object($_GET).
> $get = $_GET may be a problem, but moving from PHP5 to PHP6 won't easy in
> any case.
a couple of views from an end-user POV:
if your going to have a BC break concerning this you might consider using a
differently
named variable to $_GET - there are enough people that are only just getting to
grips with
$_GET (and learning about register-globals) - I foresee a lot of confused people
with regard to $_GET having is semantic change, although no less 'annoying'
for people who are confronted with a BC break having a new variable would at
least
mitigate some confusion.
additionally using a fancy 'overloaded' object (as opposed to a straight forward
object) is [probably] going to confuse alot of beginners.
imho Pierre's suggestion of using the filter extensions 'interface' to solve the
problem seems much more approachable and understandable for an average user.
kind regards,
>
> Dmitry.
>
>> -Original Message-
>> From: Sara Golemon [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, January 27, 2007 10:21 PM
>> To: Andi Gutmans
>> Cc: 'Pierre'; 'Andrei Zmievski'; 'Dmitry Stogov';
>> internals@lists.php.net; 'Zeev Suraski'; 'Stanislav Malyshev'
>> Subject: [PHP-DEV] Objectified Request Parameters
>>
>>
>> > Btw, having a request object was one of the #1 requests in
>> framework
>> :) People actually really like encapsulating this because it
>> > also makes unit testing easier down the road...
>> > Just mentioning this because I don't think we should be
>> too set with
>> our ways esp. for people who need to accomplish more
>> > functionality.
>> >
>> For the record, I *do* prefer the simplicity of
>> implementation of going
>> with a request object, and I *personally* don't see it as a
>> show-stopping BC break. Then again, I didn't see that
>> fgets() change as
>> show-stopping either.
>>
>> So let's start back from square one. How about a fresh round of
>> discussion on the request object approach, in psuedo-code:
>>
>> class PHPGetObject implements ArrayAccess
>> {
>> private $decoded = array();
>>
>> public function __offset_get($varname)
>> {
>> if (!isset($this->decoded[$varname])) {
>> $val = http_decode_get($varname);
>> $this->decoded[$varname] = $val;
>> }
>>
>> return $this->decoded[$varname];
>> }
>> /* plus set,isset,unset of course */
>> /* Probably need an iterator too */
>> }
>>
>>
>> Pros: Fast, (mostly) clean, and cheap.
>> Cons: Breaks the following BC bahaviors:
>>* is_array($_GET) === false
>>* is_object($_GET) === true
>>* Referenceishness:
>> $get = $_GET;
>> $get['foo'] = 'bar';
>> var_dump($_GET['foo']); /* 'bar' */
>>
>> My vote: +1 as I don't think the Cons are that serious.
>>
>> -Sara
>>
>> --
>> 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] Is this what Stefan Esser was referring to ...?
whilst reading the thread on security issues in response to the article on the theregister.co.uk I came accross a remark by Stefan Esser aimed at Chris Shiftlett which I didn't understand, is this what he was referring to when he pointed a/the violation of the php license?: http://phpsec.org/images/phpsecinfo_ss.png 1. I don't feel strongly about the problem. 2. I don't want to stir any animosity towards phpsec or Chris Shiftlett (Im very grateful for all the things I have learnt form them/him) 3. Stefan Essers apparent feeling of ill treatment may be colouring his manner in terms of communicating this (and other) issue(s) BUT ... doesn't Stefan have a valid point with regards to the violation? if not I guess my understanding of the PHP licence and the PHP Group's policy is incorrect (I will make a go of rereading to correct that mistake) but I would have thought that someone would have, very quickly, offered up the reason(s) as to why there was no violation. if yes then I'm rather surprised that: a. the point was glossed over in favour of tackling Stefan's manner. b. Chris Shiflett (and/or phpsec) didn't spot the 'problem' and correct it proactively (I'm guessing, given his standing within the php community, Chris know where his towel is, so to speak) c. an amicable, behind the scenes solution was not crafted and implemented (I gather Chris is good friends with more than one of the members/founders of the PHP group) - in the spirit of portraying a consistent image/message to the outside world - at the end of the day changing a logo and colour scheme for the output of the tool in question is a rather minor technical challenge (it seems to me). I ask purely out of an insatiable curiosity with regard to anything that has to do with php, I'd be very for any comments anyone offer on this issue. It has not been my intention to offend anyone so I apologize in advance if I have inadvertently done so. kind regards, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen / allow_url_include and fine grained control
Ilia Alshanetsky wrote: > > On 16-Jan-07, at 8:07 PM, Sara Golemon wrote: > >> allow_url_include has been bashed lately for being "not good enough", >> and there is a kernel of truth to that, though where the ultimate >> blame falls if of course a touchy subject. > > Not really, I mean is it so difficult to expect the extension writer to > know that if they are working with remote streams that they should set > is_url to 1 rather then 0. > >> So rather than continue the fight over who's shoulders the job of >> security should fall on, how about the attached patch which puts a >> little more power in the hands of the user/site-admin to control what >> can be treated as a url include, and how it can be treated that way. > > I do not think that this is a good idea. Controlling security settings > via INI is just a recipe for disaster and will only lead to problem due > to poor configuration choices. Basically you are moving the "blame" from > extension writers that provide stream wrappers (fairly limited group) > onto a far larger group of users. what what it's worth, my opinion (as a member of the 'larger group of users'): as an end user I'd rather have the control myself and be the one to blame, than be at the 'mercy' of extension writers - where I have little to no idea if an extension behaves or not (and if not if/when it might be corrected). I see no reason to think that hosting providers & or packages would think any differently ... unless their lazy and enjoy passing the buck all the time. this does presume that good documentation and best-practice recommendations are available. rgds, Jochem (php village idiot by profession) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Include fileinfo in core
Kevin Waterson wrote: > This one time, at band camp, Antony Dovgal <[EMAIL PROTECTED]> wrote: > >> Also, to repeat myself here, there is also no way to use filepro database, >> hwapi, msession, >> cpdf, dio, fam, ingres, mnogosearch, yp API, Ovrimos, PayFlow Pro and a >> bunch of other functions >> without using PECL. > > I appreciate your point about not having everything available to core. The > extensions you > mention above are very specific to a task, where-as validating a file > mimetype is quite a > generic procedure. To this end I would like to see more discussion on the > topic. Its very > clear that you are not for it, but lets hear from others? my opinion count for jack s*** around here but the way I see it if I have a function fopen() as standard then I 'should' have a standard mechanism to figure out what kind of file something is. in practice I control all the servers I work on so doing 'pecl install fileinfo' is not a big deal - but the majority of users don't have that privilege. having fileinfo included as standard will hopefully encourage lots of projects (that are often infamous for security flaws?) to do a little more than check a file's extension when dealing with uploads? > > > Kind regards > Kevin > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] invalid array key/index not generating notices
without getting involved with whether there is a bug here or not
(I neither have the karma or the insight to make that judgement),
I would like to offer the idea that an alternative coding style could
have averted the problem regardless of the lack of an E_NOTICE...
namely a more defensive coding style; some example code
to make this clear:
maybe this is food for thought for you/your team with regard
to defending against [such] mistakes - I know from experience that,
even though I am often the only developer on a project, it pays not to
make to many assumption about what should be returned from functions/methods.
Daniel Convissor wrote:
> Folks:
>
> I came across a subtle bug a developer introduced into our application.
> It took us a month to realize the bug was there because PHP didn't throw a
> notice. Here is a simplified version of what was happening.
>
> // function some_func() {}
> $a = some_func();
> if ($a['do_something'] == true) {
>// Do it.
> }
>
> some_func() was supposed to return an array. But it was returning void.
> So $a was NULL. Oops -- we all make mistakes. What's unfortunate is PHP
> didn't raise a "Notice: Undefined index: do_something" here. It would
> have saved us some headaches. I'm sure others have run into this as well.
>
> The following also doesn't produce a notice:
>
> $a = 12;
> echo $a['k']
>
> I looked through the bugs database and mailing list archive and came up
> with nothing on this particular issue. But bugs 29271, 30885 and 38165
> cover the situation where a key's string is auto-converted to 0:
>
> // While this is a behavior we all truly expect:
> $a = 'value';
> echo $a[0] . "\n"; // output: v
>
> // Another oddity, but people closing bugs say it's expected:
> $a = 'value';
> echo $a['k'] . "\n"; // output: v
>
> This last behavior is counter-intuitive, let alone un-documented.
it does become intuitive once you truly understand the way php autocasts
stuff - I'll happily admit it took a post from Rasmus (no less) on the
generals mailing list for me to start to really understand what goes on in
situations
such as these... I'll try to explain (and hope I don't do anyone an injustice):
1. $a is a string therefore only integers are allowed as 'keys' in the
'array notation' used for accessing offsets of the string directly
2. the 'key' is string and therefore converted a integer according to the
string-to-integer conversion rules... leading consecutive numeric characters
are taken to
be the integer and in cases where there is no leading numeric character the
string converts
to zero (not taking into account a leading sign character that might exist in
the
string e.g.
echo (int) "123string"; // 123
echo (int) "1string"; // 1
echo (int) "string";// 0
>
> Wondering what the folks here think about this.
>
> Thanks,
>
> --Dan
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal - E_TAINT / purely ?
the way I see it there is one simple way of making sure 'taintmode' doesn't become another magic suicide bullet (ala safemode)... make taintmode do nothing more than produce warnings/errors/whatever - don't let it have any effect on the actual running of the application. I for one would be more than satisfied if taintmode did nothing more than fill my errorlog with info about how I can make my code better - rather akin to E_STRICT. my suggestion (for what it is worth) would be to offer taintmode as an error_reporting level rather than a switch that effects the actual running of code, ergo E_TAINT :-) [it should not be part of E_ALL, again akin to E_STRICT] which ISP would turn on E_TAINT as a security feature given that it would be logical to document suchlike as being purely a reporting level and having no effect on actual code run (in exactly the way E_STRICT might fill my logs on a production machine if I turned it on but has no effect on what my code actually does [assuming display_errors is Off]) my rationale is that one will have to read the error messages to make any use of taintmode - and if your going to have to read the error messages anyway why bother to integrate taintmode into php's behaviour? a developer reacts to the error message not so much the fact that php halts (because we can turn off taintmode to make the halting go away) rgds, Jochem Zeev Suraski wrote: > At 23:40 16/12/2006, Ilia Alshanetsky wrote: You're not helping them, just making assumptions about how their code should work and making them adhere to them. >>> >>> Yes, and this is helping. Every language does that. Saying "you >>> can't make 100% work exactly as I wanted without any effort, so >>> entire thing isn't even worth discussing" is a road nowhere. >>> There's a lot of places it would be helpful, and there's a lot of >>> places it won't - and that's ok. >> >> I am saying that you should not try to outsmart the developer because >> you assume you know best. > > Ilia, > > Why are we outsmarting developers? Security bugs are out there, in fact > in web apps they're pretty much a plague (irregardless of the > language). Does it mean that some developers aren't smart and many are > not properly informed? Absolutely YES - that's the world we live in... > Given that, and the likelihood it'd only get worse (more and more people > are programming the web with less and less training) - whatever we can > provide in the direction of creating better apps can help. > > My 2c on this piece is that tainting can be a nice helper tool to reduce > the likelihood of security problems in your code. Nothing more and > nothing less. > > I too fear the possibility of tainting becoming the new safe_mode. > "Outsource your security to PHP, it'll take care of it". But I think > there's a way of both designing and pitching tainting so that we avoid > this false perception. If we pitch tainting as a development-time only > tool the points out a certain class of security mistakes, and is by no > means an invisible magnetic shield that actually protects you from them > - then I think it can be quite useful. > > As such, I would consider: > - Saying tainting should not be enabled in production (avoid the false > sense of security people might have if they turn on tainting in > production). > - Not necessarily the fastest possible implementation, since it'd be > used for development purposes only. > - Consider making this a compile time option with significant overhead > and a big DO NOT ENABLE IN PRODUCTION, so that people have an even > clearer idea they shouldn't rely on it to find their bugs, and that in > fact it's just a helper tool, not unlike a strong IDE. > > We could possibly even come up with a new name other than tainting so > that there is not prior perception as to what this feature is supposed > or not supposed to do. > > Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML: A bug or just an annoyance?
Stut wrote:
> Sebastian Bergmann wrote:
>> 1 > 2 $root = simplexml_load_string('');
>> 3
>> 4 $array = array();
>> 5 $array[$root['id']] = 'value';
>> 6
>> 7 $key = (int)$root['id'];
>> 8 $array[$key] = 'value';
>> 9 ?>
>> Warning: Illegal offset type in /home/sb/test.php on line 5
>>
>
> I've not used it much, but I believe you need to cast attributes coming
> out of SimpleXML, in this case probably to an int.
that sounds about right. my experience with SimpleXML is that every is either
a string, an object, an array depending on how you are looking at it and
regardless of
the situation auto-casting can be relied on to NOT do what you want/expect ...
the most problematic thing I found with simpleXML was the complete lack of
means to
inspect an objects structure/content using funcs like var_dump() [it seems
lots of __toString() magic lays waste to any attempt to look inside the object]
from what I gather the described 'annoyance' is indicative of the prescribed
SimpleXML behaviour.
I personally believe that SimpleXML is too clever and/or intuitive for it's own
good
- or maybe I'm just incredibly stupid, either way I decided a while back to
stick to
using the DOM extension for anything XML related because I found it so much
easier to
use and understand.
I guess nothing in live is ever simple ;-)
>
> -Stut
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] class defs from file?
Tony Bibbs wrote: > First post here so be gentle ;-) > > I've got a unique need to get the class definitions from a file. Now I > can write the string manipulation necessary to do this myself with the > help of some regex-fu but I was wondering if it wouldn't be possible to > add a method like: > > array getClassDefs(string $someFileName) > > Like I said, I can do it with some regex work but given the PHP engine > has to do this it'd seem like a nice addition to the core oo-functions. > This may be a case where I've got too specific a need to warrant > community interest but I'd think there might be other cases where such a > method would prove handy. > > Thoughts (other than the obligatory 'p1ss-off'? not really an internals thing - generals list is better. http://nl2.php.net/manual-lookup.php?pattern=token&lang=en should get you what you need. :-) > > --Tony > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where to setlocale(3)?
Michael B Allen wrote: > How does one PROPERLY set the locale under which PHP scripts run? Is > it a script level property, if you want. PHP level property, yes. HTTP level property or dont know > inherited from the OS default? the default is inherited from the OS unless something is broken. > > I have a module that converts strings between the locale character > encoding and another encoding. Currently setlocale(LC_CTYPE, NULL) > within a script returns 'C' which is to say the locale is not set. 'C' = Posix std locale. > > Where do I look? what do you want to find? ;-) > > Thanks, > Mike > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using grand-parent constructor
Jasper Bryant-Greene wrote: > adding parent::__construct() in the constructors of both Parent and > Child should do what you want. not only that but you 'should' _always_ really be calling the complete constructor chain (e.g. Gparent < Parent < Child) according to "OO theory" - the thought being that the construction phase is critical to instantiating a class instance, a subclass should be able to rely on the fact that the baseclass definition is completely/correct instantiated when it is created. sounds to me that either your class hierarchy is 'wrong' or there is some code in the Parent ctor that should belopng in some optional (protected?) setup/utility function. just a thought. > > Jasper > > Evert | Rooftop wrote: >> Hi List, >> >> Sorry if this is the wrong list for this kind of stuff.. I'd be happy to >> re-post this to the users mailing list. >> >> With the recent updates that will raise E_STRICT on static calls that >> are non static, how do we properly do the following.. >> >> I have a class named 'GrandParent' a class named 'Parent' and a class >> named 'Child' >> >> GrandParent has a constructor, Parent overrides it and Child does too.. >> What if I want to call GrandParent's constructor from the child? >> >> Most languages allow this through casting the class into the ancestor >> and call then call the method, but I can't do this with PHP, or can I ? >> The other solution (right now) would be GrandParent::__construct(), but >> this is not OOP anymore.. So it seems kind of weird that we get limited >> in functionality, for OOP-ness, but not adding the functionality to >> solve common design problems that we're raised by introducing this.. >> >> Will we get casting in the future? >> >> Evert >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Simplistic End User View] Re: [PHP-DEV] is_numeric_string causes function inconsistency
Pierre wrote:
> Hello,
>
> Note that I also answer your previous mail here :)
>
> On Fri, 11 Aug 2006 06:18:13 -0500
> [EMAIL PROTECTED] ("Matt W") wrote:
>
>> Hello again,
>>
>> I discovered a couple more things is_numeric... is causing problems
>> with (leading whitespace). I doubt any of the examples I've given
>> make sense to regular users who don't know what's happening behind
>> the scenes. Add these to the "wrong" list:
>>
>> is_numeric(' .123') // bool(false)
>
> this one should return true.
as Pierre mentions further down changing this behaviour could cause pots of
problems for existing code. from an enduser POV having is_numeric(' .123')
return true (and therefore having maths operations using ' .123' use that string
as if it was '.123' would be tantamount to doing:
$v = " .123";
$v = trim($v);
var_dump(is_numeric($v), ($v + 0));
In order to be able to move forward and allow for leading spaces in numeric
strings
maybe an ini setting could be used, one that defaults to false:
trim_numeric_strings_before_usage = 0;
such a setting if true would essentially trim space (like the trim() function
does)
form strings before they were checked (by is_numeric) and before being used in
calculations.
in php6 the default of this ini setting could be changed to true (which would
offer quite some time to check for possible unforeseen problems and eventually
in php7,8,9 the setting could dissappear entirely once the community is
satisfied
any/all problems have been dissipated.
I have no idea if this is feasable or desirable (I'm aware of the animosity
towards
new ini settings!) but it might offer a potential resolution between moving
forward
and protecting muppets like myself from 'strange behaviour' related to
autocasting of
numeric strings.
rgds,
Joche,
>
>> ' .123' + 0 // int(0)
>
> ' 0.123' is casted to 0, 0+0. But if the ' .123' is allowed, it should
> then result in 0.123+0, which is the correct behavior.
>
>
>> One more thing I was curious about as far as keeping things
>> consistent is with is_numeric... (and therefore
>> convert_scalar_to_number()), hex strings are allowed/work, but not
>> with convert_to_[long|double]().
>
> I did not check convert_* while fixing/enhancing filters, but I think
> there is a higher risk of breakages if you change these functions. We
> should first have a clear view of what is used where and how the
> changes affect end user scripts and extensions. It sounds like an
> impossible task (except for 6.0).
>
> I suggest you to take a look at the ext/filter code and what we accept.
> I spend a far amount of times to ask and listen to users to see what
> they expext. I'm quite happy with the current state and for what I
> hear, the users too.
>
> You can check the FILTER_VALIDATE_* mode, they do the same operations
> that we are discussing here. The sanitize mode only checks for
> unexpected chars.
>
>
>> So a few PHP functions properly
>> accept hex strings, but most will convert one to 0. Should anything
>> be done about this difference? I have an idea about allowing hex
>> strings in to_[long|double] using the new is_numeric... functions I
>> will propose.
>
>> Few things about the current is_numeric... and hex strings, which I
>> think I'll change in my proposal unless I hear opinions otherwise:
>> *) Leading whitespace isn't allowed
>
> They should be allowed (leading/ending).
>
>> *) A sign (±) isn't allowed
>
> It is allowed except for in the hexadecimal notation (see the manual
> page of is_numeric), so if you talk only about is_numeric and the hex
> notation, it is a bug fix.
>
>> *) Hex doubles don't work. I think they should (for *whole* numbers
>> only obviously, no "."). So '0xFF' + 0 for example, works on
>> a 32-bit system.
>
> They should not, an hexadecimal notation represents an integer (long),
> not a double. A double could be the result of a cast when it is out of
> the integer range.
>
>> If that last one can be changed, it also should be in the language
>> parser of course (you know, for $n = 0xFF;).
>
> It is the endless problem about 32/64bits issues, also I don't think
> you are considering to use double in a for loop? :)
>
>
>>> Since I've been looking at is_numeric_[string|unicode], I found a
>>> weird thing it causes; probably doesn't make sense to users; bug?
>>> Look:
>
>
>>> abs(-1e500) // float(INF)
>>> abs('-1e500') // int(1) WRONG
>
> Agreed, it should float(INF)
>
>>> abs('-1e100') // float(1.0E+100)
>>> is_finite(1e500) // bool(false)
>
>>> is_finite('1e500') // bool(true) WRONG
>
> Agreed, should float(INF)
>
>>> is_finite('1e100') // bool(true)
>>> is_numeric(1e500) // bool(true)
>>> is_numeric('1e500') // bool(false) WRONG
>
> Agreed, float(INF) as before
>
>>> is_numeric('1e100') // bool(true)
>>> 1e500 + 123 // float(INF)
>>> '1e500' + 123 // int(124) WRONG
>
> I get the feeling that the E notation has one bug, solving it should
> most of these issues. ext/filter pass
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Pierre wrote:
> Hello,
>
> On 8/7/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>
>> > class Foo {
>> > public interface function myFoo($x) { echo $x; } // strict
>> method signature enforced
>> > }
>>
>> > class Bar extends Foo {
>> > public function myFoo() { echo "bar"; } // this would be
>> E_FATAL
>> > }
>>
>> > class Qux extends Foo {
>> > public interface function myFoo($x) { echo $x; } // this is
>> okay.
>> > }
>>
>> Hmm i see some elegance here :-)
OT: that's a nice thing for a 'php mug' to hear coming from a 'php dev' :-)
>
> This is exactly what has been proposed last week, add a keyword to the
> declaration to mark a method as strict.
having reread the thread this does seem to be pretty much the case, although
my suggestion saves on adding a new keyword and by reusing the 'interface'
keyword hopefully sparks, in the mind of the developer, the direct correlation
between interfaces and strict methods.
> And I'm in favour of this solution.
I very much hope that this means there is a potential to resolve the 'mexican
standoff'
between the 2 camps and dissapate some of the [perceived] animosity between 2
(or more)
great contributors to the php project (your both 'the good guy', something
which is easy
to forget in the heat of an argument :-).
kind regards,
Jochem
>
> --Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Marcus Boerger wrote:
> Hello Pierre,
>
> Monday, August 7, 2006, 11:36:57 AM, you wrote:
>
>> On Mon, 7 Aug 2006 11:16:05 +0200
>> [EMAIL PROTECTED] (Pierre) wrote:
>
Oh thinking and documenting is forbidden - i
see
>>> PHP thinks for me now, and if it is about documenting, then I don't
>>> any interfaces and all the other additions, I can document everything.
>
>> Sorry, I mean I do not _need_ any of the new OO additions (private,
>> public, interface, etc...) as everything can be documented.
>
> Some people have colleagues, sometimes self discipline is not enough.
> And yes you can leave public, protected and private. But that is not
> even in any remote way connected the topic.
I had a [another] thought about the enforced strictness issue being
discussed...
the current thinking of Marcus (and his proponents) is that method signatures
must stay the same when a method is overloaded in a subclass, making std.
class signatures work exactly in the way that interface signatures work.
Pierre (and his proponents) think that this is an artificial limitation which
in the general case make php less attractive.
I am personally in the 'Pierre camp' on this one but I understand the
argument Marcus provides regarding breaking the 'is a' relationship.
(btw: I am aware of both Marcus' and Pierre's great work in the php project
and am grateful for their efforts; regardless of whether I always agree with
their personal vision of what php is and where it should be headed)
My Ideas:
=
idea no. 1 is: to make it so that methods originally defined as abstract to
behave like methods defined in interfaces (namely enforce strict method
signature
compliance - continue using E_FATAL for non-compatibility); and leave methods
which are not derived from an abstract definition to change their signatures
without
any penalty (not even E_STRICT). I realise that this may not do the trick for
the
strictness camp because it might not always be possible/viable to define the
required abstract method in order to enforce method signature strictness.
idea no. 2 is: to reuse the 'interface' keyword in another context, namely as
a modifier for the method definition; the idea being that any method that
overloads
a method in a baseclass that is defined as 'interface' must adhere to the
original
method signature (again using an E_FATAL for non-compatibility). obviously
doing something
like this requires hashing out the details of, for instance, what happens when
you don't
specify 'interface' for a base class method but do specify it for a subclass's
overload of
said method and/or whether the interface modifier need be specified in
overloaded methods (etc).
e.g:
class Foo {
public interface function myFoo($x) { echo $x; } // strict method
signature enforced
}
class Bar extends Foo {
public function myFoo() { echo "bar"; } // this would be E_FATAL
}
class Qux extends Foo {
public interface function myFoo($x) { echo $x; } // this is okay.
}
rgds,
Jochem
>
>> -- Pierre
>
>
>
>
> Best regards,
> Marcus
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Rasmus Lerdorf wrote:
> Pierre wrote:
>> Hello,
>>
>> On 8/3/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>>
>>> I'm not all that keen on a new keyword for this. How about using an
>>> interface to indicate strictness? Isn't this really what interfaces are
>>> all about?
>>
>> I don't like new keywords either, but I don't see any alternative. I
>> also think that interfaces are what should be used. But it seems that
>> we are wrong, interfaces do not solve this issue, I'm still unsure
>> about the reasons though...
>
> Well, currently they don't because they don't care about method
> signatures, but they could be made to care. Are there reasons beyond that?
erm, interfaces do care about method signatures either that or my php5 install
is magic:
# php5 -r '
interface Foo { function bar($v, $k); } class Qux implements Foo { function
bar() {} }'
Fatal error: Declaration of Qux::bar() must be compatible with that of
Foo::bar() in Command line code on line 2
# php5 -r '
interface Foo { function bar($v, $k); } class Qux implements Foo { function
bar($a, $b, $c) {} }'
Fatal error: Declaration of Qux::bar() must be compatible with that of
Foo::bar() in Command line code on line 2
>
> -Rasmus
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Lukas Smith wrote: > Hi, > > well it seems that the initial vision of E_STRICT to denote future > deprecation is no longer valid. Then again it might have been a > misunderstanding from the beginning as E_DEPRECATED would have been the > more obvious name in that case. I did try to point this out but I was probably ignored due to lack of karma (which is understandable given the volume of the thread). I don't care much about *real* strictness issues but I do develop with E_STRICT on because it tells me about things in my code that are depreciated and/or will be removed in future versions (which is something I do care about). so it seems an E_DEPRECIATED might be needed (requiring alot of E_STRICTS to be changed), or alternatively something like an E_NOTRECOMMENDED? someone just mentioned the the possibility of having this strictness (and maybe others?) error be thrown as an E_NOTICE. I personally like this approach because E_NOTICE does not have the same "this is second class code and the ability to run it will disappear in the future" connotations as E_STRICT does. kind regards, Jochem > > I still think that a flag on a per class basis would be the better > solution, but I guess I can accept this change. > > This reminds me again about my question of how E_STRICT warnings are > added and how things are then handled (E_STRICT becomes E_ERROR or the > feature is removed entirely) with the future releases. I think a clear, > written down policy is needed (and as always may be overwritten via > common sense on a case by case basis). > > regards, > Lukas > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Zeev Suraski wrote: ... > > > My recommendation: > - Add a new flag to methods (at the implementation level) that will > allow to flag them as 'strict' > - In case such a strict method is improperly overridden - error out > (E_ERROR) > - In case a non-strict method is improperly overridden - emit E_STRICT > - Consider adding userland ability to set entire classes or methods as > strict > > Most people who use 'strict OO' will have E_STRICT enabled and have > their code E_STRICT clean, so providing userland support for tagging > classes/methods as strict is probably not really necessary. one thing occur to me (from a enduser's POV): E_STRICT is often used to denote usage that is depreciated and/or 'evil' with the implication (when it's not explicitly mentioned) that in future one will no longer be able to rely on the said usage. this makes, by implication, anything that produces an E_STRICT is 'second class' which I believe is not the implication that should be made here. E_STRICT has seemingly been abused regarding it's meaning and it seems to me that there is a need to differentiate between strictness and depreciation (E_DEPRECIATED? E_EVIL?). I personally don't want to write/use code that is depreciated [if I can help it] but mostly I don't give 2 hoots about strictness (for instance, I'm quite disciplined enough to write matching method signatures in relevant subclasses when that is needed; without php always forcing it upon me) kind regards, Jochem PS - very nice to see someone come with up with a definite suggestion that does take into account the voice of the [legion of?] php-nobodies who have concerns/issues regarding the 'strictness' stuff that's been creeping in lately. > > Zeev > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
