We probably should support this, but not only for __toString().
Objects may also have internal get() (not __get()) and cast() handlers that
should be supported too.
Also usage of cast() in context of array offset don't say what do we like
"int" or "string".
Thanks. Dmitry.
> -Original Messa
This patch fixes very specific bug.
"php -v" calls RINIT() functions, php with php-gtk throws error from RINIT
if we run php from telent/ssh session, because it cannot open DISPLAY. As
result we don't go into request shutdown (shutdown_memory_manager() is
called there) sequence and doing module sh
Rasmus Lerdorf wrote:
> I think if we are going to add a toHash thing, it should trigger when
> the object is used in a hash context, just like toString triggers when
> it is used in a string context.
This makes sense to me, too.
--
Sebastian Bergmann http://www.sebastian-b
Marcus Boerger wrote:
> 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.
+1
--
Sebastia
it looks likes there's too many spam in pecl-dev these days. is that
list moderated yet?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As far as I can see, and I'm sure someone will be kind enough to correct me
if I'm wrong, but there is no current behaviour for it, it returns a
warning.
$a = new stdClass;
$b[$a] = 0;
Warning: Illegal offset type in t3.php on line 2
And results in an empty array (in this case) so it does nothi
On Sat, June 3, 2006 6:42 am, Marcus Boerger wrote:
> 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 in
On Sun, 2006-06-04 at 20:49, Gwynne wrote:
> On Jun 4, 2006, at 8:33 PM, Michael Gall wrote:
> >> For example, for an eBay Item object, my __toString() returns the
> >> Title, but that's not unique, so my __toHash() returns the numeric
> >> ID,
> >> which is.
> > While I wouldn't be surprised if
Need to think about that but I remembered after I sent my email that
I was wrong about something like "num:num" (e.g. "3:4") requiring to
start with a letter in order not to be auto-converted to a numbered
index. The reason for the confusion is the behavior of strtol() in:
print "3:4" + 1;
Whi
On Jun 4, 2006, at 8:33 PM, Michael Gall wrote:
For example, for an eBay Item object, my __toString() returns the
Title, but that's not unique, so my __toHash() returns the numeric
ID,
which is.
While I wouldn't be surprised if you completely ignore my opinion,
however I
think the __toHash i
On 6/5/06, Adam Maccabee Trachtenberg <[EMAIL PROTECTED]> wrote:
For example, for an eBay Item object, my __toString() returns the
Title, but that's not unique, so my __toHash() returns the numeric ID,
which is.
While I wouldn't be surprised if you completely ignore my opinion, however I
thi
On Sun, 4 Jun 2006, Andrei Zmievski wrote:
> I am sorry if I missed the whole thread. I think that using the
> result of __toString() for indexing objects is a bad idea. If we want
> to allow this behavior (which is actually useful in some situations),
> I'd rather we had a __hash() method or some
On Wed, May 31, 2006 at 06:24:35PM +0400, Antony Dovgal wrote:
>
> So that E_STRICT notices introduced in 6.x will become E_FATALs only in 7.0
> and so on.
That's pretty much what I was going to say.
To be clear, unlike the commit that was recently reverted, E_STRICT should
never be moved into
I am sorry if I missed the whole thread. I think that using the
result of __toString() for indexing objects is a bad idea. If we want
to allow this behavior (which is actually useful in some situations),
I'd rather we had a __hash() method or something similar to what
Python does. The strin
There will be a BC problem with classes implementing ArrayAccess where the
array key is passed to offsetXXX methods as it is. And there we have objects
also allowed as parameters.
2006/6/3, Marcus Boerger <[EMAIL PROTECTED]>:
Hello guys,
the attached patch closes one more __toString() part.
Andi Gutmans wrote:
Again, I don't think we should have a hash but a unique id which can be
used as an array key and in other things. Difference. Hash implies that
it's not unique, I'm talking about unique. So yes, I'd take the starting
point of Marcus' proposal but:
a) Make the value start wit
Hello Stanislav,
ok, that was good explanation, thanks.
best regards
marcus
Sunday, June 4, 2006, 6:02:33 PM, you wrote:
MB>>>typedef struct _zend_object_value {
MB>>>zend_object_handle handle;
MB>>>zend_object_handlers *handlers;
MB>>>} zend_object_value;
MB>>>
MB>>>And would
At 09:05 AM 6/4/2006, Derick Rethans wrote:
On Sun, 4 Jun 2006, Andi Gutmans wrote:
> Again, I don't think we should have a hash but a unique id which
can be used
> as an array key and in other things. Difference. Hash implies that it's not
> unique, I'm talking about unique.
Instead of all t
On Sun, 4 Jun 2006, Andi Gutmans wrote:
> Again, I don't think we should have a hash but a unique id which can be used
> as an array key and in other things. Difference. Hash implies that it's not
> unique, I'm talking about unique.
Instead of all those hacky ways to come up with IDs, why don't s
Again, I don't think we should have a hash but a unique id which can
be used as an array key and in other things. Difference. Hash implies
that it's not unique, I'm talking about unique. So yes, I'd take the
starting point of Marcus' proposal but:
a) Make the value start with a letter so that th
MB>>typedef struct _zend_object_value {
MB>>zend_object_handle handle;
MB>>zend_object_handlers *handlers;
MB>>} zend_object_value;
MB>>
MB>>And wouldn't it be faster to drop both handlers from the table and
MB>>instead have zend_object_value have a pointer to zend_class_entry
MB>>a
Hello Stanislav,
do you remember any reason why we have the current layout with the zval
pointing to a handler and that having a function which returns a pointer
to the class_entry as well as a function that returns the name?
struct _zend_object_handlers {
[...]
zend_object_get_class_en
AG>>We should probably make this a requirement and I don't know of one
AG>>today that doesn't have an associated class name. I believe some parts
AG>>of PHP might blow up if this isn't supported.
There are parts that can blow up if get_class_name is NULL or returns NULL
(though good practice wo
On Sun, 4 Jun 2006, Andi Gutmans wrote:
> Yes, I realize that but it doesn't happen today and I don't think we couldn't
> make this a rule (requiring extensions to have unique id's per classes). In
> any case, we can always make it the following string:
> "id=#unique id"
And that is exactly what
Hello Andi,
you don't read my proposals, do you? If you read them you will find
that i actually proposed to add a function that uses exactly what you
just wrote here.
best regards
marcus
Sunday, June 4, 2006, 5:35:25 PM, you wrote:
> Yes, I realize that but it doesn't happen today and I don't
At 08:22 AM 6/4/2006, Stanislav Malyshev wrote:
MB>> the classname doesn't help, it is the handler that you need. In
MB>>theory you can have two objects with the same id and classname but not
MB>>with the same id and handler table.
Yes, theoretically you could have two modules returning same cl
Yes, I realize that but it doesn't happen today and I don't think we
couldn't make this a rule (requiring extensions to have unique id's
per classes). In any case, we can always make it the following string:
"id=#unique id"
Andi
At 08:18 AM 6/4/2006, Marcus Boerger wrote:
Hello Andi,
the c
MB>> the classname doesn't help, it is the handler that you need. In
MB>>theory you can have two objects with the same id and classname but not
MB>>with the same id and handler table.
Yes, theoretically you could have two modules returning same class names
for their objects, though it would be
Hello Andi,
the classname doesn't help, it is the handler that you need. In theory
you can have two objects with the same id and classname but not with the
same id and handler table.
best regards
marcus
Sunday, June 4, 2006, 5:14:46 PM, you wrote:
> At 08:08 AM 6/4/2006, Marcus Boerger wrote:
At 08:08 AM 6/4/2006, Marcus Boerger wrote:
Hello Andi,
it was your own argument that the id itself is not unique when some
time ago somebody wanted to have access to that id from userland. And
it is also the reason for SplObjectStorage the way it is today.
The object id itself is not unique
Hello Andi,
it was your own argument that the id itself is not unique when some
time ago somebody wanted to have access to that id from userland. And
it is also the reason for SplObjectStorage the way it is today.
By 'it hash' nothing to do with hash' i mean that the classname does
not belong i
What extensions today have different objects with the same object ids
(inside a certain class)?
What do you mean it has nothing to do with hash? Don't understand
what you mean.
At 07:56 AM 6/4/2006, Marcus Boerger wrote:
Hello Andi,
the classname has not make the id unique. In fact it has
Hello Andi,
the classname has not make the id unique. In fact it has nothing to
do with a hash.
best regards
marcus
Sunday, June 4, 2006, 4:26:13 PM, you wrote:
> I would suggest :
> a) Make sure $arr[(string)$obj] works (I see no reason for it not to).
> b) Look into how to support a uniqu
On 4-Jun-06, at 10:26 AM, Andi Gutmans wrote:
I would suggest :
a) Make sure $arr[(string)$obj] works (I see no reason for it not to).
It already does, nothing needs to be changed or added.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
I would suggest :
a) Make sure $arr[(string)$obj] works (I see no reason for it not to).
b) Look into how to support a unique identifier (-1 on a hash value).
Two main questions are how this thing looks like, and whether it's
explicit (you need to call some function/method to get it) or
implici
Hello Pierre,
Sunday, June 4, 2006, 2:05:52 PM, you wrote:
> On 6/4/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> Adding a function hash_from_object() or spl_hash_from object() to ease
>> > the generations of hashes is indeed a good idea. There is no impact in
>> > the objects managements an
Hello Dmitry,
the 'f' requires at least the first helper, so it makes sense to have
all three of them in the engine. Attached you will find the patch for
the helpers and the 'f' thingie for 5.2 and an additional patch for SPL
to introduce iterator_apply() which uses the stuff.
marcus
Wednesday
On 6/4/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Adding a function hash_from_object() or spl_hash_from object() to ease
> the generations of hashes is indeed a good idea. There is no impact in
> the objects managements and people are free to use it or not (no magic
> default behaviors).
H
Hello Pierre,
Sunday, June 4, 2006, 1:52:41 PM, you wrote:
> Hello,
>> Hello Rasmus, Andi,
>> [EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new
>> stdClass));' string(32) "0bab1548e3b42acbcf1170617b5432ae"
>>
>> For PHP 5.2 we could think about adding a hash handler to
On Sun, 4 Jun 2006, Michael Wallner wrote:
> 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
Hello,
> Hello Rasmus, Andi,
> [EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new
> stdClass));' string(32) "0bab1548e3b42acbcf1170617b5432ae"
>
> For PHP 5.2 we could think about adding a hash handler to the object
> handler table and provide the above as default implemen
Hello Eric again,
forget the last mail, you're right it is hasNext() in php, too. So it
should be array_has_next() as well. Thanks to michael for reminding me.
I got confused with the original implementation (i shouldn't have changed
the name).
best regards
marcus
Sunday, June 4, 2006, 1:39:04
Hello Eric,
our iterators have next() and valid() in separate functions. That alone
makes them way more powerful then java' iterators. In SPL we have an
iterator wrapper called CachingIterator that has a method has_more()
which has a boolean return value that allows to check whether a call to
ne
Hi,
Took from Java world, it could be something like array_has_next() which is
more significant because return boolean is only about the next value not
about all the next values.
On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Andi,
Wednesday, May 31, 2006, 5:28:47 AM, you wrote:
Andi Gutmans wrote:
Can you give a short summary of what the essence of the change is and
how the APIs have changed (Both the ones available to the PHP
developer and to the extension writer?)
To come back to that topic; there are certainly some implications
to think about, some of the top o
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.
-1 on a
Hello Rasmus, Andi,
first to Andi, there is no BC involved beside the fact that this would
allow objects being used in arrays which wasn't possible before.
Now a hashing value can easily be generated:
char * hash;
int len = spprintf(&hash,0,"%p:%d",Z_OBJ_HT_P(zobj),Z_OBJ_HANDLE_P(zobj));
That s
In case we can't find a solution Andi's (a) approach, I think I like
the explicit cast approach better than just implicitly converting to
string. Rasmus pointed out that it's not clear why of all types PHP
would implicitly convert the object to a string, and chances are that
he's not the only
Not a lot (attached)
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Sunday, June 04, 2006 11:31 AM
Subject: Re: [PHP-DEV] Fw: small note about interface registration
Hello Steph,
what did you fix in spl
Whichever way we go, the key would have to be either an integer or a
string (since that's what array indices can be), and going with an
integer here sounds like a really bad idea (chances of it colliding
with numeric indices are reasonably high on a 32-bit system). So if
we go with (a), it wou
Hello Steph,
what did you fix in spl and reflection?
best regards
marcus
Sunday, June 4, 2006, 9:05:02 AM, you wrote:
> I take it back, fixing that in SPL and reflection _did_ do something :)
> The only problem left now is that DL_UNLOAD's called too soon - we need
> ts_free_id() to be call
I take it back, fixing that in SPL and reflection _did_ do something :)
The only problem left now is that DL_UNLOAD's called too soon - we need
ts_free_id() to be called in the Zend module_destructor, but DL_UNLOAD to be
called at the end of tsrm_shutdown() - or at least, after the global core
52 matches
Mail list logo
