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 tha
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 ...
---
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 cod
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 r
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
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
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,
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
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::t
[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 pos
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
some
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.
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
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/
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.
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 cu
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
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
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 f
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) an
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 i
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)
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
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
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 r
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 ha
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
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
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_p
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
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 Mail
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/sh
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
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 __au
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 erro
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 matur
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
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
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 explan
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 fr
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_ca
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? Ad
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
aliasi
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
J
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
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 'He
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 f
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
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 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:
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 propo
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
-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
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
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
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 r
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
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 mass
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 lea
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
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
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()
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
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 diffe
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 pro
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
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
>>
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
+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 o
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
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 differen
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
>>>
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 et
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.
>
> Namespa
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 inh
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
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 qu
e :-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
>>
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< ---
>>
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 abo
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.
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 probabl
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 tomorr
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 c
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/image
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
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 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
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 t
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
>>
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:
>
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
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 t
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
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"; } // th
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
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 k
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
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 - em
1 - 100 of 192 matches
Mail list logo
