Re: sub BEGIN

is this something like anonymous sub but gets applied before code is compiled?

It is a (specially) named block, called by Perl before processing the rest of the module. See perlmod for details.

But I don't understand how to access sub BEGIN

What do you mean by "access sub BEGIN"?

If you mean how do you call it? You don't.

If you mean how do you use the package? I think the answer is that in the normal way of things you wouldn't. It appears to be a sub package of a larger suite that is intended to be called internally only. The one subroutine (method?!) it contains--that rather nastily, remotely insinuates itself in to a complete different package space--is a rather clumsy replication of exists.

Basically, once the module is loaded, the hash has been constructed. But, the BEGIN block is probably unnecessary. The module would work just the same without it.

And whenever anyone calls SOAP::Deserializer::typecast() passing ($self, $value, $name, $attrs, $children, $type), if $type exists in the hash, it returns $value, otherwise undef.

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

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

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

RIP an inspiration; A true Folk's Guy

Comment on Re: sub BEGIN Select or Download Code

Replies are listed 'Best First'.
Re^2: sub BEGIN by Anonymous Monk on May 10, 2010 at 16:03 UTC
so basically BEGIN and END is just bad styling.(or at least unnecessary). thank you so much guys!!	[reply]
Re^3: sub BEGIN by BrowserUk (Patriarch) on May 10, 2010 at 22:06 UTC
From my perspective, BEGIN blocks are a form of code smell. In this case, a variation on 'Inappropriate intimacy'. Several possibilities for a fix stand out: Making that hash a constant. Using inheritance rather than poking stuff into remote namespaces. If the use of the BEGIN block is required to make the code work as need, then a better solution would be to move the require. If the BEGIN block is a precautionary prophylactic, you might as well use cling film, because it is full of holes. What if the required module calls the overridden method within its own BEGIN block? Once you start the arms race of every programmer putting the bits of their code they think are of paramount importance in BEGIN blocks, soon everybody will be putting everything in BEGIN blocks, and you're back to square one with no solution. But the most interesting question here I think would be: why are you poking around in there anyway? That is, what led you in there? What are you trying to do that you're failing to achieve? What error situation are you trying to avoid? What is it that you're really asking for help with? If this is just an academic exercise of trying to improve your Perl by reading and understanding the internals of some examples, on the basis of what you've posted in isolation, you'd better pick some better examples. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]
Re^3: sub BEGIN by ikegami (Patriarch) on May 10, 2010 at 17:14 UTC
Almost certainly unnecessary. It depends on when `$urnMap` is used. If that's your whole file, then it is indeed unnecessary. I wouldn't say bad style.	[reply] [d/l]
Re^4: sub BEGIN by Anonymous Monk on May 10, 2010 at 17:23 UTC
just one more question if I may where is SOAP::Deserializer::typecast being defined? I searched on cpan and was not able to find them.	[reply]
Re^5: sub BEGIN by ikegami (Patriarch) on May 10, 2010 at 17:48 UTC
Re^6: sub BEGIN (order) by tye (Sage) on May 10, 2010 at 20:24 UTC
Some notes below your chosen depth have not been shown here
Re^3: sub BEGIN (wise) by tye (Sage) on May 10, 2010 at 20:17 UTC
It seems likely (functionally) unnecessary in this specific case. But some prefer not to analyze each specific case to try to convince themselves that it is actually foolproofly unnecessary and so just include BEGIN for such initializations as a "best practice". (The END block is likely just a visual reminder for "this is where you put clean-up code" and "I didn't forget the clean-up code, we just don't need any for this module at this time" -- as such, I might comment it out for the sake of clarity.) The flow of the above code w/o the BEGIN goes like: `Compile: package iControlTypeCast; Compile: require SOAP::Lite; # nothing happens Compile: my $urnMap; # declares the variable Compile: $urnMap = ...; # nothing happens Compile: sub SOAP::Deserializer::typecast # makes it possible to cal +l this Run: require SOAP::Lite; # compiles and then runs S +OAP/Lite.pm # During the loading of SOAP::Lite, a whole ton # of stuff can happen and is likely to happen Run: my $urnMap = ...; # the variable is /finally +/ initialized` [download] In this particular case, it seems unlikely that anything that happens during the loading of SOAP::Lite would lead to SOAP::Deserializer::typecast() being called. But I'd actually have to study the SOAP modules quite a bit more before I was fully convinced of that. It would certainly be bad style for that order of execution, IMHO. But I see no reason to just rely on such an order of execution never arising. So it seems wise to avoid the window of time where SOAP::Deserializer::typecast() can be called while $urnMap is still not initialized. The BEGIN block avoids exactly that. So, I consider it good style/practice. - tye	[reply] [d/l]
Re^4: sub BEGIN (wise) by Anonymous Monk on May 10, 2010 at 20:48 UTC
hey thanks for the explanation. It looks like i have to study soap::lite more(as well as i can understand that is) All in all, from my understanding reading this module, only purpose of it is that to make sure key(e.g, {urn:iControl}System.ConfigSync.SaveMode) that user is inputting is in the list of urnMap before allowing it to use.. Am I correct on this?	[reply]