Site Sponsors:
C++ - The Novel 
I was reminded the other day that not everyone has decades of C/C++ experience behind them.

For the benefit of those who tend to think that mastering an API (let alone OO!) is beyond them, I have a book to go along with my C/C++ Project.

Without further elaboration (you know who you are!) here is The Joy of C++.

[ view entry ] ( 2328 views )   |  permalink  |  related link
Faster Field Support using Enumeration & Arrays 
The humble 'enum' has come a long way. --Indeed, when I first taught the 'enumeration concept' (i.e why use numbers, when you can use names) a few decades ago, I was using C/C++.

Today both .Net and Java have their humble 'enum' equivalent:

enum codes {
one, two, three

--Easy enough to understand.

Object Members

What is interesting to note however is that, unlike C/C++, any 'enum' in either Java or .Net is not merely about mnemonic substitution. Rather, the enum keyword in both technologies creates a fully-qualified Object:

public String get(codes which) {
return vals.get(which.ordinal());

public String set(codes which, String sWho) {
return vals.set(which.ordinal(), sWho);

Like any Object, any instance of 'enum' in .Net and Java has member functions. Amongst other things, by default the members of an 'enum' allow us to translate between a set of zero-based integers, as well as any enumerated token.

Enumerated Rarefactions

Since by default the enum uses a zero-based ordinal (read i-n-t-e-g-e-r ;), the use of any enumerated set of tokens readily transfers over to a zero-based array usage. The piratical :) application of this default numbering series is that any set of arbitrary enumerators can be used to quickly create a class, with just as many value-storage opportunities:

class ClientSettings {
ArrayList<String> vals = new ArrayList<String>();

public enum codes {
// We could also use enums like name, address, phone (etc)
one, two, three

public ClientSettings() {
codes[] set = codes.values();
for (codes code : set) {

public String get(codes which) {
return vals.get(which.ordinal());

public String set(codes which, String sWho) {
return vals.set(which.ordinal(), sWho);

public static void main(String[] args) {
ClientSettings ref = new ClientSettings();
if (ref.get(codes.two).equals( == false) {
System.out.println("Error - Conceptual failure #1.");
String sTest = "Enumerated arrays are so easy, they are scary.";
ref.set(codes.two, sTest);
if (ref.get(codes.two).equals(sTest) == false) {
System.out.println("Error - Conceptual failure #2.");

In short, no mater if we have 2 or 200 values. -Whenever we want to quickly create a class to support the storing of one or all of them, all we have to do is to update a single 'enum'. --The rest is as good (or evil ;) as is the enumerated set of tokens we choose to represent our data_stored therein.



(p.s: The above is a Java demonstration. The proof of concept is in main().)

[ view entry ] ( 3384 views )   |  permalink
Quick PHP Persistence  

Easy Enough?

One of the reasons why SQL databases are such a performance bottleneck in modern enterprise systems is that people store absolutely everything in them. Indeed, over the decades I encounter more and more blank stares when I respond to queries by telling friends that - even given the millions of search-able recipes, quotations, events, and graphics shared throughout my popular sites, that we have never felt the need to use SQL. -Binary searches, text indexing, and data storage routines are easy enough to write?

Requirement Triage

Indeed, it is due to the many fallacies one often discovers in the "one technology fits all" mantra that savvy technical folks refuse to do things like log HTML hits to an enterprise resource. -Without clear business justification, when it comes time to store billions of simple n-keyed records a day - into a bottleneck-sensitive database - perhaps folks are doing so because they do not realize that there is an easy alternative? (After all, to make any database work, someone had to write things like indexing and binary searches (and a whole lot more - wink - wink), at some point?)

When it comes to demonstrating customized, responsive solutions to domain-specific challenges, such was the case when I was recently showing off a performance-boosting notion designed to use PHP CRUD. When discussing how we can quickly & easily save data to an indexed file, the "I'm from Missouri" (i.e. 'show me') -urge came up with a succinct demonstration:

class user_info {

var $data = array();

function __construct() {
$this->data[0] = -1;
$this->data[1] = '';
$this->data[2] = '';
$this->data[3] = '';
$this->data[4] = false;


public function getPayload() {
return $this->data[4];

public function setPayload($str) {
$this->data[4] = $str;

public function getAlias() {
return $this->data[3];

public function setAlias($str) {
$this->data[3] = $str;

public function getPassword() {
return $this->data[2];

public function setPassword($str) {
$this->data[2] = $str;

public function getEmailt() {
return $this->data[1];

public function setEmail($email) {
$this->data[1] = $email;

public function getAccount() {
return $this->data[0];

public function setAccount($ss) {
$this->data[0] = $ss;

public function isNull() {
return ($this->data[0] === -1);

public function toString() {
$result = implode('|', $this->data);
return $result;

public function fromString($str) {
$this->data = explode('|', $str);
return true; // gigo


Simple String

The crux of the above example is a demonstration of how we can quickly read and write class information to a string. No XML. No JSON. Just a nice, efficient, cross platform representation of an easily extensible data format.

Exploding Arrays

By using arrays, encapsulation, and PHP's implode() and explode() feature, a classy lifestyle can get instances stored relatively quickly. -Best of all, when using an encapsulated array(), we are free to rapidly extend the number of fields / columns we keep without change requests, hours of meetings, or ever contacting your friendly neighborhood DBA ;-)

After storing data, comes the searching. While I consider my indexing technologies to be intellectual property, at the end of the day such things are easy enough to write for oneself.

Class Egocentricity

For what it is worth, working within the confines of typeless languages (such as PHP) can also bring a few conveniences to mind. Indeed, while an accomplished object-oriented designer might be interested in designing an instance out of a controller, for maintenance reasons some odd 'typeless-convenience' patterns may surface:

class user_info_crud extends user_info {
var $info;
var $db;

public function __construct() {
$this->info = new IndexedDataInfo();
$this->info->data_min = 1024;
$df = home('front_end_data/user_info.crud');
$this->db = new IndexedData();

public function create() {
$res = $this->db->append($this->info, '');
if ($res === false)
return false;
return $this->update();

public function read($ss) {
$str = $this->db->read($this->info, $ss);
if ($str === false)
return false;
return $this->fromString($str);

public function update() {
if ($this->isNull() == false) {
$str = $this->toString();
return $this->db->update($this->info, $this->getAccount(), $str);
return false;

public function delete() {
if ($this->isNull() == false)
return $this->db->update($this->info, $this->getAccount(), '');
return true;

public function tally() {
return $this->db->tally($this->info);

public function destroyDatabase() {
return $this->info->delete();

The above demonstrates how we might use PHP CRUD to maintain a list of user accounts. By using the logical, zero-based record-offset as the record identifier / account number, users have that identifier, as well as the email address (etc.) to manage their front-end web-access account. --In addition to leveraging file-level POSIX securities (usr/group, etc), the security conscious can even use PHP CRUD's base64 encoding as another line of defense.

Proper Packaging

But the real point is this: In as much as PHP is - for the moment - extremely typeless - rather than having your CRUD operations return - and manage - objects - it is often easier in PHP to use the above design pattern. While it always seems laughably obscene to derive a controller from an entity (such as we do above), doing so can often make OIOO (One-In One-Out - pronounced "ohio") operations far, far easier to deal with.

Indeed, in the final analysis, the ability to wrap a controller around an object is often what templates (also referred to as parametrized types) are all about.

Better still, if push comes to shove (as it often may), we can always retrieve or otherwise manage an array of user_info.



[ view entry ] ( 2436 views )   |  permalink  |  related link

<<First <Back | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Next> Last>>