Re^6: Indirect variable name

Thanks, but

> That's OK because eval has the "evil, don't use" stigma on it.

Well which is perfectly the same with symderef, that's why it's not strict!

When the code breaks, the compiler can't be blamed. No optimization would be hindered by that.

Cheers Rolf

Comment on Re^6: Indirect variable name

Replies are listed 'Best First'.
Re^7: Indirect variable name by moritz (Cardinal) on Nov 21, 2008 at 10:35 UTC
Well which is perfectly the same with symderef, that's why it's not strict! symbolic derefs are not syntactically distinguished from "normal" derefs, so I do see a difference to the case with eval.	[reply]
Re^8: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 10:58 UTC
Well... now we are entering the domain of taste. My arguments in short: symderefs are actually considered nonstrict and therefore evil they can't ever hinder optimization if they fail, nobody blames the compiler orthogonality between package vars and lexical should not be broken, even on the dark side of the force. they have a big advantage to eval, since there is no security risk of code infiltration. Cheers Rolf UPDATE: I think your arguments are valid to proof why real refs are much better than the evil symbolic ones. There is no doubt ... but sometimes you can't help but getting dirty to solve a problem. That's why perl has tools like eval helping to dig in the dirt.	[reply]
Re^9: Indirect variable name by LanX (Saint) on Nov 21, 2008 at 11:20 UTC
UPDATE2: I think there is indeed a need to syntactically distinguish the two forms of dereferences, maybe by obliging the programmer to enclose symbols in double quotes: `${"$sym"}` [download] But this should be done equally for package and lexical vars, IMHO no need to break orthogonality. UPDATE3: But anyway you're bringing a syntax-argument into a semantic-discussion.	[reply] [d/l]