>If it would behave no differently why would it need to know?

Possibly just to display a message on the screen, error/usage logging, there's probably quite a few reasons that don't affect overall behaviour. Maybe it would have been worth asking the person who asked the question why he needed to know, rather than give him all the reasons he shouldn't need to know.

>Yes, there is. If the option to append or overwrite needs to be built into the flexibility of the function, it should be passed in as a parameter, or set as a property on the object that hosts the method.
>

I know I picked a poor example there. But there is a view that if the function NEEDS to know a particular value, & has the ability to calculate/determine that value itself, it should not be passed as a parameter. It can be far safer than trusting a programmer to pass the correct parameter.

>FWIW, with the exception of error methods, I have _never_ seen a valid reason that a function should know the function that called it.

Did anyone ask the question of the person who posted the question whether or not this was what he was doing ? I thought the object was to determine the form that it was called from, not the function - I've never seen a valid reason for that either.

Can I please say (again), I was not disagreeing with the fact that it was possibly bad programming practice. My complaint was about the assumption that it was. My examples of why someone might want to do it were probably not the best, but various people have mentioned error logging as a valid reason, so there is at least one valid reason for wanting to know.