With all due respect, if you're going to discuss the minutae, nuances, and other "advanced" Perl stuff, could you please do so on another list?
This is [EMAIL PROTECTED] Publicly arguing this sort of thing on this list, at least to me, makes it more intimidating to post what will be my silly neophyte questions. I say this because of the recent banter that has been going (and this particular thread isn't the only example), I conclude that I will not be told the simplest way to solve my problem and as such, I won't be improving my fundamental Perl skills. I will be told of the most difficult way to do such. I will not be able to implement it, and will likely grow even more frustrated with my problem rather than having received some courteous help in having it solved, and then moving on. I joined this list to read what other beginners are doing, how and what they're learning, and how they're moving on. I joined in the hope that one day I can get to the point where I can help others. Here's the two problems *I* perceive: - Too many complicated and complex answers to what are simple questions. - A tad to much eagerness to interject one's personal "Perl brilliance" to the mailing list. Please remember the best way to impress us n0oBs is to answer our simple questions simply. If you are advanced, and are on this list helping us n0oBs out, please don't be defensive reading this. Please consider that someone, who calls himself a "beginner" is finding this to be a mailing list whose content (much advanced stuff) doesn't match with the title ([EMAIL PROTECTED]). Please also consider that I'm probably not the only n0oB dissatisfied with the list. You could also say "Don't like it? Leave." True. However, I am trying to help fix what I perceive to be a problem, instead of leaving. If nothing changes, I will. Thank you for your time and consideration, -Zander At 11:37 AM 10/2/2001 -0800, Michael Fowler wrote: >> One of the problems with prototypes is that they are not prototypes, at >> least not in the sense that other programming languages use them. > >I am aware of this "problem", which, personally, I don't consider a problem, >because it is documented fairly clearly. > > >> Instead, they allow us, amongt other things, to force function arguments >> into a particular context. In your example, the first argument *doesn't* >> have to have a scalar value. > >I wasn't using the prototype to check the parameters, I was using it to ease >the use of the function. Without the prototype the function would have to >be called thusly: > > append_and_print(\$stuff_to_print, "hi", " there\n"); > >The prototype serves simply to enreference $stuff_to_print, so it doesn't >have to be enreferenced by the programmer using it. It was meant for >nothing more. With both solutions there is the possibility of passing a >reference to another type of data. The only solution, if this is considered >a serious enough problem, is to check the parameters more thoroughly. The >code snippet I gave was but an example of one solution, it was not meant to >be used without examination by the person using it. > > >Michael >-- >Administrator www.shoebox.net >Programmer, System Administrator www.gallanttech.com >-- > >-- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
