Re: get an object property

Tom Worster wrote:

On 9/13/09 3:21 AM, "Lars Torben Wilson" <torben@php.net> wrote:

On 9/12/09 9:50 AM, "Tom Worster" <fsb@thefsb.org> wrote: but let me give you a more different example: $a and $b are normally both objects, each with various members including a prop q, but sometimes $a is false. i want the q of $a if $a isn't false, otherwise that of $b. ($a ? $a : $b)->q // is not php, afaik before you suggest one, i know there are simple workarounds.

You're right, that isn't PHP syntax. One workaround that came to mind which does a similar thing (although using a different mechanism) is this: ${$a ? 'a' : 'b'}->q

i would not have thought of that. interesting...

and while i'm at it, and using my original error, how come... function o() { return (object) array('q'=>7); } echo o()->q; // is ok syntax, but function a() { return array('q'=>5); } echo a()['q']; // isn't?

I'm afraid I can't answer that right now--it does perhaps seem inconsistent at first glance, although I can't say I've ever missed it or felt that using syntax like that would make my life any better. Maybe it would. Then again, I can also see an argument being made for allowing the object syntax but not the array syntax: in the case of objects, you can have a clean class declaration which is pretty much self-documenting, and later users of the class can have a clear idea of which properties are available and which are not, and they can thus be sure that o()->q will not result in uninitialized property problems. Using the array syntax you could never be sure that the index requested actually exists. Of course, this holds true only for people like me who don't really like the idea of creating objects on the fly in PHP unless there's a very good reason to. Usually in PHP such tasks are better handled by arrays anyway.

the dbms abstraction library i use delivers rows, by default, as objects. so i commonly handle dynamically generated data in the form of objects, though it's not my code generating those objects. i think that's one reasons why i often find i would use objects as data structures. and because i find the dynamic objects in js convenient. Yeah. . .never been a fan of the libs which return objects, although such a model does

perhaps have its uses.

but i think you're preference reflects more closely was probably the concept of php's version of oop: an object is an instances of a static class.

Yes, I'd say the same thing, except I'd replace the term 'static' with 'declared'. If an object is created on the fly, in someone else's code, and I have to maintain that code, then either that code must be well-documented or I have to go on a hunt through the source code to find out what might be available within that object. Not my idea of fun. Convenient for the original coder, perhaps, especially if they come from an automatic model background such as Javascript. And maybe one day I'll come to love it. So far I haven't seen enough of a benefit to convince me that it's worth the long-term maintenance headache it can (note that I say "can", not "does") cause.

in any case, now that i've confirmed that i'm not merely unaware of the features i was hunting for, and that they don't exist by design, i can perhaps move on. on a related note, way back when xml was ascendant as "the most exciting new technology to hit the net since java", i was not impressed. what a horrid syntax for specifying and communicating data, i would argue. why not use the syntax from some sensible programming language instead? js, for example? easy to parse, less overhead, human readable (i find xml hard to read), etc. then eventually json happened, without all the hype and fanfare, just doing the job very conveniently. i love it. I also never found myself sold on the "XML everywhere" philosophy which seemed to

spring up during its first few years. I have found it useful for certain things--usually involving documents. :) It's awesome for technical documentation such as working on the PHP manual; I've used it when writing books; and XML and the DOM can be a great help when constructing automatically validated XHTML. But there are also many other things which people insisted it would be perfect for which just end up being a waste of cycles and memory. It's a good tool for some tasks but completely ill-suited for others IMHO. I like the idea of json when working with Javascript. Years ago (before var_export()) I wrote something very similar to var_export() which would write out a human-readable and directly PHP-parseable string for structured data. Sort of like. . .er. . .pson (*cough*). ;)

and to make that comment vaguely php related, i now use json to encode structured data that i want to write to the php error log. Interesting. For something like that I would just use var_export() and skip the overhead

of parsing json back into PHP if I needed to do that. I'd use json when using Javascript, though. But whatever makes you happy--I'm certainly not here to try to change anybody's mind about that sort of thing. Cheers, and good luck with the explorations! Regards, Torben