Sean Coates wrote:
>> i know this hack, but it does not work, if the statically called method
>> is from the same class as the calling object
>
> Good point. Sorry for not noticing.
> ... I have no idea WHY someone would want to do this.. that said, I
> don't know of a way to do it, either.
a fun
Hi Michael,
It is not a bug. You understood proper. Internal classes are stored in
regular heap and they don't use e[memory] function family.
This is done, because memory allocated by emalloc is freed after each
request, but internal classes should still alive in global class table.
Thanks. Dmitr
Hi,
I have noticed that fread()'s behavior has changed between PHP 5.0.4 and
PHP 5.1.0b3. Basically, http://pear.chiaraquartet.net/go-pear.phar
works in PHP 5.0.4 and fails in 5.1.0b3 because of this change. The
line in question of the .phar from PHP_Archive is:
fread($this->_file,
i know this hack, but it does not work, if the statically called method
is from the same class as the calling object
Good point. Sorry for not noticing.
.. I have no idea WHY someone would want to do this.. that said, I don't
know of a way to do it, either.
S
--
PHP Internals - PHP Runtime D
Sean Coates schrieb:
>> how can i check if a method is called statically when called from inside
>> another object? (without debug_bactrace())
>
> type="own">http://blog.phpdoc.info/archives/4-Schizophrenic-Methods.html
>
> Short answer:
> $isStatic = !(isset($this) && get_class($this) == __CLAS
Hi I wrote:
> I wrote:
>
>
>>I have some issues with static members of internal classes.
>>AFAICS no extension uses them so far (did I miss something?).
>
> I cannot declare static properties as strings because that causes
> memory errors in zval_dtor() (SET_STATIC_PROP_EX code is actually
> the s
My include path is huge... of course it includes the basic ones, but
also my classes path /classes/System/* , /class/System/Exceptions/* etc.
Beside of that why clutter the include_path with namespaces? In my
opinion it's something different then the rest.
p.s. you will support nameless namesp
Hi Val,
This wil require that at least one of the extensions are compiled in so it
might not work on Win32 where the extensions are provided as shared
objects.
- Frank
> Hello!
>
>There're 2 extensions - APC and bcompiler - that can work
> independently, but when both of them are used,
Hello Marcus,
In my case at work, my include_path only has three directories: . (current
directory), the PEAR path, and the directory where my company's classes are
stored. In this case, the namespace import will only have to search in
three directories, which is not bad. The class_path would only
Hello!
There're 2 extensions - APC and bcompiler - that can work
independently, but when both of them are used, they need to intercept
zend_compile in a specific order. I see the only way how to arrange this -
if during bcompiler's init APC is already loaded, call a C function in
APC from b
how can i check if a method is called statically when called from inside
another object? (without debug_bactrace())
type="own">http://blog.phpdoc.info/archives/4-Schizophrenic-Methods.html
Short answer:
$isStatic = !(isset($this) && get_class($this) == __CLASS__);
HTH
S
--
PHP Internals - P
Hi,
at first, im really really sorry to bother the internals-list with this
problem (especially Derick for coming back from playing somewhere else
... (<[EMAIL PROTECTED]>) ), but i didnt find
an answer on php.general or german php mailinglist
if anybody just can point me to any discussions, webs
Hey Andi,
> I agreed to make life easier on Derick who didn't want to maintain the
> patch outside of CVS, mainly because there were some bug fixes mixed in
> with it. I didn't realize this would cause havoc.
It hasn't created havoc. My concern is that it precluded discussion.
> Derick did brin
I couldn't agree more, Wez - but this is the problem I'm seeing. What
chance is there of working it out together when all discussion on the topic
has been effectively overruled? If this ever gets to be the standard
approach to PHP development, we'll have utter chaos.
The last word on the subject
Hey Steph and all,
I agreed to make life easier on Derick who didn't want to maintain the
patch outside of CVS, mainly because there were some bug fixes mixed in
with it. I didn't realize this would cause havoc. It was definitely not a
political move on my part (I'm not involved in any of the
+1
On 7/20/05, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Guys, work [EMAIL PROTECTED] You'll get the best results and ultimately our
> goal
> is to provide the best solutions to PHP users, not spend time in politics
> and on ego trips.
>
> I'm not going to play policeman (and I shouldn't). You g
I wrote:
> I have some issues with static members of internal classes.
> AFAICS no extension uses them so far (did I miss something?).
I cannot declare static properties as strings because that causes
memory errors in zval_dtor() (SET_STATIC_PROP_EX code is actually
the same as in ReflectionClass
All,
I know I haven't much sway here, but...
No disrespect to either Andi or Derick, I just want to register publicly my
opinion that putting contentious code into CVS HEAD, even out-commented,
sets a worrying precedent. There may well still be 'room for change and
discussion', but once it's in
I will be maintaining the HTML_Select pear package. I've spoken with the
current maintainer (klaus aka thesaur) and he told me I needed to open a CVS
account to have access to pear and peardocs.
Thakn you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
Hello,
Well, I wouldn't use the include_path parameter of PHP for the new
namespaces lookup code, neither __autoload(). I see it as a major
language change -- the support of namespaces, where you should consider
to make all need. I suppose you want to support namespace spread over
multiple fi
Hello Jessie,
Wednesday, July 20, 2005, 8:35:26 PM, you wrote:
> "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Please don't add new ini settings here, living with include_path should be
>> enough, wouldn't it?
>>
> Do we want the import behavior to apply to th
Hi,
I have some issues with static members of internal classes.
AFAICS no extension uses them so far (did I miss something?).
There seems to be missing a proper cleanup routine for the
static_member hashtable in PHP-5.0 because there are mem-leaks
for each property to which another value (i.e. st
22 matches
Mail list logo
