phpjs
Version:
82 lines (55 loc) • 5.44 kB
HTML
<!-- Generated by Rakefile:build -->
<strong>
Onno Marsman
</strong>
on 2009-01-15 21:00:08 <br />
About your last paragraph: I don't see the need to make a distinction between an object and an associative array either. That's why I've always said I think they should both be considered objects (which they really are) and only be treated as an associative array in functions that expect an array and not an object (is_array clearly doesn't expect an array, you can pass an object to is_array in PHP which will return false)
But I really don't care much about these types of functions because I'll never use them. So as far as I'm concerned: feel free to do anything. I just can't help replying to stuff like this when I see things getting more complex than I think they need to be.
<hr />
<strong>
<a href="http://kevin.vanzonneveld.net" rel="nofollow">Kevin van Zonneveld</a>
</strong>
on 2009-01-14 10:52:43 <br />
@ Onno Marsman: Again, because this was such a controversial decision, I cannot be assured that we never change it's implementation. I think other functions should be aware of this uncertainty and allow for different approaches we may or may not take in the future.
Take Brett's point for example: for me this may be the most acceptable way of distinguishing objects from arrays I've seen so far. But inded: only if the length property is already present, I will never want php.js to pollute user data.
And so that basically means the length element will always have to be added by the users themselves. Which is very un-php-like and would require documentation throughout the project to keep pointing that out to everyone using associative array functions.
From a PHP point of view: What would be the need to even look at objects differently than associative arrays. Maybe it's just me but I cannot imagine many situations that would require this distinction. If you look at it from a JavaScript perspective: yes, but then, you should also just use javascript statements if you want that.
<hr />
<strong>
Onno Marsman
</strong>
on 2009-01-13 18:18:20 <br />
Sorry, Brett, didn't read your comments, you already mentioned this, though I wouldn't solve it the way you suggest because of the argument against this you provided yourself.
Didn't contribute much here, did I... sorry ;)
<hr />
<strong>
Onno Marsman
</strong>
on 2009-01-13 18:14:17 <br />
the function gettype will never return 'object' the way it is currently implemented.
<hr />
<strong>
<a href="http://bahai-library.com" rel="nofollow">Brett Zamir</a>
</strong>
on 2009-01-13 15:22:47 <br />
Np at all...
I guess you mean &quot;class-like functions will be presented as 'function'&quot;? Since PHP doesn't even allow classes or functions as data like in JavaScript (except callbacks represented as strings), I guess it wouldn't hurt to return &quot;function&quot; as it does now. But as it is now, there's no way to get &quot;object&quot; back, as in PHP, since you're treating them as arrays.
As far as polluting user variables, rather than adding the 'length' property to an object that doesn't have it, I'm now just suggesting that if objects are passed in without 'length', then they should be considered regular objects and not arrays. This will make type detection more clear, and it is a good practice to encourage adding 'length' if it is to be an &quot;array-like object&quot;. Some extensions like array_push() could even increment this property for the user, if it were present (though that need not be enforced, as array-like objects often let the user handle the length handling, though I think it would be convenient for PHP-JS to handle). I think the danger of someone including a &quot;length&quot; property on an object and our treating it as having some other meaning (though we wouldn't need to change it, if you don't want) would be much less prevalent than someone expecting, for example, is_array() to return false for a regular object. JavaScript doesn't even guarantee that objects will be iterated in order (though they always seem to be), so I think it is more standard to only treat them as arrays if the user is doing something to make them seem that way. But it's of course your call.
Thanks for your hard work in keeping up with us! Your thoughtful quality control really adds clout to the project...
<hr />
<strong>
<a href="http://kevin.vanzonneveld.net" rel="nofollow">Kevin van Zonneveld</a>
</strong>
on 2009-01-13 13:12:18 <br />
@ Brett Zamir: strval: yeah stupid, it was late last night ;)
This is actually the exact same discussion as with is_array. 'Polluting' user variables is never an option in my eyes.
But class-like objects will be presented as 'function' right?
<hr />
<strong>
<a href="http://bahai-library.com" rel="nofollow">Brett Zamir</a>
</strong>
on 2009-01-13 02:47:51 <br />
Hi Kevin,
A couple things... First, &quot;type&quot; should not be added to the final return result. strval() just gives the value unless it is an array, object.
Also, by using is_array() which returns true for objects, putting in an object gives &quot;Array&quot;. Maybe to resolve that issue, you could require that people who wish to use objects as arrays add a length property? I think that might be a good compromise (of course the functions would need to be programmed to ignore the length property).
<hr />