Guys/gal,
At the risk of being boring, someone should probably know that the
ZEND_ACC_INTERFACE flag isn't getting set for anything outside the Engine
during zend_register_internal_interface(). zend_API.c needs to #include
zend_compile.h to get it defined, unless you know a better way.
SPL a
Marcus Boerger wrote:
> Hello guys,
>
> the attached patch closes one more __toString() part. It allows
> to use objects that define __toString as indexes to arrays. What do
> you guys think about this, should we add it or stay with the old
> behavior that didn't allow objects as indexes at all.
erm, _with_ attached output!
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: "Dmitry Stogov" <[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Sunday, June 04, 2006 5:02 AM
Subject: [PHP-DEV] More diagnostics - win32/shared extension shutdown
OK people, I'm finally getting somewhere with this one now. More
diagnostics:
In debug mode, the Tidy extension crashes with an assert failure at exactly
the same point PHP-GTK release version dies - during the call to
zend_hash_destroy(compiler_globals->class_table) from
compiler_globals_dt
On Sat, 03 Jun 2006 18:50:09 -0700
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> This works today and basically gives you the same thing. The only
> thing it doesn't do is separate an array index context from an output
> context allowing you do different things in the two cases.
>
> I think if we
Alan Knowles wrote:
$x = new Obj;
$y[$x]= 123;
That behaviour is going to be fun to document, and for people unfamilar
with it to find in the manual
-> php.net/array -> go to array syntax page -> read down to find about
objects as keys -> go to __toHash() page...
..whereas...
$x = new Obj;
$x = new Obj;
$y[$x]= 123;
That behaviour is going to be fun to document, and for people unfamilar
with it to find in the manual
-> php.net/array -> go to array syntax page -> read down to find about
objects as keys -> go to __toHash() page...
..whereas...
$x = new Obj;
$y[$x->toHash()]= 123
Yep that is also a choice, although it can be advantageous to have an
automatic (a) which people just now works, always...
I don't think it's a critical problem because as you pointed out
people can deal with it, but I think it'd be nice to provide some
tools to make life easier.
At 06:01 PM
Hi,
On 6/4/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Generally I think it's a good thing to allow to use objects as array
> indexes. There are really two ways of doing it:
> a) Try and find a way to create unique ideas.
> b) Support __toString() and leave it up to the author.
I see a third ch
Generally I think it's a good thing to allow to use objects as array indexes.
There are really two ways of doing it:
a) Try and find a way to create unique ideas.
b) Support __toString() and leave it up to the author.
I have a bit of a hard time finding a solution to (a) unless the
unique id is
Gwynne wrote:
> no attempt
would/should be made to calculate a hash based on anything other than
what the object is willing to call itself.
+1 here
oo people have a name for that.
and implement what's needed.
I'm surely out of talk , but please keep indexes scalar.
The toString way is anyway
On Jun 3, 2006, at 6:12 PM, Jasper Bryant-Greene wrote:
I would imagine that __hash() or whatever it is called would be
defined
on all objects and implemented internally in PHP, and would simply
generate some internal hash that is unique for all objects.
That might work for initial testing, b
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gwynne wrote:
> I'm new to this list, so I apologize if I'm out of line in commenting
> here, but it's my opinion that the advantages offered by a __hash()
> magic function would outweigh the inevitable complexity and issues
> involved. I imagine
On Jun 3, 2006, at 1:13 PM, Rasmus Lerdorf wrote:
RL>>I don't understand why using the object as an index would
trigger a RL>>__toString() call. PHP's array indices are not
defined to be strings, RL>>so I don't see this as being a string
context use and thus
RL>>__toString() shouldn't be c
Stanislav Malyshev wrote:
RL>>I don't understand why using the object as an index would trigger a
RL>>__toString() call. PHP's array indices are not defined to be strings,
RL>>so I don't see this as being a string context use and thus
RL>>__toString() shouldn't be called.
If so, what should
Right, just let me clarify. My point here was that if we are going to
make a change here, we should do it correctly and come up with a way to
create a unique hash of the object so it really can be used as an array
index. Magically calling __toString() in a case where we don't have an
explicit
RL>>I don't understand why using the object as an index would trigger a
RL>>__toString() call. PHP's array indices are not defined to be strings,
RL>>so I don't see this as being a string context use and thus
RL>>__toString() shouldn't be called.
If so, what should be the actual key in the has
Hello Rasmus,
though you are probably right here your idea brought to it's full
extend will bring a major BC break. Just consider we had both key
and value as a zval then the current behavior would change for quite
a lot of situations including not only objects and resources but also
booleans, f
Hello Andrew,
Saturday, June 3, 2006, 4:36:39 PM, you wrote:
> On Sat, Jun 03, 2006 at 01:42:12PM +0200, Marcus Boerger wrote:
>> Hello guys,
>>
>> the attached patch closes one more __toString() part. It allows
>> to use objects that define __toString as indexes to arrays. What do
>> you guys
I don't understand why using the object as an index would trigger a
__toString() call. PHP's array indices are not defined to be strings,
so I don't see this as being a string context use and thus __toString()
shouldn't be called.
I also don't see why we need to make a distinction between the
I think this is a potentially missing bit of functionality we
definitely need to consider including. There is really no technical
reason why $foo[new ToStringObject] = "bar"; cannot work or a reason
why it shouldn't as far as functionality goes.
Ilia Alshanetsky
On 3-Jun-06, at 7:42 AM
On Sat, Jun 03, 2006 at 01:42:12PM +0200, Marcus Boerger wrote:
> Hello guys,
>
> the attached patch closes one more __toString() part. It allows
> to use objects that define __toString as indexes to arrays. What do
> you guys think about this, should we add it or stay with the old
> behavior th
On Sat, 3 Jun 2006, Marcus Boerger wrote:
> Hello Robert,
>
> well lazy is a good point here but __toString is all about lazyness.
> Then again as said you might want to have objects naturally convert
> to strings whereever possible. Generally when providing a __toString
> implementation you sa
On 6/3/06, Robert Amos <[EMAIL PROTECTED]> wrote:
Thats fair, as long as it doesn't result in any unwanted behaviour then I'm +1.
Good luck ;-)
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Thats fair, as long as it doesn't result in any unwanted behaviour then I'm +1.
-Rob
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Robert,
well lazy is a good point here but __toString is all about lazyness.
Then again as said you might want to have objects naturally convert
to
Hello Robert,
well lazy is a good point here but __toString is all about lazyness.
Then again as said you might want to have objects naturally convert
to strings whereever possible. Generally when providing a __toString
implementation you say that you want this. And then you might as well
expect
Hi,
Is it really worth enabling a whole new area where problems could
occur just for this? Can you provide an example of where it might
actually be considered useful and not just being lazy?
-Rob
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Pierre,
ever thought that we use tes
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Pierre,
ever thought that we use tests to check special behavior and that
those snippets have little to do with real applications? Obviously
not. The idea behind is that for instance you might use an array as
a translation and use an o
Yes definitely, that functionality would be useful.
Regards,
Michael
On 6/3/06, Pierre <[EMAIL PROTECTED]> wrote:
Hi,
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello guys,
>
> the attached patch closes one more __toString() part. It allows
> to use objects that define __toString
Hello Pierre,
ever thought that we use tests to check special behavior and that
those snippets have little to do with real applications? Obviously
not. The idea behind is that for instance you might use an array as
a translation and use an object to *calculate* the index.
Saturday, June 3, 2006
Hi,
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello guys,
the attached patch closes one more __toString() part. It allows
to use objects that define __toString as indexes to arrays. What do
you guys think about this, should we add it or stay with the old
behavior that didn't allow
Hello guys,
the attached patch closes one more __toString() part. It allows
to use objects that define __toString as indexes to arrays. What do
you guys think about this, should we add it or stay with the old
behavior that didn't allow objects as indexes at all.
--
Best regards,
Marcus
Hello Andi,
Wednesday, May 31, 2006, 5:28:47 AM, you wrote:
> Zeev and I designed each() to deprecate key()/current()/etc. which
> came from PHP/FI 2. Maybe not exactly what you're looking for but
> just want to point out that there have always been some issues with
> the latter functions.
> I
33 matches
Mail list logo
