Free base class software for linux

C++ base is a base class suite contains several powerful c++ base classes for basic encapsulation of low level operating system calls and basic library functions.

Further packages you may access from this page require the installation of this base package

dtRdr::Traits::Class is a Perl module with shared OO stuff.

Methods to Break Things

NOT_IMPLEMENTED

Imported into base class. Gives a nicer message than the standard "Cant locate method...", indicating that you did not typo the method name, but instead forgot to override it.

sub virtual_method {my $self = shift; $self->NOT_IMPLEMENTED(@_);}

Is the shorter, less readable version worthwhile?

sub virtual_method { $_[0]->NOT_IMPLEMENTED(@_[1..$#_]);}

This should be safe for subclasses to override and/or call as ->SUPER::. This gives you something like an AUTOLOAD (though you would have to get (caller(1))[3] yourself) without having to also do can(), but thats untested...

WARN_NOT_IMPLEMENTED

Same as NOT_IMPLEMENTED(), but just a warning. Returns undef.

$self->WARN_NOT_IMPLEMENTED;

Class Hopping

claim

Assumes a hash-based object. Creates a copy (with only one level of dereference) and blesses it into Package.

$object = Package->claim($object);

KinoSearch::Util::Class is a Perl class building utility.
PRIVATE CLASS
This is a private class and the interface may change radically and without warning. Do not use it on its own.
SYNOPSIS
package KinoSearch::SomePackage::SomeClass;
use base qw( KinoSearch::Util::Class );
BEGIN {
__PACKAGE__->init_instance_vars(
# constructor params / members
foo => undef,
bar => {},
# members
baz => {},
);
}
KinoSearch::Util::Class is a class-building utility a la Class::Accessor, Class::Meta, etc. It provides four main services:
- A mechanism for inheriting instance variable declarations.
- A constructor with basic argument checking.
- Manufacturing of get_xxxx and set_xxxx methods.
- Convenience methods which help in defining abstract classes.

Class::Spiffy is a Spiffy Framework with No Source Filtering.

SYNOPSIS

package Keen;
use strict;
use warnings;
use Class::Spiffy -base;
field mirth;
const mood => :-);

sub happy {
my $self = shift;
if ($self->mood eq :-() {
$self->mirth(-1);
print "Cheer up!";
}
super;
}

1;

"Class::Spiffy" is a framework and methodology for doing object oriented (OO) programming in Perl. Class::Spiffy combines the best parts of Exporter.pm, base.pm, mixin.pm and SUPER.pm into one magic foundation class. It attempts to fix all the nits and warts of traditional Perl OO, in a clean, straightforward and (perhaps someday) standard way.

Class::Spiffy borrows ideas from other OO languages like Python, Ruby, Java and Perl 6. It also adds a few tricks of its own.

If you take a look on CPAN, there are a ton of OO related modules. When starting a new project, you need to pick the set of modules that makes most sense, and then you need to use those modules in each of your classes. Class::Spiffy, on the other hand, has everything youll probably need in one module, and you only need to use it once in one of your classes. If you make Class::Spiffy the base class of the basest class in your project, Class::Spiffy will automatically pass all of its magic to all of your subclasses. You may eventually forget that youre even using it!

The most striking difference between Class::Spiffy and other Perl object oriented base classes, is that it has the ability to export things. If you create a subclass of Class::Spiffy, all the things that Class::Spiffy exports will automatically be exported by your subclass, in addition to any more things that you want to export. And if someone creates a subclass of your subclass, all of those things will be exported automatically, and so on. Think of it as "Inherited Exportation", and it uses the familiar Exporter.pm specification syntax.
To use Class::Spiffy or any subclass of Class::Spiffy as a base class of your class, you specify the -base argument to the use command.

use MySpiffyBaseModule -base;

You can also use the traditional use base MySpiffyBaseModule; syntax and everything will work exactly the same. The only caveat is that Class::Spiffy must already be loaded. Thats because Class::Spiffy rewires base.pm on the fly to do all the Spiffy magics.

Class::Spiffy has support for Ruby-like mixins with Perl6-like roles. Just like base you can use either of the following invocations:

use mixin MySpiffyBaseModule;
use MySpiffyBaseModule -mixin;

The second version will only work if the class being mixed in is a subclass of Class::Spiffy. The first version will work in all cases, as long as Class::Spiffy has already been loaded.

To limit the methods that get mixed in, use roles. (Hint: they work just like an Exporter list):

use MySpiffyBaseModule -mixin => qw(:basics x y !foo);

A useful feature of Class::Spiffy is that it exports two functions: field and const that can be used to declare the attributes of your class, and automatically generate accessor methods for them. The only difference between the two functions is that const attributes can not be modified; thus the accessor is much faster.

One interesting aspect of OO programming is when a method calls the same method from a parent class. This is generally known as calling a super method. Perls facility for doing this is butt ugly:

sub cleanup {
my $self = shift;
$self->scrub;
$self->SUPER::cleanup(@_);
}

Class::Spiffy makes it, er, super easy to call super methods. You just use the super function. You dont need to pass it any arguments because it automatically passes them on for you. Heres the same function with Class::Spiffy:

sub cleanup {
my $self = shift;
$self->scrub;
super;
}

Class::Spiffy has a special method for parsing arguments called parse_arguments, that it also uses for parsing its own arguments. You declare which arguments are boolean (singletons) and which ones are paired, with two special methods called boolean_arguments and paired_arguments. Parse arguments pulls out the booleans and pairs and returns them in an anonymous hash, followed by a list of the unmatched arguments.

Finally, Class::Spiffy can export a few debugging functions WWW, XXX, YYY and ZZZ. Each of them produces a YAML dump of its arguments. WWW warns the output, XXX dies with the output, YYY prints the output, and ZZZ confesses the output. If YAML doesnt suit your needs, you can switch all the dumps to Data::Dumper format with the - dumper option.

XML::SAX::Base is a base Perl class with SAX Drivers and Filters.

SYNOPSIS

package MyFilter;
use XML::SAX::Base;
@ISA = (XML::SAX::Base);

This module has a very simple task - to be a base class for PerlSAX drivers and filters. Its default behaviour is to pass the input directly to the output unchanged. It can be useful to use this module as a base class so you dont have to, for example, implement the characters() callback.

The main advantages that it provides are easy dispatching of events the right way (ie it takes care for you of checking that the handler has implemented that method, or has defined an AUTOLOAD), and the guarantee that filters will pass along events that they arent implementing to handlers downstream that might nevertheless be interested in them.

WRITING SAX DRIVERS AND FILTERS

Writing SAX Filters is tremendously easy: all you need to do is inherit from this module, and define the events you want to handle. A more detailed explanation can be found at http://www.xml.com/pub/a/2001/10/10/sax-filters.html.
Writing Drivers is equally simple. The one thing you need to pay attention to is NOT to call events yourself (this applies to Filters as well). For instance:
package MyFilter;
use base qw(XML::SAX::Base);

sub start_element {
my $self = shift;
my $data = shift;
# do something
$self->{Handler}->start_element($data); # BAD
}

The above example works well as precisely that: an example. But it has several faults: 1) it doesnt test to see whether the handler defines start_element. Perhaps it doesnt want to see that event, in which case you shouldnt throw it (otherwise itll die). 2) it doesnt check ContentHandler and then Handler (ie it doesnt look to see that the user hasnt requested events on a specific handler, and if not on the default one), 3) if it did check all that, not only would the code be cumbersome (see this modules source to get an idea) but it would also probably have to check for a DocumentHandler (in case this were SAX1) and for AUTOLOADs potentially defined in all these packages. As you can tell, that would be fairly painful. Instead of going through that, simply remember to use code similar to the following instead:

package MyFilter;
use base qw(XML::SAX::Base);

sub start_element {
my $self = shift;
my $data = shift;
# do something to filter
$self->SUPER::start_element($data); # GOOD (and easy) !
}

This way, once youve done your job you hand the ball back to XML::SAX::Base and it takes care of all those problems for you!

Note that the above example doesnt apply to filters only, drivers will benefit from the exact same feature.

Class::Adapter is a Perl implementation of the "Adapter" Design Pattern.

The Class::Adapter class is intended as an abstract base class for creating any sort of class or object that follows the Adapter pattern.

What is an Adapter?

The term Adapter refers to a "Design Pattern" of the same name, from the famous "Gang of Four" book "Design Patterns". Although their original implementation was designed for Java and similar single-inheritance strictly-typed langauge, the situation for which it applies is still valid.

An Adapter in this Perl sense of the term is when a class is created to achieve by composition (objects containing other object) something that cant be achieved by inheritance (sub-classing).

This is similar to the Decorator pattern, but is intended to be applied on a class-by-class basis, as opposed to being able to be applied one object at a time, as is the case with the Decorator pattern.

The Class::Adapter object holds a parent object that it "wraps", and when a method is called on the Class::Adapter, it manually calls the same (or different) method with the same (or different) parameters on the parent object contained within it.

Instead of these custom methods being hooked in on an object-by-object basis, they are defined at the class level.

Basically, a Class::Adapter is one of your fall-back positions when Perls inheritance model fails you, or is no longer good enough, and you need to do something twisty in order to make several APIs play nicely with each other.

What can I do with the actual Class::Adapter class

Well... nothing really. It exist to provide some extremely low level fundamental methods, and to provide a common base for inheritance of Adapter classes.
The base Class::Adapter class doesnt even implement a way to push method calls through to the underlying object, since the way in which that happens is the bit that changes from case to case.

To actually DO something, you probably want to go take a look at Class::Adapter::Builder, which makes the creation of Adapter classes relatively quick and easy.

Class::Cloneable is a base class for Cloneable objects.

SYNOPSIS

package MyObject;
our @ISA = (Class::Cloneable);

# calling clone on an instance of MyObject
# will give you full deep-cloning functionality

This module provides a flexible base class for building objects with cloning capabilities. This module does its best to respect the encapsulation of all other objects, including subclasses of itself. This is intended to be a stricter and more OO-ish option than the more general purpose Clone and Clone::PP modules.