On 2009-01-26, at 06:46:40, Mark J. Reed wrote: I seem to have been misunderstood. I apologize; I wasn't trying to over-optimize, nor was I claiming my algorithm is superior. Given past experience building lists up via &, I would not be at all surprised to find out that it performed terribly. I just threw it out there as an example of a handler that returns its result rather than modifying a global or an out parameter.
I am confused by the fact that all the previous solutions in the thread used the latter; I feel like I must be missing something, perhaps performance-related, and I seek enlightenment.
I was absolutely not trying to turn this into a "my solution is better than your solution" contest; I'm just honestly perplexed. Maybe it's as simple as the fact that the first solution used a global and later responders took their cue from that.
Well, the previous chat on this list has been that globals are bad but not properties; the reason why I agreed with your assessment.
However, the main reason for my first solution was to use 'contents of item i' because I couldn't get the OP's script to work correctly without it. I didn't even think to rework the notion as to how I would use it. And that would depend on the situation -- sometimes globals are necessary because they can contain information useful for top level branching. For the general situation of working with AppleScripts that might transfer to another language, I prefer to have input parameters because it doesn't require the other language to have the same object result that AppleScript is capable of. This is especially true of AppleEvents because they always return an integer error code.
On Mon, Jan 26, 2009 at 9:40 AM, Philip Aker < email@hidden> wrote: On 2009-01-26, at 05:56:57, Mark J. Reed wrote:
You're correct. A better plan is to use a parameter for output.
Why do you need either one? Why not just have the handler return the
flattened list? This seems to work fine:
on flatten(aList)
if class of aList is not list then
return { aList }
else if length of aList is 0 then
return aList
else
return flatten(first item of aList) & flatten(rest of aList)
end
end flatten
flatten({{1,2},3,{4,{5,{6,7},8}}})
Whatever, the problem is solved.
It's six of one, half dozen of the other to me.
For instance, the example above has an extra recursive call so we'd have to
whip out $ time osascript flatten.scpt and run it a few thousand times to
find the optimal solution.
Philip Aker
Democracy: Two wolves and a sheep voting on lunch.
|