Re: Programming style: using Classes or inline

[David <dbree duo-county com>]

On Thu, Mar 16, 2006 at 08:16:12PM -0500, muppet wrote:

> On Mar 16, 2006, at 2:30 PM, David wrote:

> > What came as a surprise to me was that I couldn't have global  
> > variables.
> > Again, I'm quite new to Perl and some of the rules are a bit  
> > unexpected.

> "strict" doesn't prevent you from having globals.  What it does is  
> require that you use either fully-qualified package names or  
> lexically-scoped variables.

Yes, I learned that in the docs.  What I should have said was that you
couldn't use them "conveniently", at least, IMO.  What I was trying to
do was something I guess not appropriate in Perl.  What I had attempted
was to keep it modular - I had three component files - but none were
defined as packages.  I'd attempted to keep the related portions of the
code in separate files, and then just include them into the main program.
In the fashion as you would in C.  In C, if you "include " a file, the
code and all variables in all these files are treated as if it were one
single file.  I found that this didn't work this way in Perl.

[ .. description of what "strict" does .. ]

> All of this is documented in perl's online manual.

Yes, I've studied them and the concepts are _slowly_ creeping in.

> And, actually, i hesitate to mention all of this because globals  
> really are not good things to use.  They limit the ability of your  
> packages to scale to multiple instances and tend to cause spaghetti- 
> like interdependencies.

> Avoid globals.

Yes, I think I depend too heavily on globals.  I tend to try to access
global variables directly from within a subroutine when I should be
passing references or returning a reference or value.  I need to get out
of that habit, I think.

> Learn to create classes.  Perl makes it very easy.  Once you  
> understand classes, there's a slight change in initialization style  
> to start creating subclasses of Glib::Objects so that you can create  
> your own widgets.  Here's a write-up that contrasts normal perl  
> classes and Glib::Object-style classes.
> http://gtk2-perl.sourceforge.net/doc/subclassing_widgets_in_perl.html


> > > You can do either.  It's perfectly reasonable to declare multiple
> > > classes in a single file.
> >
> > With the above question, I meant keeping the classes in the same  
> > file as
> > the mainline code.  I know that in your tutorial, you stated that  
> > while
> > developing your project, you kept separate files for the classes  
> > and the
> > mailine code, but that sometimes it was advantageous, especially after
> > development was complete, to merge them all into one file.

> Whether to use one file or a bunch of files really depends on how the  
> code will be used.  When i have something that i want to deploy  
> easily, i like to have all the classes in a single file so that the  
> application consists of just one file.  If i'm reusing code, i'll  
> create installable modules.

In my particular case, I don't think any packages I'd create would be
very generic to where they could be reused.  The main reason I'd want to
split it up (wanted to split it up to begin with, actually), would be
for manageability.

> An important thing to remember when placing a bunch of classes in one  
> file is that execution order still matters.  When using "require" or  
> "use", your whole pm file will be parsed and then executed.  If you  
> have all the classes in one file, all of the code will be parsed, but  
> whether it will be executed depends on the position in the file.

Not trying to be a grammar police, but, for my understanding, do you
mean "will have been executed"?  It appears that in the following code
all executes, but the question is whether it has executed by the time
(in this case) main:: does its thing.

I had not even thought about executable code outside of a subroutin in a
package.  Since you bring up this point, wouldn't it be wise to avoid,
if at all possible, having any executable code outside a subroutine in a
package.  Again, I'm really new at this, but I'd think that it would be
best to do all initialization that you can from within your constructor.
Of course, I realize that this program you supplied was for
demonstration purposes.


> To  wit:
[ .. sample program .. ]

> Figuring out why is left as an exercise for you.  :-)

Yeah, think I followed it all..  Just tried something.  I cut-and-pasted
your program putting the three packages into separate files, and
inserting corresponding "use " statements at the appropriate places and
the program ran without error or warning.  I had expected the same
results as the single-file.pl.  Did I see somewhere that "use"
statements are all processed at compile time, regardless of position?


> So, you then get to decide whether you want your main driver logic at  
> the top or at the bottom of the file.

Well, after this thread, I may do some Packaging :)  Actually, I have
gotten in the habit of trying to put most of my subroutines at the begin
of the file.  This in an attempt to avoid having to prototype my C
variables and subroutines.. But I think prototyping is the equivalent of
"strict" in perl, and it's a Bad Thing(tm) to avoid it.

> > I do realize that this
> > question _was_ a bit OT for this list.

> If everything was on-topic life would be quite boring.  But i do try  
> to spare y'all the tales of what crazy things my kids have done each  
> day.  =)

I appreciate that.  I know that on some lists, there are people who seem
to look for every opportunity to jump on people for OT posts, but I'm
thinking that there may be others who might be helped by this thread.