From: ahoward Date: 2003-01-30T07:19:55+09:00 Subject: Re: Local variables & blocks On Wed, 29 Jan 2003, Martin DeMello wrote: > Yes, but my point was, when doing this, I usually have either object > being an instance variable, or object being assigned shortly before I do > the call, or object being one of the args to the current method. 'shortly' is subjective though : require 'tons_of_stuff' object = 42 is this 'shortly'. alot of namespace polluting could have happened during the require... > In the first case, you wouldn't use @object as a block temp variable > anyway. why not? > In the second, you'd have to call object = function_that_sets_object > within your current method in order to have any expectation of it having > a value. If you call it after the block, you're fine. If you call it > before the block, you'll be warned about shadowing. > > In the third case, you'll be warned about shadowing. well. i guess we disagree on this one. one of the things i _hate_ about perl is it's scoping rules, especially how easy it eas to put something into the global namespace. i like languages which make it difficult to pollute global namespaces, take pascal vs C. i personally think polluting one's parent's namespace should require effort (not alot) because it is not generally wanted, if it _were_ every C library in existence would _not_ have been written like : static int function (x) int x; { ... } but i'm with you on not wanting to do this x = nil loop { x = ... } thing all the time. however, that really seems like the ONLY time one want to 'export' variables isn't it? -a -- ==================================== | Ara Howard | NOAA Forecast Systems Laboratory | Information and Technology Services | Data Systems Group | R/FST 325 Broadway | Boulder, CO 80305-3328 | Email: ahoward@fsl.noaa.gov | Phone: 303-497-7238 | Fax: 303-497-7259 ====================================