http://www.perlmonks.org?node_id=995254


in reply to Re^2: Accessing a scalar value in another subroutine?
in thread Accessing a scalar value in another subroutine?

Yes. I read the docs; but would still like to a see an example of actual, practical use.

The only example I've seen that makes any logical sense at all (to me), is the ability to query the information in a repl.

But that extremely limited-use facility, does not justify burdening the runtime with the overheads it imposes, in a language who's runtime has facilities designed to support it.

Emulating that limited-use facility in a language the does not have runtime facilities to support just imposes addition runtime costs for no conceivable benefits.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

  • Comment on Re^3: Accessing a scalar value in another subroutine?

Replies are listed 'Best First'.
Re^4: Accessing a scalar value in another subroutine?
by LanX (Saint) on Sep 23, 2012 at 21:41 UTC
    > Emulating that limited-use facility in a language the does not have runtime facilities to support just imposes addition runtime costs for no conceivable benefits.

    yes, avoiding runtime costs is the real problem.

    > The only example I've seen that makes any logical sense at all (to me), is the ability to query the information in a repl.

    docstrings are mostly oneliners (at least in elisp)

    Other applications are methodbrowsers/tabexpansions showing additional infos.

    Or tooltips in IDEs when hovering the mouse over a method call.

    PODs are not DRY, the subname must be repeated, docstrings are automatically at the right place.

    see also:Re^2: Accessing a scalar value in another subroutine?

    Cheers Rolf

      yes, avoiding runtime costs is the real problem.

      It shouldn't be.

      Avoiding imposing penalties on 99% of people's code that have no use for such esoteric facilities, to satisfy the 1% that thinks it might be a good idea, should be simple.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong