I keep ruminating on this, trying to understand what you're trying to do. I'm guessing that you want to have one master array that holds data and attributes, but you want to be able to grow/shrink the data portion of it, while maintaining the aliases to the attributes. If so, the splice limitation I mentioned above might not be a problem. For example:

use strict;
use warnings;
use Data::Alias;

my @data = ( 1 .. 3 );
my @attributes = ( 'a' .. 'd' );

my @master = ( scalar @data, @data, @attributes );

alias my @alias = @master[ 1 + $master[0] .. $#master ];

print "After alias\n";
print "master: ", join(q{,}, @master ), "\n";
print "attrib: ", join(q{,}, @alias  ), "\n";
print "\n"; 

$alias[0] = 'z';

print "After change\n";
print "master: ", join(q{,}, @master ), "\n";
print "attrib: ", join(q{,}, @alias  ), "\n";
print "\n";

splice @master, 2, 0, '6';
$master[0]++;

print "After splice\n";
print "master: ", join(q{,}, @master ), "\n";
print "attrib: ", join(q{,}, @alias  ), "\n";
print "\n";
[download]

Prints

After alias
master: 3,1,2,3,a,b,c,d
attrib: a,b,c,d

After change
master: 3,1,2,3,z,b,c,d
attrib: z,b,c,d

After splice
master: 4,1,6,2,3,z,b,c,d
attrib: z,b,c,d
[download]

The splice happens in the data section, which is not aliased, and it doesn't disturb the alias to the attributes. So offsets you define for specific attributes (from the start of @alias) would be preserved.

Wow. Not only did you provide the module needed, but you also provided the inside-out thinking that makes the problem solveable.

Basically, the idea is that I have a set of attributes and an array that grows and shrinks. Instead of having a hashref with an entry pointing to an arrayref, I was thinking I should be able to just have an arrayref. If that's all it was, I could have the attributes up front and the array in the back. But, I want to be able to add attributes in subclasses, so the array has to live up front. I also wanted to use splice for some of the array manipulation sections.

I'll have to see if I can work this in, but it's definitely a promising idea. THANKS! :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

You're splicing the wrong array. He wants to allow the module's user to splice the array it sees (the slice) and have it affect both the slice and the master array.

I know. I was trying it the other way around, aliasing the part that isn't being sliced. That's why I didn't use "foo" and "bar" as the OP did -- I was experimenting, trying to understand the problem, not just the narrow question asked. It's not clear whether the issue is a user interface one -- trying to transparently provide the data array to a user to manipulate without impacting other parameters -- or a design one -- easier manipulation of separate of data and parameters sections behind the scenes without having to re-calculate offsets repeatedly. If the goal is providing the data as a slice, what I showed clearly doesn't do the trick.

If the data section is what has to be aliased, then I don't think it's possible with this technique without an explicit synchronization step before each access to the master to check whether the alias has been spliced and updating the master accordingly. Without knowing the precise application, it's impossible to guess what would offer better performance.

In the final analysis, I'm hard pressed to imagine that these kinds of workarounds are better than just leaving the object hash-based and keeping separate data and parameters entries.

Just brainstorming, however -- another way to separate the data and parameters while using an array-based object would be to use an inside-out object. Let the blessed reference be of the data array, put all the parameters in static hashes indexed off the memory address of the data array and use accessors to read/write the parameters. Of course, then there's all the overhead and complexity of inside-out objects, thread-safety and CLONE issues, and so on. Again, might not be worth it.

-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.