Re^3: [perl6] Complex Attribute Validation and/or Triggers (good OO)

[raiph]

»»» This post is about alpha status Perl 6, not rock solid Perl 5 «««

tl;dr A) You're already using automatically generated method calls without knowing it. B) Your assignments will continue to work if you override these with your own manually written attribute accessors. C) There's more to this than meets the eye. ;)

If one compiles this:

class c { has $.lb }

the compiler creates both a private read-only attribute and a public read-only accessor method. It's as if one had written:

class c {
    has $!lb;
    #| Auto-generated if there's no explicit `lb` method: 
    method lb { $!lb }
}

The generated `lb` accessor method provides public read-only access to the otherwise private read-only `$!lb` attribute.

If one writes:

class c { has $.lb is rw; } # note the `is rw`

the compiler automatically creates a corresponding lvalue method that provides read/write access as if you had written:

class c {
    has $!lb;
    #| Auto-generated if there's no explicit `lb` method: 
    method lb is rw { $!lb } # note the `is rw`
}

When the compiler sees code of the form `$i.lb = 6` it calls the `lb` method and treats the result as a container to which the RHS (the `6`) is assigned. For example one could write the following bizarre but hopefully self-explanatory code:

my $container;
class c {
    #| `is rw` means return the container, not its value 
    method m is rw { $container }
};
my $o = c.new;
$o.m = 6;
say $container # prints `6`, the container's contents

---

With that confusion out of the way (hopefully I haven't created more!) you may be interested in the following (edited) dialog about your Interval example use case:

raiph    What's the intended way to create
         (the equivalent of) validating setter methods?
jnthn    Preferably, fold the validation into the type
         (using subset types)
raiph    will a subset type on an attribute support access to self?
jnthn    No
         If you want an l-value-ish interface where
         you can do what you like, there's Proxy
         But an object with interesting enough invariants
         that you want to do more sophisticated things
         probably deserves an interface expressed in
         terms of meaningful method names rather
         than just getter/setter logic.
raiph    fwiw the use case is an Interval class with
         lower/upper bounds; setters for those; and
         the invariant lower <= upper.
jnthn    I lack context, but off-hand, Interval sounds
         to me like a value object, and so the kinda thing
         where I'd go for an immutable design.
         (And validate at construction time)

---

Which brings me to my cryptic "more to this than meets the eye" comment at the start. There's tye's and jnthn's admonitions. And more than I was expecting of: lack of sugar; bugs; not yet implemented stuff. YMMV but, at least in the near term (this year? next?) may not...