in reply to Avoiding reference of sub optimization

Is there any reason for this? Without a closure those two subroutines will be exactly the same and do and return the same things in all circumstances. So why should they be different?

UPDATE to your UPDATE: An array is different since you can change values in it. But you can't edit a subroutine "in flight"

  • Comment on Re: Avoiding reference of sub optimization

Replies are listed 'Best First'.
Re^2: Avoiding reference of sub optimization
by LanX (Saint) on Mar 21, 2011 at 14:36 UTC
    I totally understand your point about immutable subs , but...

    > UPDATE to your UPDATE: An array is different since you can change values in it. But you can't edit a subroutine "in flight"

    Actually I'm blessing them into a dedicated class to set attributes, so subs with the same body can have different attributes. (like debug informations)

    UPDATE: And yes using subs as objects isn't frequently done in Perl ...

    Cheers Rolf

[reply]
      Actually I'm blessing them into a dedicated class to set attributes, so subs with the same body can have different attributes. (like debug informations)
      Any reason why you aren't using a closure then? Which ought to give you exactly that, plus give you different references as preferred....
[reply]
        Making them all closures is what I'm planning to do now.

        I was using an inside-out mechanism to set the attributes (a hash as class-variable with the subref as key) but know I'm thinking about closing over a hash %attribute at generation.

        So no practical problem, just asking for insight.

        Cheers Rolf

[reply]
[d/l]

      Doctor, it hurts when I do this.

      I vote against Perl hiding the fact that two code references are identical and increasing memory usage to do so in order to enable a dubious use of "code reference as object".

      - tye        

[reply]
        I think everything outside your normal paths is per personal definition dubious.

        Cheers Rolf

        UPDATE: There is along list of "dubious" languages allowing the use of functions as objects. :)

[reply]

In Section Seekers of Perl Wisdom