Tom Worster wrote:
On 9/13/09 3:21 AM, "Lars Torben Wilson" <torben@xxxxxxx> wrote:
On 9/12/09 9:50 AM, "Tom Worster" <fsb@xxxxxxxxxx> 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
