I'm not convinced that fractal is the appropriate term though. Fractal refers to a patern that repeats at different scales (usually spatial).

Specifically, you're referring to self-similarity, and that's actually a source of tremendous power. One of the first bits of code I tend to build when I work with hierarchical data sets is a spider to traverse the nodes and do things to/with them. The fact that the lowest nodes in the hieararchy have the same layout as the root node leads to very fast execution. The spider can be very simple because of the consistent layout, and pass nodes to software of any complexity. Spiders are based on recursion, and recursion is the basis of fractal generation.

The basic premises of OOP include the idea the data should model reality, and that there should be a clean separation between software and data. I think how we've actually implemented OOP does a very poor job of maintaining that separation. On any given software component you'll find application data and metadata (e.g., parameters that control the software) hopelessly intermingled--which property is data and which is a parameter controlling the execution of the code?

FractalOOP achives perfect separation because the app data structure holds only app data, and the software that works on it stores its operating parameters elsewhere.

That's not to say that the data structure can't hold metadata that identifies the particular software to go with each node and parameters for the node. The difference, though, is that it's by reference, and the software isn't actually connected to the data. Instead, at runtime, a spider looks in each node's MetaData container for a reference to code that should run on the node during that execution phase. You can have multiple passes, each with its own name, like "rendering.setup" followed by "rendering.render", which runs the code appropriate for that pass. It's kind of like methods, only sideways to the conventional implementation.

The code can modify the data structure, and an interesting thing happens: The data has a lifecycle, and usually starts out small; and grows over time as software extends the data tree. Using the example of the ASP page generator, the initial data tree just lays out the structure consisting of a root HTML node containing a HEAD and BODY node. Page-specific nodes get added below those nodes. Complexity peaks, and then collapses in the final rendering phase until the data structure contains only HTML that's simply streamed out to the browser. At all times the structure of the data reflects the structure of an HTML page, just like it should.

var rec =
[
kNode_Root,
{
dispatch:
{
rendering:
{
setup:[ "asp.JSSP.GalleryPage.Setup" ],
render:[ "asp.JSSP.GalleryPage.Render" ]
}
}
},
[ kNode_Literal, {}, Parameter( "nodes", "doctype" ) ]/**/,
[
kNode_Element,
{
tag:[ 'html' ]
},
[ kNode_ChildCollection,
{},
{
head:Parameter( "nodes", "head", "head" )( Parameter ),
body:Parameter( "nodes", "body", "body" )( Parameter )
}
]
]
];

That's an HTML page. "Parameter" refers to a parameter block that you can feed the structure's constructor (much like XSL parameterization), providing app-specific nodes to be attached below 'head' and 'body'. The MetaData container is the structure below "kNode_Root", and its "dispatch" node specifies the code that should be applied to the node at various execution phases.

Oh, BTW, if the notation "asp.JSSP.GalleryPage.Setup" reminds you of Java packages, it should: I've developed a packaging system for JavaScript much like Java's (but much more useful, given how JS works).

And yet, it's still just the top of the iceberg. I probably shouldn't say too much more until I get a white paper written to establish authorship, but I hope the taste has been interesting.