Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: Defining classes and inheritance using packages within a single .pl file, without creating modules

by MaxKlokan (Monk)
on Nov 29, 2006 at 12:43 UTC ( [id://586676]=note: print w/replies, xml ) Need Help??


in reply to Re: Defining classes and inheritance using packages within a single .pl file, without creating modules
in thread Defining classes and inheritance using packages within a single .pl file, without creating modules

Thank you for the good advice. For this particular case, IMHO the neatest way is to turn the { package ... } blocks into BEGIN { package ... } blocks, and remove the require Class1; line. If I don't remove that line, the block for Class1 is evaluated twice and I get a warning about new() and PrintHello() being redifined. The same warnings are issued if I use base qw(Class1); (without BEGIN). I guess that's because of the same reason (base implies a require). It seems therefore that use base is not the way to go for inline class definition.
  • Comment on Re^2: Defining classes and inheritance using packages within a single .pl file, without creating modules
  • Select or Download Code

Replies are listed 'Best First'.
Re^3: Defining classes and inheritance using packages within a single .pl file, without creating modules
by jbert (Priest) on Nov 29, 2006 at 13:08 UTC
    Well, require is for loading files, which you won't need at all if everything is inline, so removing it is a good idea.

    The reason I would prefer 'use base' (bart's objections notwithstanding) over assigning directly to @ISA is that I don't like having run-time code in modules. (It also seems to work fine in a test here - just remove the @Class2::ISA line and use base qw/Class2/; instead of require Class2;).

    I would say that having a script with a single entry point and execution following function/method invocation, it is easier to see what is going on. Otherwise one must read through the whole file to check for side-effects.

    For example, I commonly have a

    main</c< function: <code> #!/usr/bin/perl use warnings; use strict; exit !main(@ARGV); sub main { ... } sub foo { }
    The benefit of the early exit is that a maintainer can see that there isn't any run-time code lurking down between any later subs (since execution never flows down there). It also means that any lexical variables I use in main aren't accidentally accessible in the functions within the script. (OK, it might make sense to have some file-scope vars, but such things should stand out, not be the default because I'm writing code at the toplevel).

    Yes, for quick scripts etc it is handy to have the scripting behaviour, but by the time we bring OO or helper functions in, we probably have enough complexity that this kind of discipline is beneficial.

    So...when using perl as a programming language (as opposed to a 'scripting' language), I think it is harmful to have code at the top-level - it's effects are too wide-spread (variable scope too large) and the code can be spread over too large an area to see easily.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://586676]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-04-25 21:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found