Re^8: Experimenting with Lvalue Subs

[BrowserUk]

Be warned. This reply drifts way off the topic you raised/responded to. Sorry! Feel free to ignore it--not that you need me to tell you that :)

Most of the time, this isn't needed. A normal variable $foo can have any value and I don't understand why instance variables should be different in this.

I'm not sure that I agree with that. If the value of $foo comes from "outside" my program, and the use to which it is put requires that it be positive, then I am going to validate that it is. And I am going to validate it just after it receives it's value from that external source.

I would like that same ability for lvalue subs. I'm sticking with the use of that term for a reason. The lvalue sub, may be a method tied directly to an attribute. But it may also be a completely transient value untied(sic) to any permanent attribute of the class which it is a part of, and used to effect some change of state of the object without being a directly accessed attribute.

I hate giving examples, especially when related to OO things, because they always sound contrived, but I'll do it anyway. The one that springs to mind relates to a real test set by the US Navy I was reading about recently.

The object is an instance of a TrackedObject class in a radar detection system. At some point, the radar detects a new contact and creates an instance to track it. Some time later, an ident (FriendOrFoe) is received from the object, and it is assigned to the object:

$trackedObject->Ident = $ident;

The ident itself (some alphanumeric code), isn't stored in the object. It could change anytime and is pretty meaningless except for the significance it carries. The ident must be verified against the current database of valid ident code for this day, this location etc. That means calling another system to get that verified, but before doing so, I must at least verify that it is of the right format for a valid ident.

In order to get the proper verification (which will be responsible for marking this currently unknown object as freind or foe), I must also pass the current datetime, and the location of the ship or aircraft that is detecting it, and the heading of the contact.

...
method Ident: lvalue {
    LVALUE{ my $ident };
    reject( $ident ), return 
        unless $ident =~ $RE_IDENT{$LOCATION}{$DATETIME};
    
    $self->FreindOrFoe = ValidateIdent( 
        $ident, 
        $self->currentHeading,
        $LOCATION, $DATETIME 
    );
}
...

Yes. It is contrived, but it demonstrates 3 things;

1. The lvalue method need not be attached to a permenant attribute.
2. The validation can be complex. More complex than can easily be accomodated by any generalised trait mechanism. It can be very specific to this particular method.
3. It can require reference to instance specific information, and global state.

   All this is available, by definition has to be available, right there at the point of validation directly after the lvalue is assigned.

And that's the cruz of my argument. Everything, whatever that may be, required for validating the value assigned has to be available at the point of assignment. So why try and move it elsewhere?

I sit down to code to this object--I look up the "attributes" available and see the one I want to assign to. If I want to know what values I should be assigning, if the docs are vague or non-existant, I should be able to go to the definition of the method and read what validation is done.

I simple do not understand why it would be put anywhere else--except if it is technically infeasible. It isn't, so why not put it in the (to me:) obvious place?

I realise that this is more a case of syntax that semantics (or is that the other way around? :), and I realise that there is a move in P6 to make as much as possible declarative rather than imperative, but I don't believe that everything can be done declaratively.

Actually, the more time I spend thinking about it, the less likely do I think that much of the declarative stuff in P6 will get a lot of use. It (IMO) requires a style of programming, and a way of thinking, that I do not see fits with the tradition of Perl.

In many ways, it requires much deeper "systems design" than P5, and detracts from the immediacy and the "rapid prototyping" way of working that I think is Perl's greatest strength.

Time will tell on that one I guess.