I question whether this statement is really a correct characterization of inside-out objects:

# - No method of an inside-out class accesses (de-referrences) the body of its objects directly.

When using inside-out classes for 'black box' inheritance, this is often exactly what is desired, e.g. subclassing an IO::File or other unusual base object type.

Overall, it's an interesting approach and you've clearly given it a good deal of thought -- but I don't really understand how this is "beyond" inside-out objects -- rather it's an extra level of indirection and I'm not entirely clear what the benefits are or whether those offset the 'costs'.

On potential costs/downsides:

• Compile time field name checking is lost (as someone else mentioned)

• Overhead of calls to ego (vs refaddr) -- Inside-out classes that offer "black box" inheritance still require overhead of calls to refaddr. Both can be cached outside of loops, so this is really an issue of just ego vs refaddr (which may not matter for most applications). And Object::InsideOut's array implementation with the index stored in the object itself will be faster than either approach anyway (but doesn't do direct "black box" inheritance as a consequence).

• With "regular" inside-out classes, getting at the lexical storage of data from outside the file scope requires fiddling with PadWalker, whereas it looks as if ego could be fooled because of caller to access underlying data. (Maybe this is covered in the XS discussion which I didn't really follow completely.) If so, "breaking" encapsulation becomes easier from the outside. (Some might consider that a feature, I suppose.)

I'd be interested in a concise summary of the features/benefits. Right now I really only see one:

• Classes get "inside-out" property storage without needing to define fields and associated data storage hashes/arrays explicitly.

(Though I personally question whether that is really a net savings in characters typed if accessors will need to be defined for most fields anyway or if some sort of field-name validation is added.)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.