in reply to Re: Class::InsideOut - yet another riff on inside out objects.
in thread Class::InsideOut - yet another riff on inside out objects.

Hmm, I think we are getting away from the real issue. Finding a way to hook up lexicals with attributes is not the real point, though interesting in itself. The real point is to make a succinct way to declare instance data.

So, don't use an attributed declaration. Instead, use a syntax like: field ('name', options); that will create the underlying hash itself, rather than the caller making one.

The underlying hash can either be "hands off", or there can be a way to get to it (return value from that call?) if you really want to support it.

{ # extra scope
$xx= field qw/xx private/;
sub something
 {
 # I use that instance data internally.
 # ...
 ... $$xx{$id} ...
 }

[download]
Being private, no access method is autogenerated, and the returned ref is the only way to get to it.

—John

Replies are listed 'Best First'.
Re^3: Class::InsideOut - yet another riff on inside out objects.
by Aristotle (Chancellor) on Dec 19, 2002 at 20:19 UTC
    Well, the point is twofold:
    1. Most importantly, we need a way for a generic DESTROY to work.
    2. Ideally we wouldn't have to name the the field more than once and only once.
    The attribute semantics seem to offer the most succint possible syntax to reach both of those goals - provided it can at all be made to work, of course.

    Makeshifts last the longest.

[reply]
      The generic destroy would work fine, since the class would remember all the fields it generated using this syntax just as well as it could using any other syntax.

      I agree that this still names the field twice (public name optional, internal ref optional) when most of the time you'd be happy to use the same name in both places.

[reply]
Re^3: Class::InsideOut - yet another riff on inside out objects.
by adrianh (Chancellor) on Dec 19, 2002 at 20:26 UTC

    This would work, but has a couple of minor issues:

    • We've added another layer of indirection. Means that direct access is a little slower.
    • We have to mention the "name" of the object attribute twice (the xx in $$xx and qw/xx private/.
    • It's more work if you don't want the accessors.

    If we want to name an object attribute explicitly we could do it with a modified :Field attribute. For example, something like this wouldn't be hard to implement.

    my %foo : Field;         # no accessor
my %foo : Field(as foo); # create accessor named foo

    [download]

    While easy to implement, it still has the duplication of names... which offends :-)

[reply]
[d/l]
[select]
      Direct access is slower: Dereferencing the hash ref is not a big deal. It's only taking a reference that's slow, for some reason.

      Naming the object twice: good point, that's no better than putting the name in the attribute's text.

      Not generating an accessor: how do you do it now? I suppose that if you write your own accessor method it will overwrite the generated one, but then you have to make sure it happens in that order, and you have to take pains to zap the ones you don't want.

      I think the 5.x attribute mechanism should be extended to get the source name and ref, not just (sometimes) a glob. As is now, attributes are pretty pointless on lexicals because it doesn't provide a way to associate the attribute with the thing it's attached to!

      —John

[reply]
        Not generating an accessor: how do you do it now?

        I don't generate them by default. You have to ask explicitly for accessors by using Class::InsideOut::Accessor.

        I suppose that if you write your own accessor method it will overwrite the generated one, but then you have to make sure it happens in that order, and you have to take pains to zap the ones you don't want.

        You would also get nasty errors under strict/warnings due to redefining the sub.

        With the current source filter mechanism the "right" way of doing it would be to turn the filter off when you don't want to have any accessors, e.g.:

        package Foo;
use base qw(Class::InsideOut);
use Class::InsideOut::Accessor; # build accessors for Fields

use %foo : Field;  # foo method built automatically

no Class::InsideOut::Accessor;  # stop building accessors

use %bar : Field;  # no accessor sub built

sub bar { whatever... };

        [download]
        I think the 5.x attribute mechanism should be extended to get the source name and ref, not just (sometimes) a glob.

        This may be possible. I'm not certain whether the difference in visibility of lexicals between 5.6.1 and 5.8 is a bug or not... need to spend some time looking at the code ;-)

        <update>See Lexical pad / attribute confusion for more detail on what I find confusing.</update>

        As is now, attributes are pretty pointless on lexicals because it doesn't provide a way to associate the attribute with the thing it's attached to!

        I think that's an over statement. The vast majority of the time you are interested in applying an attribute to a bit of perl data, and don't give a fig for the variables name. This is the only time I've used attributes where this has been an issue.

[reply]
[d/l]
        think the 5.x attribute mechanism should be extended to get the source name and ref, not just (sometimes) a glob.

        I've just come across Attribute::Handlers::Prospective, yet another neat module from TheDamian, that allows you to do this. From the documentation:

        If a lexical variable is given an attribute, there is no symbol table to which it belongs, so the symbol table argument ($_[1]) is set to the string 'LEXICAL(name)', where name is the name of the lexical (including its sigil). Likewise, ascribing an attribute to an anonymous subroutine results in a symbol table argument of 'ANON'.

        Neat. Implemented with a source filter.

[reply]
[d/l]

In Section Meditations