Nuther one of those Perl questions.

Post #146,444 by folkert 3/16/04 9:36:16 AM Reply	Nuther one of those Perl questions. Re-reading on arrays (arrays were fuzzy), I noticed this particular quote: Note that the inserted array elements are at the same level as the rest of the literal: a list cannot contain another list as an element. Although a list reference is permitted as a list element, it's not really a list as a list element. Still, it works out to nearly the same thing, allowing for multidimensional arrays. This is the part that made it fuzzy for me. Why does Perl allow such a change in the way it handles things. Yes, I know it is the Perl way, but the question I have is: How does Perl guarantee data to be handled consistently? (disregarding programmatic errors in this regard) I know it just DOES... but that isn't a good answer. Yes this is a basic question, but my concerns pivot on this one question and then can be answered myself by reading and research. Once I know this answer, I can continue on my way. I need a bit more explanation which I can't seem to find any good reading on it. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* I did a 10K wheelchair race once. The NTMFAC who pushed me still has the whip-marks.
Post #146,454 by ben_tilly 3/16/04 11:10:15 AM Reply	This is Perl. What are guarantees? :-P As Larry Wall says, Give people enough rope to hang themselves, and they'll usually figure out how not to, after several successes. Seriously, that is the problem with dynamic typing. You have a variable. It might have any of several different kinds of data. Try to do something with it, if you ask to do something that you can't, there will be a problem. Most of the time people don't make this mistake. This is the attitude taken by languages like Perl, Python, Smalltalk and Lisp. Trying to guarantee that this won't happen requires statically stating the type of everything, and statically verifying that nothing will try to be accessed in a way that it shouldn't be. Many mainstream languages have type systems like this (eg C, C++, and Java). The problem with that is that managing the constraints that you need turns out to be a considerable amount of work. Particularly when you decide to change a data structure. Or when the way that you have to manage the constraints conflicts with the design that you are working with. In general Perl's attitude is to give the programmer a lot of freedom. It will catch some things. It catches more if you use [link\|http://www.perlmonks.org/index.pl?node=strict.pm\|strict] and turn warnings on. But fundamentally it is up to the programmer to catch your own errors (for instance with good test suites). Incidentally for understanding references in Perl I recommend [link\|http://www.perlmonks.org/index.pl?node_id=69927\|References Quick Reference]. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #146,600 by broomberg 3/16/04 9:15:55 PM Reply	It is a list A list of what, you may ask? A list of stuff! Stuff can be scalars, or refs to other stuff, including hashes or lists. You want to ask what it is? Use the 'ref' function. perldoc -f ref \n ref EXPR\n ref Returns a true value if EXPR is a reference, false otherwise.\n If EXPR is not specified, $_ will be used. The value returned\n depends on the type of thing the reference is a reference to.\n Builtin types include:\n\n SCALAR\n ARRAY\n HASH\n CODE\n REF\n GLOB\n LVALUE\n\n If the referenced object has been blessed into a package, then\n that package name is returned instead. You can think of "ref"\n as a "typeof" operator.\n\n if (ref($r) eq "HASH") {\n print "r is a reference to a hash.\\n";\n }\n unless (ref($r)) {\n print "r is not a reference at all.\\n";\n }\n if (UNIVERSAL::isa($r, "HASH")) { # for subclassing\n print "r is a reference to something that isa hash.\\n";\n }\n\n See also perlref.\n Of couse, if you really want the language to "handle" it for you, you will deal only in objects and use accessors to so "the right thing", rather than have a bunch of if/then/else base on the return of a ref. Or to start off with, you could just put the right stuff in the list in the 1st place. Enjoy.

Welcome to IWETHEY!