And I have registered its namespace so it shows up in the module list. This means the Bricklayer::* namespace can now be used to begin build the various components of my evolving frameworks
Posts Tagged ‘API’s’
Bricklayer::Templater is on CPAN
Tuesday, August 14th, 2007Would you like a little Moose with that?
Tuesday, March 20th, 2007I have found a great new tool in CPAN. Moose is an extension of the perl OO system. It implements metaclasses in an intuitive and easy to understand way. Getting started with Moose couldn’t be easier. Make sure you use v0.18 though because the previous version has a few quirks that get in the way. Basically to get started all you need to get started is install Moose from CPAN. I recommend doing so from CPAN because a lot of the distros are behind a little and 0.18 has some fixes that will make your life a great deal easier when using Moose.
Once you’ve installed Moose it’s time to start building your classes. In this tutorial I’m going to highlight the most used (in my opinion) features of Moose.
- has
- after
- subtype
A class is composed of attributes and operations for the most part. Some OO systems further divide these into private and public methods/attributes. For this tutorial though we will just keep it at those two.
The first thing you have to do in your class is use Moose at the top to import the Moose package.
package MyClass;
use Moose;
Now your commited. That use Moose statement has forever altered the way you write this class. Well not really you can turn it off but lets not worry about that right now. Moose does a lot of heavy lifting for you in the background so it’s best to just use the moose feature set to build your class from here on out.
The first thing we need to do is start writing your classes attributes. For this we will need our handy dandy ‘has’ function. ‘has’ will create our attributes for us and automatically do type restriction, create accessor methods, and police reading and writing to them. So what does ‘has’ need? It needs two arguments a scalar and a list of key value pairs with a minimum of at least one but I recommend 2 keys at a minimum. The scalar is the name of the attribute. The list describes the attribute for Moose so it knows how to set it up for you. The first key, and the absolute must, is the ‘isa’ key. This key tells Moose what type to restrict the attribute to. It can be a class name or predefined subtype. You can see a list of Moose’s of already defined subtypes for us Here : http://search.cpan.org/~stevan/Moose/lib/Moose/Util/TypeConstraints.pm#Default_Type_Constraints
You should be able to use those to get started.
The second key Moose needs is the ‘is’ key. This key tells Moose how to police reading and writing to this attribute. A value of ‘rw’ in this key tells Moose this attribute can be read and written. A value of ‘ro’ in the key tells Moose this attribute can only be read and not written to. So lets add a couple of attributes to this class.
has 'Name' => (is => 'rw', isa => 'Str');
has 'Purpose' => (is => 'ro', isa => 'Str');
Now our class instances can have a name and a purpose. We can see that both attributes are strings and that the name is readable and writable while the purpose is only readable. This is actually a fully functional class now. It only works to store things since we don’t have any operations yet but it is fully useable. A few things to keep in mind is that Moose automatically adds Moose::Object as your classes base class. So you do have a few operations: ->new() is a constructor that Moose::Object provides for you. This allows Moose to properly set up your classes accessors and constraints for you. We could use this class now by calling
my $obj = MyClass->new();
We can set our name by calling
$obj->Name('test');
We can retrieve that name by calling
my $name = $obj->Name();
But wait our Purpose attribute is not writable and nothing is stored in it. How on earth do we get something in there? Ahhh, now we come to Mooses little secret: You don’t have to use the methods to access those attributes.
$obj->{Purpose} = 'To Show off Moose'; will work just as well with a few caveats. (You see it really is just an extension of the Perl OO system.)
Moose doesn’t do any policing when you access them this way. This means people who use your class and regard it properly as a black box shouldn’t be doing this. Which brings us to two more really handy keys in our descriptive list we are passing to has: ‘default’ and ‘required’.
Up to now our attributes have not been restricted from being undefined. setting the required => 1 key/value pair in our list takes care of that. If we do that though then we have to define a default value for the attribute or our class will error on compile with Moose telling us that the attribute is undefined. That’s what the default key is for. default => 'To Show off Moose' will set the default value for the attribute to our string. Now our class looks like this:
package MyClass;
use Moose;has 'Name' => (is => 'rw', isa => 'Str');
has 'Purpose' => (is => 'ro', isa => 'Str', default => 'To Show off Moose', required => 1);
When we create a new instance of our class with
my $obj = MyClass->new();
our Purpose attribute will be preset for us and not modifiable (without breaking the rules which you would never do of course).
That’s enough for this post. I’ll be posting next on the benefits of after and subtype when it comes to your attributes and Object Integrity.
Bricklayer Refactored and other news
Tuesday, January 16th, 2007Bricklayer has been heavily refactored for more modularity. You can see the much changed codebase at the new svn repository
Instructions for SVN Checkout can be found here: SourceForge SVN Checkout Current is the trunk branch in the repository tree structure.
Documentation and some examples for the new API will be forthcoming shortly. Including the new DataBase Access API concept I will be introducing. A preview of the proof of concept code is in the Bricklayer/Data libraries directory.
Inception: The Distributed Community API
Wednesday, January 3rd, 2007I have been noodling an idea lately that I think I will begin to implement in Bricklayer. A distributed MySpace/FaceBook of sorts. Think of it as everything you like about a Community Website with none of the Myspace pains. Your profile and content will be yours and under your control. But the network will still be there. It’s distributed because its a network of individual unrelated sites. A Blog, Forum or Discsussion board perhaps. It will allow Disparate sites to network using similar technologies to trackback pings with less spam because a request for friend status with an identity will have to be explicitely allowed.
In Theory with this API joining a community like Myspace would be as simple as requesting Friend Status with a Service Website. Leaving would be as simple as revoking the status with the Service Website. Each way you still keep the identity and Content and moving it from Service to Service or using it in Multiple Services would be simple and easy.
Mod_Perl 2.0 – First in a series
Saturday, April 22nd, 2006I have put up a new page on mod_perl development on the site. I hope it is of use to someone. If it isn’t well at least I still have my own notes :-) You can find it here: Mod_Perl 2.0 – A Real World Guide – part I