Hi again,
Well, its behavior isn't like a Parse Error, becase the following code
return NULL and not false:
\'\\;' ));
?>
On Sun, Aug 31, 2008 at 2:33 AM, Diogo Neves <[EMAIL PROTECTED]> wrote:
> I send the sample file attached, it's easy to understand what I'm saying...
> The line in where is e
I send the sample file attached, it's easy to understand what I'm saying...
The line in where is echo 'maria'/; should throw a Parse Error and not
a Warning, and @ least if it really is a Warning it should be catch
like any other Warning...
Plz, see the file, it's simple and shows better than my e
Hi,
__get() makes more sense to me, and maybe was where | got the ideia
because | never used __call() before but i add used __get() :(
Maybe the php folks change its behavior in future...
It's worthy of a bug report ( I ask because i'm not very involved in
php community )
Thanks,
On Sun, Aug 31
Antony,
I don't at all disagree about the inappropriateness of this not triggering
an error but I did want to point out that this behavior is not consistent
with how __get() works. It seems like they should all behave similarly when
dealing with overriding methods or properties of different access
Hi again,
On Sun, Aug 31, 2008 at 12:04 AM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 31.08.2008 02:50, Diogo Neves wrote:
>>
>> Exactly...
>>
>> Is that normal workings or more like a bugie one?
>
> Definitely not a bug.
Ok, it's implemented to work like that... less bad ;)
>
> I believe th
On 31.08.2008 02:50, Diogo Neves wrote:
Exactly...
Is that normal workings or more like a bugie one?
Definitely not a bug.
I believe the reason is that if you enable __call() in this case,
you'd have different behavior depending on the calling scope,
i.e. complete mess.
Also there would be
Exactly...
Is that normal workings or more like a bugie one?
On Sat, Aug 30, 2008 at 10:02 PM, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Cristian Rodríguez wrote:
>>
>> Diogo Neves escribió:
>>>
>>> Hi all,
>>>
>>> I'm emailling to ask why __call isn't called when you call a private
>>> method
Hi again,
I'm workarrounding ( I really don't know if that word exists ) with an
'_' on private methods, but u can that that off on user class to see
this error:
Fatal error: Call to private method user::print_user() from context
'' in /home/diogo/Documents/devspace/mangas.dev/index.php on line
Cristian Rodríguez wrote:
Diogo Neves escribió:
Hi all,
I'm emailling to ask why __call isn't called when you call a private
method from outside of function...
Please provide example code ;-)
He means this:
class foo {
private function bar() { }
function __call($f,$a) {
echo "calle
Diogo Neves escribió:
> Hi all,
>
> I'm emailling to ask why __call isn't called when you call a private
> method from outside of function...
Please provide example code ;-)
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Rodríguez R.
Platform/OpenSUS
Hi all,
I'm emailling to ask why __call isn't called when you call a private
method from outside of function...
In my opinion, this error should exist, but when you haven't an __call
function, because outside the scope of class it only should see public
methods, then if it don't exist it should c
On Sat, Aug 30, 2008 at 16:15, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a reason phar is built shared in win32 snapshots even though
> the default in config.w32 is to build it statically?
Isn't there a internals-win@ list ? :)
-Hannes
--
PHP Internals - PHP Runtime Development
On Sat, Aug 30, 2008 at 8:05 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>> and the problem will be gone. The false set the "shared" argument to
>> false (problem is that PHP_XYZ_SHARED is set to NULL now or smtg
>> similar). I will have time after alpha2 to dig into this problem and
>> apply a fix
Pierre Joye wrote:
> On Sat, Aug 30, 2008 at 7:56 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>
>
>> Right, my point is that this:
>>
>> configure --enable-debug-pack
>>
>> builds phar in statically, just as zlib is built statically. Perhaps
>> the --enable-snapshot-build could be fixed to match
On Sat, Aug 30, 2008 at 7:56 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Right, my point is that this:
>
> configure --enable-debug-pack
>
> builds phar in statically, just as zlib is built statically. Perhaps
> the --enable-snapshot-build could be fixed to match this behavior?
That's my point
Hi
2008/8/30 Steph Fox <[EMAIL PROTECTED]>
> Can you try to actually what is used to build a release please?
>>
>> cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack
>>
>
> So the snapshot build no longer works with the same criteria as the rest of
> the build system? Great
Pierre Joye wrote:
> hi,
>
> On Sat, Aug 30, 2008 at 6:41 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>
>> Pierre Joye wrote:
>>
>>> hi,
>>>
>>> On Sat, Aug 30, 2008 at 4:15 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>>>
>>>
Hi,
Is there a reason phar is built shared in
I wonder if I'm completely stupid or unable to get you actually read
the mails before complaining endlessly and obviously 48hours before
the release because we have nothing else to do than that.
I complain endlessly because I see an apparently endless line of things that
worry me, some of which
hi,
On Sat, Aug 30, 2008 at 7:02 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>> Can you try to actually what is used to build a release please?
>>
>> cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack
>
> So the snapshot build no longer works with the same criteria as the rest o
Can you try to actually what is used to build a release please?
cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack
So the snapshot build no longer works with the same criteria as the rest of
the build system? Great.
And I still have no answer to my question. Why should
hi,
On Sat, Aug 30, 2008 at 6:41 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Pierre Joye wrote:
>> hi,
>>
>> On Sat, Aug 30, 2008 at 4:15 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> Is there a reason phar is built shared in win32 snapshots even though
>>> the default in config.w
Pierre Joye wrote:
> hi,
>
> On Sat, Aug 30, 2008 at 4:15 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> Is there a reason phar is built shared in win32 snapshots even though
>> the default in config.w32 is to build it statically?
>>
>
> The default config.w32 (besides being wron
Pierre,
I do know, though,
that it all worked fine before the build system was 'upgraded' and
several
of the other config.w32 files across the core were 'fixed' to accommodate
those changes.
Let forget this attempt to yet again discredit the fantastic work
being done by the windows team and
On Sat, Aug 30, 2008 at 5:16 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>>> Is there a reason phar is built shared in win32 snapshots even though
>>> the default in config.w32 is to build it statically?
>>
>> The default config.w32 (besides being wrong) is shared.
>
> ARG_ENABLE("phar", "disable phar
Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?
The default config.w32 (besides being wrong) is shared.
ARG_ENABLE("phar", "disable phar support", "yes");
I'm still not in a position to test and uncover what you might
hi,
On Sat, Aug 30, 2008 at 4:15 PM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a reason phar is built shared in win32 snapshots even though
> the default in config.w32 is to build it statically?
The default config.w32 (besides being wrong) is shared.
Why should it be built static
Hi,
Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Stanislav,
Friday, August 29, 2008, 7:53:02 PM, you wrote:
> Hi!
>> It wasn't designed to have multiple namespaces at all to begin with. But as
> You mean multiple namespaces per file, right? Otherwise it sounds kind
> of silly. Yes, it wasn't designed to have multiple namespaces per fil
Hello Stanislav,
Friday, August 29, 2008, 10:00:08 PM, you wrote:
> Hi!
>> Seems like you are answering lot of questions about namespaces lately
>> with "that's not how the model was designed".
> Not really, and it's not the reason, the reason why it wasn't designed
> that way was explained be
29 matches
Mail list logo
