The original intent is to be compatible though in this particular case,
I don't particularly favour the idea of fixing it.
Adam Cameron wrote:
Irrespective of what Sean says, what was the *original intent* here?
Was it to copy the whole thing (like CF would), or just copy the ref
(like other languages generally do, as Sean - quite rightly - says).
It's difficult to tell due to how things seem to have eben implemented
to sometimes do one thing, and sometimes do another.
There's an argument with staying true to how CF decided to do it, be
that the best way or just the way that keeps you most compatible.
There's also an argument to do the better way, as it's really not
often that there'll be an issue anyhow. But there must've been some
initial decision to do it one way or the other, and I reckon that's
how the issue should be addressed.
I *suspect* the original intent was to go the reference route, but it
would be best to check, I guess. If, that is, there's anything to
check against.
If you decide to diverge from how CF does it, you should probably
document that to be the case, too.
(all the above is just "IMO", and "because you asked", btw).
And, above all else: cheers for looking into this!
--
Adam
On Oct 18, 3:44 pm, Andy Wu<[email protected]> wrote:
Given your test case Adam, I initially thought the problem was down to
the function return handling.
But given Sean's example, I see it's actually the assignment where
things are going wrong.
I can fix that particular issue by duplicating the value when the RHS of
the assignment operation is an array but that seems overkill and likely
to introduce a new issue if there are situations where you wouldn't
expect that to happen. Just trying to think if there are any.
Thoughts welcomed.
Andy
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
official manual: http://www.openbluedragon.org/manual/
Ready2Run CFML http://www.openbluedragon.org/openbdjam/
mailing list - http://groups.google.com/group/openbd?hl=en
