RFC: an unusual inside-out object generator

Dear fellow monks, I'm seeking comments on a new module I've written, including suggestions for improving its name before I release an initial version to CPAN. This module started as a thought exercise coming out of Abigail's talk at YAPC::NA on Lexical::Attributes and Ingy's talks about Spiffy. It's now reached the point where the basics are working and it might be of interest. The working name is "Object::Local". Here's a quick example of use:

package My::Object;
use strict;
use Object::Local;

give_methods our $self;

our $name  : Prop;
our $color : Prop;

sub as_string : Method {
    return ref($self) . " named '$name' with color '$color'";
}

1;

__ELSEWHERE__

use My::Object;
my $o = My::Object->new;
$o->set_name("xdg")->set_color("orange");
print $o->as_string;

__RESULT__

My::Object: named 'xdg' with color 'orange'
[download]

At its core, this module helps create inside-out objects. It does some things like Lexical::Attributes and Spiffy, but in some different (better? worse?) ways. Like those modules, it's a bit unusual compared to other object/class generators out there and has some of its own unique approaches:

Provides $self automatically to methods -- without source filtering
Provides dynamic aliasing of properties within methods, eliminating accessor calls in methods -- again, without source filtering
Uses attributes to mark properties and methods, but only in the BEGIN phase so should be mod_perl friendly (though I haven't tested this yet)
Under the hood, uses local() and dynamic scoping of package variables ($self, et al.) while remaining 'strict' friendly

Suggestions for a better name are welcome. Some criteria I'd like to apply to the naming include:

evocative -- the name should convey some salient point about the module
relatively short -- the whole point of the module is less typing so a long name is counterproductive
catchy -- it would be nice to stand out from the zillions of Class:: modules since this actually is pretty wierd and different
not too frivolous -- e.g. "Spiffy" meets the above three but is a bit on the frivolous side (sorry, Ingy)

I've considered variations such as:

Object/Class::Less -- 'less' typing for the programmer, plus a bit of a pun
Class::Selfless -- more specific on the "less"
Object::Voodoo -- lots of under-the-hood namespace munging, function wrapping, etc. to make this work
Object::Dynamic -- dynamic scoping tricks heavily used throughout
Class::OutsideIn -- like InsideOut, but the global/local trick is another type of inversion

Your early feedback on functionality or names is appreciated. When I release the module, I'll have more detailed commentary on the internals, speed benchmarks, and pros/cons versus other approaches.

Thank you,

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on RFC: an unusual inside-out object generator Download Code

Replies are listed 'Best First'.

Re: RFC: an unusual inside-out object generator
by simonm (Vicar) on Jul 22, 2005 at 19:53 UTC

I'd add three guidelines from perlmodlib to your naming list:

Generally the name should reflect what is special about what the module does rather than how it does it.
Avoid any risk of ambiguity.
Always try to use two or more whole words.

A name like "Object::Voodoo" really doesn't say anything abuot "what the module does," in other words, about the public functionality.

Similarly, Object::Dynamic and Class::Less seem ambiguous: starting from the name, there's very little chance that people would be able to guess what the module does, because there are so many other things that could be meant by "dynamic" or "class-less".

I would suggest finding a name that was more explicit about what the module does: it uses designated package variables as accessors for object instance values. (Right?) So your package name should reference those key concepts: object instances, and locally-scoped package variables.

Rather than shortening your current name of Object::Local, I'd lengthen it to Object::LocalVars. In the context of Perl, I think that people will rapidly parse "local vars" as "dynamically scoped package variables along the lines of local()."

I understand that you want the class name to be short, but since you only have to type it once per file, I think this is a mis-directed optimization. The extra few keystrokes in the name are a small price for people scanning a list of module names on CPAN being able to guesstimate the features it provides.

Update: If you'd a terse and "catchy" interface, provide an optional props.pm psuedo-pragma that delegates to the main class so that people can write use props; mad props, G; our $name : G;. People who are looking for something "wierd and different" can use this interface, while people who are looking for something practical will be able to understand the primary module name.

[reply]
[d/l]

Re: RFC: an unusual inside-out object generator
by Zaxo (Archbishop) on Jul 22, 2005 at 19:30 UTC

You may have found a route to the fabled less.pm.

After Compline,
Zaxo

[reply]

Re: RFC: an unusual inside-out object generator
by Jenda (Abbot) on Jul 26, 2005 at 14:58 UTC

Looks kinda nice, how well does it work with inheritance? What happens if a child class defines a property with the same name as the parent one?

I like the Class::OutsideIn name best.

Is there any place this may be downloaded from already? It's hard to discuss something you can't test.

Jenda
XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

[reply]

Re^2: RFC: an unusual inside-out object generator

by xdg (Monsignor) on Jul 26, 2005 at 16:05 UTC

Inheritance works very well, for some definitions of "well". The inside-out design is generally very orthogonal -- meaning that it doesn't collide data with superclasses. You can use Object::Local to subclass pretty much any other class, even classes based on some other system -- all it cares about is that the superclass constructor gives back a reference.

The tricky bit is in the accessors, though. If you define properties with the same name as a superclass, you have to be careful what you wind up with for accessors. By default, Object::Local uses private properties -- no accessors are created as you access the properties directly via the local aliases. (This is sort of the major goal -- strict-safe properties without accessor calls, though you can request accessors, too.) But in that case if the superclass has an accessor with that name, you have to be careful not to call it by mistake when you don't mean to.

It does not really support multiple inheritance, though, as that generally requires too much coordination within/between object frameworks for setup/teardown. The Object::Local approach treats the superclass as a black-box -- it lets the superclass build a new object, then does its own additional initialization. On destruction, it does its own teardown then has the superclass do its teardown. The design goal is maximum orthogonality.

If you're really jonesing for a sneak-peak, you can pull from my subversion server. It's a moving target, of course, so some revisions may be buggy, but I usually try not to check in unless all tests are passing. (Occasionally I have to if I'm moving back and forth from the laptop.) Documentation is very sparse so far, so the best way of seeing how it works is to look at the 't/' directory, where the 'Objects' directory contains many simple examples used in testing. I hope to have a release to CPAN by the end of the week -- at this point it's mostly an issue of documentation. The API should change minimally.

(Edited to change repository target to renamed "Object-LocalVars" directory)

-xdg

[reply]