Change value of a variable in parent function?

[d d]

Hi, I don't think this is possible but it's worth asking.

Is there any way a function can change the property of a variable
in the caller function? Here's a simplified example of what I have:

function mainfunc(){
var myvar = unchangeable_broken_func();
var myvar2 = childfunc2(); //I CAN change this one
...
}
function childfunc2(){
return something_for_myvar2;
}

You see that mainfunc's myvar is being set by the broken function. The
problem is that it's setting it wrongly in a unique situation. Due to QA
resources and schedules, there's no way I can change mainfunc or
unchangeable_broken_func.

I can, however, do things in childfunc2. That's a special customer
optional function. For a specific customer, for a short-term fix, I'd
like to add some code into childfunc2 that basically works around the
bad logic in the broken func.

In visual studio I've seen that this code in childfunc2 works:

childfunc2.caller; //this gives a handle to mainfunc
childfunc2.caller.toString(); //shows the code of mainfunc

I'm looking for a possible syntax that would allow me to change the
mainfunc's myvar variable from childfunc2. Then I can add some logic to
childfunc2 that looks for the unique circumstance that makes the broken
function go wrong and I can auto-correct myvar.

Possible ?

~dd

 

[Martin Honnen]

I'm looking for a possible syntax that would allow me to change the
mainfunc's myvar variable from childfunc2. Then I can add some logic to
childfunc2 that looks for the unique circumstance that makes the broken
function go wrong and I can auto-correct myvar.

A nested function can do that, looking like this:

function f () {
var a = 1;
function g () {
a = 2;
}
g();
return a;
}
alert(f());

But in your case I don't see a way as the second function is simply
being called in the body of the first function.

 

[d d]

A nested function can do that
But in your case I don't see a way as the second function is simply
being called in the body of the first function.

That's what I thought, and would have told anyone that asked me. I've
seen some ninja kung fu from you guys on here though and thought it was
worth a try.

Thanks! btw, the annoying thing is, it should have been a nested
function anyway, but it's several years old and is what it is :-(

~dd

 

[rf]

Due to QA resources and schedules, there's no way I can change mainfunc or
unchangeable_broken_func.

Your QA people are going to *knowingly* sign off broken code? Does the
client/CEO know about this?

 

[The Natural Philosopher]

Your QA people are going to *knowingly* sign off broken code? Does the
client/CEO know about this?

Welcome to the Real World :-(

 

[d d]

Welcome to the Real World :-(

I think you misunderstood slightly. This is code that was QA'ed last
year and has been working since then without problem. It's run billions
of times on hundreds of sites. It's just recently we've discovered (for
one client only) that there are some circumstances where it doesn't work
as expected. Even for that client, those circumstances are hard to
recreate. I've already fixed the problem, but I can't release it for ALL
clients.

~dd

 

[rf]

I think you misunderstood slightly. This is code that was QA'ed last year
and has been working since then without problem. It's run billions of
times on hundreds of sites. It's just recently we've discovered (for one
client only) that there are some circumstances where it doesn't work as
expected. Even for that client, those circumstances are hard to recreate.
I've already fixed the problem, but I can't release it for ALL clients.

Then fix the problem, in that other function, Have QA endorse your fix and
let it flow into the next relase of the product. You don't need to "release
it to all clients" just now because it does not affect them but make damn
sure your fix is backward compatible so any existing clients will not barf
when they do upgrade. The existing clients are happy. The new one is. QA
should be because you have found a potential bug (well, you did, didn't
you).

Do not not for Deitys sake, take the approach you describe. Introducing an
unreliable hack to "mend" some code in a function that is not within your
control. Therein lies the way to unmaintainable speghatti code and you would
be working exactly against QA. What happens when, unbenownst to you,
somebody else "maintains" that other subroutine and renames the variable.
Your code would break. What would QA say about that? What would your boss
say about that?

In answer, var means local to this function. Full stop. Local means stopping
exactly the thing you are trying to do.

 

[d d]

Then fix the problem, in that other function, Have QA endorse your fix and
let it flow into the next relase of the product.

I have fixed it properly and cleanly and it passed a smoke test. I did
that before my first post about this. They plan to do a full QA on it
with a full OS/browser matrix in August (after the current sprint is
over) but it won't be released until September. There's no problem with
this side of it. I'm not sure how we got this deep into the issue ;-)

The only problem is that this one customer that is experiencing the
issue. They need a workaround to keep them going until September.

Do not not for Deitys sake, take the approach you describe. Introducing an
unreliable hack to "mend" some code in a function that is not within your
control. Therein lies the way to unmaintainable speghatti code and you would
be working exactly against QA. What happens when, unbenownst to you,
somebody else "maintains" that other subroutine and renames the variable.
Your code would break. What would QA say about that? What would your boss
say about that?

What did my boss say? He said if we don't get some kind of patch for
this one customer then we risk losing their business

~dd

 

[rf]

I have fixed it properly and cleanly and it passed a smoke test. I did
that before my first post about this. They plan to do a full QA on it with
a full OS/browser matrix in August (after the current sprint is over) but
it won't be released until September. There's no problem with this side of
it. I'm not sure how we got this deep into the issue ;-)

The only problem is that this one customer that is experiencing the issue.
They need a workaround to keep them going until September.


What did my boss say? He said if we don't get some kind of patch for this
one customer then we risk losing their business

[unsnipped, on purpose]

Rock <> hard place.

Run. Run very very quickly, very far far away.

Your boss is just about to be thumped very badly by QA. He should have
esclated this problem a long time ago.

You (read: your CEO) can afford to lose *one* customer because you cannot
fix a certain bug. You cannot afford to lose *all* of them when you are
found out to be producing bad code, spegathied for whatever reason.


You snipped the bit where I said you cannot do this.

 

[d d]

Rock <> hard place.

Run. Run very very quickly, very far far away.

I'm waiting for Larry and Sergey to call me up and offer me a billion in
stock options to run to Google.

Your boss is just about to be thumped very badly by QA. He should have
esclated this problem a long time ago.

The problem was only discovered on Friday. I wish you were the boss of
our QA ;-)

You (read: your CEO) can afford to lose *one* customer because you cannot
fix a certain bug. You cannot afford to lose *all* of them when you are
found out to be producing bad code, spegathied for whatever reason.

When the customer is this big and could represent 25% of our company's
income in the next year we get flexible.

You snipped the bit where I said you cannot do this.

I'm sure that if I wrote 100 lines of text explaining the full situation
you'd see that it's not that bad. I'll try and summarize. We have this
QA'ed and tested library that's on a public server for our clients to
use. For all except this problematic customer, it's working just fine
and has no problems. These other customers couldn't get this problem
even if they tried. All our customers are pointing their apps to this
code. Naturally I can't change anything on there without a full QA test
matrix and backwards compatibility testing with the clients. I've
already implemented the clean fix in our current development build and
that's what we'll release in September.

When clients use this library, they make calls to certain functions and
they have code of their own. I wanted to tell this client that's having
the problems, hey, you can implement your own workaround if you want -
until our next release. Leave it up to them. As I've learned here, I
can't tell them that. There's no way of changing that parent functions
variables, so that's the end of that road.

Instead what I've had to do is make a duplicate copy of the library and
put it on the server in a different location and it has just one extra
line of code in it that fixes the problem specifically for them. We'll
tell them to point to the custom library until the next release, at
which point they can switch back to the regular production library.

I know, it's not great, but it's being flexible that keeps customers.
They appreciate that it's a temporary workaround and they're as keen as
anyone to use it.

~dd