Yes, I remember. It was not for fun. I agree that this is a low
priority feature just now while many important issues are to be
solved.
On 26/11/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Marian,
>
> have a guess. Di we do this change for fun? Actually we found some nasty
> tricky pro
Sara Golemon wrote:
> Is anyone working on something like this already?
I don't known what you exactly meaning, but I'm playing with 'The Spread
Toolkit' [1] a their PECL interface [2]. I was started research phase of
project only. The goal of my work is to create sessions handling across
mul
Hello Marian,
have a guess. Di we do this change for fun? Actually we found some nasty
tricky problems.
marcus
Saturday, November 26, 2005, 1:48:15 PM, you wrote:
> Hm, strange. It used to work some months ago. My idea is to throw away
> the need of an interface for overrideing [] just like i
Hm, strange. It used to work some months ago. My idea is to throw away
the need of an interface for overrideing [] just like it is for ->. If
you mean that C coding will be a problem...I don't know but since we
were able to specify return by ref or not by ref a few months ago
(before the fix), I su
Hello Marian,
that wouldn't buy you anything becasue even if we would allow single
overrides we would have to enforce ref or non ref return.
marcus
Saturday, November 26, 2005, 4:13:03 AM, you wrote:
> Maybe magic implementation was a better idea for [] overrieding like
> for __get, __set, __
Maybe magic implementation was a better idea for [] overrieding like
for __get, __set, __isset and __unset stuff. For example __offsetGet,
__offsetSet, __offsetUnset and __offsetExists (or __offsetIsset). This
way people will be free using return by ref or not and also may
implement only some of th
Hello Oliver,
feel free to write an interface that supports return by reference and be
done.
Having ArrayAccess in use we had to chose one of two possibilities. First
go with return by reference and second go with return by copy. We chose
return by copy simply because that was the intended us
Sara Golemon schrieb:
> ArrayAccess interface for the dimension read/write.
Just to bring the issue up agaian: The current ArrayAccess
implementation does not allow for proper simulation of arrays. This has
been "broken by fixing" (tm) the method prototypes not to allow "&"
anymore in interface im
$foo = $_APPLICTION['bar'];
php_application_object::read_dimension(zval *element) {
zval *baz = fetch_from_storage_mechanism(element);
return baz;
}
Can't you hack this together today in PHP?
You just need runkit to register the superglobal.
Sure, runkit for the suplerglobal, apc for
Can't you hack this together today in PHP?
You just need runkit to register the superglobal.
--Wez.
On 11/25/05, Sara Golemon <[EMAIL PROTECTED]> wrote:
> > No, but PHP could provide a standardized frontend in the form of a
> > super-global that can have modular backends (like we have with
> > ex
No, but PHP could provide a standardized frontend in the form of a
super-global that can have modular backends (like we have with
ext/session). One backend could then use memcached as its data store.
Funny, I've been thinking of just the same thing The PHP5 OOP hooks are
just begging for tha
Andi Gutmans schrieb:
> You could use a system like memcached. This kind of thing isn't really
> in the scope of doing it in PHP per-se.
No, but PHP could provide a standardized frontend in the form of a
super-global that can have modular backends (like we have with
ext/session). One backend co
Andi Gutmans wrote:
I thought 6.9 was per-process persistent
Yeah, they are, but they are still in the same family, I think. If you
have a config.inc, for example, that populates a $config array. If you
make that persistent you only have to load it once and it will be
available to each req
I thought 6.9 was per-process persistent
At 11:50 AM 11/24/2005, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and
I can pretty much guarantee it won't happen. The SRM-like thing
doesn't need to be part of
You could use a system like memcached. This kind of thing isn't
really in the scope of doing it in PHP per-se.
At 11:19 AM 11/24/2005, Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and
I can pretty much guarantee it won't happen.
Leonardo Pedretti wrote:
On Thursday 24 November 2005 15:39, Rasmus Lerdorf wrote:
D. Dante Lorenso wrote:
All,
I have been trying to use PHP 5.0.5 for all my programming tasks
including replacing many stand-alone Java servers. I've been successful
to a degree, but I'm seriously missing Java
Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and I
can pretty much guarantee it won't happen. The SRM-like thing doesn't
need to be part of PHP though. Anybody can build such a beast.
What about something like a "persistent s
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and I can
pretty much guarantee it won't happen. The SRM-like thing doesn't need
to be part of PHP though. Anybody can build such a beast.
What about something like a "persistent superglobal"? The idea is
On Thursday 24 November 2005 15:39, Rasmus Lerdorf wrote:
> D. Dante Lorenso wrote:
> > All,
> >
> > I have been trying to use PHP 5.0.5 for all my programming tasks
> > including replacing many stand-alone Java servers. I've been successful
> > to a degree, but I'm seriously missing Java Threads.
D. Dante Lorenso wrote:
All,
I have been trying to use PHP 5.0.5 for all my programming tasks
including replacing many stand-alone Java servers. I've been successful
to a degree, but I'm seriously missing Java Threads. I've written some
code which uses SHM, Sockets, IPC, and PCNTL, but it's
20 matches
Mail list logo
