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
