Perl - my idiosyncracies

	use Cwd;

	$currWorkDir = &cwd();

  1 #!/bin/sh
  2 #! -*- perl -*-
  3 eval 'exec $PERLLOCATION/bin/perl -x $0 ${1+"$@"} ;'
  4  if 0;
  5 
  6 use Cwd;
  7 $currWorkDir = &Cwd::cwd();

Listing 3.4.1 for code_untested/useCwd.pl
This exposes the fact that it is a subroutine that is not part of the native Perl language. As you get more experienced, you may start thinking "Duh. I know the Perl language and of course the cwd came from the Cwd module. Why do I care how easy it is to trace?" If you hand off your code to someone else, they might not have your level of experience, and something like cwd looks very much like it could be part of the intrinsic language, so they may be tempted to look for it in the functions section of the Perl reference. Or worse, if they are unfamiliar with it, they may think you just have a bare word, or have some call to the UNIX prompt (like backticks) that they are unfamiliar with.

Don't use method functions implicitly. Always declare scope. [back to top]

Perl does have plenty of object oriented functionality as of Perl 5. I don't necessarily think this is a good thing. I take advantage of some of it, but I intentionally avoid a lot of it because I think it makes code harder to read.

Randal Schwartz has a couple articles about how to make hierarchies in an object oriented way in Linux Magazine [SCHW00-4] [SCHW00-5] . He has pretty good coverage of it there. Certainly better than I can do (or want to do). Don't get me wrong. As you read my pages, it should be clear just from the number of citations to his work that I have a lot of respect for Mr. Schwartz.

But here, I just happen to disagree about the use of object oriented stuff. I'm not going to reiterate Schwartz's examples. Read his articles for that. But what I will say is that the Object Oriented methodology with hierarchies allows you to subclass modules off each other. Schwartz's example deals with barnyard animals, but I'll make an example from Maya and have a whole lot of dependency nodes. Of these dependency nodes, we can have operators or DAG(Directed Acyclic Graph) nodes. An example of an operator might be the actual operation of a lattice deformation or inverse kinematics solver. An example of DAG nodes might be groups/transforms or geometry - basically things that you would see in the DAG version of the hypergraph. The following shows the hierarchy of how these nodes are subclassed from each other. This is not a scene(DAG) graph in itself. Each branch just indicates that one node inherits all of the properties of its parent.

	DependencyNode__
	/		\
	Operator	DAGNode_________________________________
	/	\	|		\	\		\
Deformation	Solvers	Geometry	Camera	Light___	Group
/			/	\		/	\
Lattice			NURBS	PolyMesh	Spot	Distant

By the way, you might be laughing at me for the above diagram. See the "How is this?" section of the introduction for an explanation of why I choose to do ascii diagrams most of the time.

Now, the DependencyNode might have a subroutine/method to do something like 'getName' or 'setName' since every node should have a name. All lights might have a color and intensity with get/set methods (which I'm also opposed to, but I'll use for this example).

Now if you import, export, and @ISA things appropriately, you can actually call getName directly from a Point light or a Group node. You may be able to get something like a getIntensity directly from a Distant light, and you may have a spot light that has information about barn doors or something.

But I don't like to do that. You should sense a theme here from me that I like to have things mapped out explicitly. When you're reading the Distant module, and you see getName, you may want to read the code for it and figure out if that's the source of your problems. But if the inheritance is done properly, the getName could be defined in any of Distant, Light, DAGNode, and DependencyNode. The trouble is that as you are tracing through it, you probably don't have the full map above. You generally only know the immediate parent. So you have to go one module at a time. And each stage may or may not define the function. This means that if you don't find the function, you look for the parents and keep searching there. But there's always that little bit of insecurity. If you do find the function, of course you're happy. But if you don't find the function, you may be unsure if the function really wasn't there, or if you just didn't look hard enough.

For this reason, I think it is important to explicitly define all subroutines/methods that a given package uses, even if you could have gotten it for free. You may still need to trace through each one, but you get explicit directions where to look. Also, you can bypass the hierarchy and just jump to the base class. So in this case, in Distant, I would just say:

	package Distant;

	use DependencyNode;

	sub getName {
		return &DependencyNode::getName(@_);
	}

An alternative that I also consider is closer to the object oriented method, but still has it explicit:

	package Distant;
	use Light;

	sub getName {
		return &Light::getName(@_);
	}

	package Light;
	use DAGNode;

	sub getName {
		return &DAGNode::getName(@_);
	}

	package DAGNode;
	use DependencyNode;

	sub getName {
		return &DependencyNode::getName(@_);
	}

Don't use the method call (->). Declare scope. [back to top]

When you are creating an "object" in Perl, you will make some subroutines within the scope of that object/package. For instance, you might have something like:

	package DependencyNode;

	sub getFieldValue {
		my $r_dependencyNode	= shift;
		my $fieldName		= shift;

		if (not exists($r_dependencyNode->{$fieldName})) {
			return;
		}
		# Yes, I really do mean to dereference here.  I found that
		# when doing scene graph stuff, it's good to be able to name
		# your data types, which is done with "bless."  But "bless"
		# requires a pointer, so if my field values are really named
		# (blessed) references, I should deref here for simplicity.

		return ${$r_dependencyNode->{$fieldName}};
	}

	use DependencyNode;
	# pretend I already have a reference to a dependency node...

	# I like this way
	my $fieldValue = &DependencyNode::getFieldValue($r_depNode, 'tx');

Now, I should probably mention that there is a C++ like way of calling this routine that looks like a shorthand. This is equivalent to the above call:

	use DependencyNode;
	# pretend I already have a reference to a dependency node...

	# I don't like this way
	my $fieldValue = $r_depNode->getFieldValue('tx');

1. There is no & character, so there is nothing to clearly indicate that there is a subroutine being called here. At least, it is harder to determine since the -> operator is used for dereferencing array ref elements and hash ref elements.
2. There is no indication of which package this came from. You might use several modules, and the use declarations are usually near the top of your code. Down here, you won't have a clear indication of where to look when your fieldValue isn't right, and you're trying to wade through this code to debug it.
3. -> is the same symbol I use for hash and array element dereferencing. (more on that later.)

That being said, there is one exception to this. I kind of like using this form for a class constructor, but nothing else. This is especially true if the class constructor is named new. Of course there is more to it than this. In this form of calling the method, suppose that you do not already have an object created (like a constructor). We can still call the method with this form by using the name of the package itself:

	use DependencyNode;
	# pretend I already have a reference to a dependency node...

	# I don't like this way
	my $fieldValue = DependencyNode->new();

This still passes in something implicitly as the first argument. But since we didn't invoke it with an object (we used the name of the class itself), it will pass in undef. You can actually take advantage of this by testing for it to decide if you have a copy or a constructor... (I know some of the Perl books discuss this) The alternatives are:

• Pass in an undef explicitly:

  	my $fieldValue = &DependencyNode::new(undef);
  

  I think this just looks dumb.
• Make the new function a regular function, which does not take a reference as the first arg, but really creates something from scratch and not expect any args coming in. This would allow:

  	my $fieldValue = &DependencyNode::new();
  

  I'm actually torn with this one. From what you've read so far, you would expect that I would like this one the best because it show explicitly that this is a subroutine. And I do like it for that reason. But for some reason, something in me does think of constructors as something special.

In short, it is my recommendation to always use the explicitly scoped subroutine call with the &. (but it's forgivable to use -> for constructors....