I can fully understand both stances on this topic, and I'm not saying we should not be allowed, as such. But more, we should try to understand that there are very good reasons why this is, so far, not allowed and perhaps that these reasons slightly, or even greatly outweigh the necessity to perform such changes, in the main.
Just this morning as it happens...
I'm knee deep in a full line upgrade project here at the moment and have just completed the project software yesterday for a 1769-L33ER controller and PanelView 5500 HMI. I'm just configuring all the PowerFlex 525 drives and Stratix 8000 switch here and will likely go live tomorrow or Saturday (argh)...
In the program, I have a few AOIs added or newly created to do very particular things. Some are generic for solenoid valve, motor, and drive control, etc. and some are pretty unique, like specific oven system control (quite old).
In the middle of all this, I've just created a simple but useful AOI to convert HMI timer value entries and apply the values to the relevant timers. Probably overkill, but I'm like that. I was asked could I add some spare AOI (ability to change timer values on HMI) for the Engineering Staff and expose its core functionality so they could modify its uses to do certain other "things" in the future. I tried to explain to the Plant Engineer, Operations Manager and some of the pretty savvy Engineering Staff who are Logix 5000 trained, that, besides it not being possible, if I do that then the first instances, which are doing something different now, will be affected, and could result in unpredictable line control. It's "one rule for all".
Despite my best "verbal" efforts, they really could not grasp it at all well. They kept thinking that each instance is being edited separately. I pointed out that how ever much you want that to be the case, it will not be. It's not that something cannot be done to achieve their goal, but just that the existing AOI route is a dead end (unless I get real fancy with it). I can make other AOIs to do what they specifically want, or use other methods, but that won't do as they want versatility, of which I thought I was providing - solutions. Management went off a bit disgruntled, but I showed a couple of the Engineers the software, how the AOI works, again, and what I meant by "one rule for all". One of them, a new Engineer, was actually the one suggesting I do this "mod" for them and kept questioning me, which I do welcome. I thought by explaining he would learn the pitfalls - you can change a timer instruction's preset for a single instance because those instruction defined parameters and their data types are exposed to the user. Likewise you can change the AOI parameters that are similarly exposed. But you cannot change how the timer operates as an instruction, nor can you change how the AOI operates as an instruction, while online. If you could, you would be changing it for all instruction instances already used or to be used and not just for a single instance. And so on...I got the prerequisite stares and nods of agreement and affirmation, but little else asked or said.
But a little knowledge can be dangerous. Later this morning, another Engineer came to me and said "...he's on his workstation trying to prove you wrong!...he's told them he can probably do it...". He'll keep at it, I'm sure, but I'll leave him to his own "devices", for now. For this one Engineer, I'm sure it will take several more "instances" of the "George instruction" before it sinks in.
Of course, we're not all as ignorant to the facts and as stubborn to boot. But I'm sure I could argue that there are far, far fewer of us programmers out there at the level that we could safely say won't mess things up here. I'm often for "open source" thinking, but I'm always "safety first" minded.
I'm sure we'll continue to politely think differently here, and that's OK too. If they do ever give us this ability then I'll use it as safely and as best I see fit, and make sure I'm aware of those pitfalls. But I do envisage such a feature creating plenty of "work" for a lot of us regulars here on the Forum.
G.