sycobuny

Sequel.migration do
    change do
        create_table :guests
            primary_key :id

            String :first_name, :null => false
            String :last_name,  :null => false

            String :street
            String :city

sycobuny

<?php

    class _QueryTable extends _QueryTableExpression {
        private $identifier;

        function __construct($identifier, $alias = null) {
            $this->identifier = _QueryIdentifier::create($identifier, $alias);
        }

        public static function create($identifier, $alias = null) {

sycobuny

_QueryExpression (interface)
 |
 | - _QueryFunction (interface)
 |
 | - _QueryTableExpression (interface)
 |
 | - _QueryValueExpression (interface)


_QueryAliasableExpression (abstract, implements _QueryExpression)

sycobuny

<?php

    foreach (array('literal', 'identifier', 'qualified_identifier',
                   'join_condition', 'conditional', 'grouping', 'limiting',
                   'ordering') as $__) {
        $__ = join(DIRECTORY_SEPARATOR, array(dirname(__FILE__), "$__.php"));
        include_once($__);
    }
    unset($__);

sycobuny

"""""""""""""""""""""
" SYNTAX HIGHLIGHTING
"""""""""""""""""""""
set t_Co=256
syntax enable
highlight comment ctermbg=blue
highlight comment ctermfg=gray
highlight constant ctermfg=red
highlight type ctermfg=green
highlight preproc ctermfg=blue

sycobuny

So, there's a single distinctly good reason to use modules that have already been written: they're already written, which means you don't have to write them. That saves time off your schedule from blank file to completed product. However, in the Perl world at least, it feels that there's reason to assume this may not always be the best course of action.

I'm actively considering writing (and somewhat [working on][plmodel]) a database for library along the lines of [Sequel][sequel]. I've looked at [RoseDB][rosedb] and [DBIx][dbix] and neither really seemed to match the It Just Works simplicity of Sequel for basic ad-hoc querying/runtime object construction, nor the flexibility and power of building more complex queries without advanced SQL knowledge. Your mileage will vary on whether you feel building complex queries entirely in Perl should be necessary, some will say you should just write raw SQL if it's that necessary, and that's a valid point but not one I'll be discussing.

Database libraries are, ho

sycobuny

def event(queuename, *nums)
    puts "Got event for #{queuename}!"
    puts "    nums: #{nums.join(', ')}"
end

begin
    while line = $stdin.readline
        args = line.chomp.split(/\s+/)
        1.upto(args.length - 1) { |x| args[x] = args[x].to_i }

sycobuny

 >>> perl -MO=Concise,-exec crazier.pl 
1  <0> enter 
2  <;> nextstate(main 66 crazier.pl:4) v:%,*,&,{,$,2048
3  <{> enterloop(next->8 last->8 redo->4) v
4  <;> nextstate(PackageA 51 crazier.pl:7) v:%,*,&,{,$,2048
5  <{> enterloop(next->7 last->7 redo->6) v
6  <0> stub v
7  <2> leaveloop vK/2
8  <2> leaveloop vK/2
9  <;> nextstate(main 69 crazier.pl:41) v:%,*,&,{,$,2048

sycobuny

use v5.14;
use warnings;

package PackageA {
    # put subs in here and then coderefs passed to PackageA->configure() can use these methods
    # as though they're in the right package
    package PackageA::ConfigurationSubs {
        sub hello {
            say "hello, world";
        }

sycobuny

#!/usr/bin/env perl

use v5.14;
use warnings;

use File::Spec;
use IO::File;
use autodie;

my ($dir);