develooper Front page | perl.perl5.porters | Postings from November 1999

Re: [ID 19991115.012] Localization and goto()

Thread Previous | Thread Next
Tom Christiansen
November 16, 1999 09:41
Re: [ID 19991115.012] Localization and goto()
Message ID:
ilya>> This is an implementation detail.  IIRC, it is documented that frame
ilya>> is replaced, not goes away.  What happens/should-happen with locals
ilya>> during "replacement" is debatable.

tom> If something has been replaced, it has gone away and is no longer there.
tom> If I replace your dog with a cat, you would not expect your new feline
tom> to bark; the dog is long gone.  

ilya> Whether a person ceases to exist after a sex change operation is
ilya> highly debatable.

Let's chalk this one up to a language barrier.

    1: substitute a person or thing for (another that has ceased to
       fulfil its function); "He replaced the old razor blade"

    2: take the place of [syn: {supplant}, {supersede}, {supervene

    3: put something back where it belongs [syn: {put back}]

    4: put in the place of another [syn: {substitute}]

If a frame has been replaced, then that frame *has* gone away,
*has* been substituted for, *has* been supplanted, *has* been
superseded, and *has* been supervened upon.  Your poor frame,
guardian and caretaker of an ephemeral setting of a shadowed @ISA,
had the fatal misfortune and dubious design to find itself in the
wrong place at the wrong time.  It's not just resting, playing
hooky, or changing its sex, for today is Garbage Day and the
Garbage Collectors have both come and gone.  Your lamented frame
is not merely past its prime.  It's an ex-frame.  It's pushing up
malloc space.  It's gone to the Happy Allocating Grounds in the sky.

It's a dead frame, Ilya.

ilya>> What happens, however, is making some "normal programming 
ilya>> constructs" much harder to implement.

tom> Such as?

ilya> In the particular case I needed it was
ilya>   local @ISA = (@ISA, 'DynaLoader');
ilya>   goto \&DynaLoader::bootstrap;

From the example you provided above, I see that, as it was with
"replaced", so too does your notion of "normal programming constructs"
differ significantly from my own.  This particular disparity, however,
I am rather less quick to attribute to a misunderstanding of the English
language than I am to a misplaced projection of your own peculiar
practices onto the rest of the cosmos.  Just because these constructs
might be normal in the sovereign state of Ilyania hardly implies that
they honestly deserve to be branded "normal programming constructs".
In fact, anything having to do with magical goto clearly belongs to a
completly disjoint set, that of "extra-ordinary programming constructs".

Be that as it may, I continue to fail to see any such ambiguity in the
description's wording that could theoretically permit some alternate,
conforming implementation to behave in a fashion different than the
way in which the current one behaves.  And considering that no such
alternate implementation appears imminent, even if it were truly the
case that you were being insightful rather than obstreperous in your
most unusual reading of that passage, I still find little cause for
grave concern--unless, perchance, it should happen to be you yourself
who would end up the author of that hypothetical alternate implementation.

Could it be that your problem is nothing more than, having misunderstood
what "replaced" meant in the context of the cited documentation on magical
goto, that you have developed unfulfilled expectations as to how that
construct shall and should work with respect to storage recovery or any
other action associated with the now defunct frame?  It might at this time
prove more expedient for you to attempt to devise some other mechanism by
which to accomplish whatever it is that you're actually trying to do here.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About