Re^9: no chunk is too small

I’m just trying to think of a rule by which this could be made consistent and non-surprising, but failing to. I suppose it would be okay to disambiguate the desired behaviour for lexicals on the presence of a my on the loop construct – but then what about globals? Should they always be aliased? I don’t like that – I’d definitely want parity here, else people are going to have to be taught about the subtlety that foreach behaves differently when given a global than when given a lexical. Maybe require foreach our $pkgvar to get aliasing for package variables? That would be strange, though, considering the actual semantics of our. And then what about $_ – do we leave it as a strange exception case?

Given that it would be so difficult to find sane semantics to support the non-aliasing behaviour, as well as that IME you want the aliasing behaviour 99.9% of the time, I think it’s clear why my preference is to just punt on this issue. I understand why you would prefer it otherwise, and I agree that it would be nice to have this behaviour, but I think there are just too many issues to untangle once you venture past the use case in your sample code.

Maybe TimToady could let this all stew for a while and come up with one of his trademark lucid decompositions, but I can’t think of anything more desirable than the current 80/20 solution.

Makeshifts last the longest.

Comment on Re^9: no chunk is too small Select or Download Code

Replies are listed 'Best First'.
Re^10: no chunk is too small by BrowserUk (Patriarch) on Nov 14, 2005 at 04:44 UTC
but then what about globals? Should they always be aliased? ... And then what about $_ – do we leave it as a strange exception case? $_ already is a "strange exception", it gets used without being mentioned and has a myriad of magical behaviours associated with it (that I wouldn't want to loose), this would continue the tradition of that variable. In the case of other globals, I hadn't really thought about them much as I don't make use of them much, but having thought about it, I don't think that there is a case for localisation. If they already exist in the symbol table, they have been used before, and should not be localised. The programmer has explicitly indicated that they wish to re-use this variable, and any changes should persist. Trust that the programmer knows what they are doing. If the programmer wants to both re-use an earlier global, and retain it's original value afterward, he has the option to localise it himself--just as he would have to in any other situation. If the variable does not yet exist in the symbol table, there is no great value in localising it, and you remove the potential for using it's final value subsequent to the loop. So basically, $_ is special--because it is already special--and for any other variable, the user controls localisation through the keywords my or local, just as he would for any other construct. Seems to me that would be the most logical, useful and consistant behaviour. Still, it's all academic anyway. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^10: no chunk is too small
by BrowserUk (Patriarch) on Nov 14, 2005 at 04:44 UTC

but then what about globals? Should they always be aliased? ... And then what about $_ – do we leave it as a strange exception case?

$_ already is a "strange exception", it gets used without being mentioned and has a myriad of magical behaviours associated with it (that I wouldn't want to loose), this would continue the tradition of that variable.

In the case of other globals, I hadn't really thought about them much as I don't make use of them much, but having thought about it, I don't think that there is a case for localisation.

If they already exist in the symbol table, they have been used before, and should not be localised. The programmer has explicitly indicated that they wish to re-use this variable, and any changes should persist. Trust that the programmer knows what they are doing.

If the programmer wants to both re-use an earlier global, and retain it's original value afterward, he has the option to localise it himself--just as he would have to in any other situation.

If the variable does not yet exist in the symbol table, there is no great value in localising it, and you remove the potential for using it's final value subsequent to the loop.

So basically, $_ is special--because it is already special--and for any other variable, the user controls localisation through the keywords my or local, just as he would for any other construct.

Seems to me that would be the most logical, useful and consistant behaviour. Still, it's all academic anyway.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]