Well, this feature could still be implemented with a coroutine.

Agreed, it could. Indeed, that has some interesting possibilities for allowing the creation of tranparent coroutines.

There is indeed effectively no difference between your proposition and tieing. So why invent a new special-use mechanism rather than streamlining an existing one that can do the same job and more besides?

First, I would contend there is a significant difference. I have an attribute. I wish to control the values that can be assigned to that attribute (whether that attribute is externally exposed or only settable from with the class definition).

The language allows me to have a method with the same name as that attribute. The obvious place to encapsulate all interactions with that attribute, is within that method. Scattering the decision as to what value will be set by assignments to the method, and the code to validate those assignments, into lots of little code blocks makes for complexity that should be avoided.

Equally, if the lvalue in question is an array or hash, or a splice across one or the other, then recieving the values one at a time through the STORE method of a tied array makes for horrible problems.

What if the validation criteria is that all the values in the list being assigned must be unique? Now I have to add additional (global) temporary variables in order that I can view the data as a single list in order to verify it. But how will I know when I have recieved the last value? And what happens if I reject the attempted list assignment? How does the recieving code get that notification? What does it do with it?

Even if the assignment is a scalar lvalue. When the FETCH method is called, will it recieve the (variable number of?) parameters passed from the calling code that are required to determine the lvalue to use? (Think substr( $self, $offset, $length ) =  $str; here!)

And if it does, and so the substring is assigned, now I want to validate that assignment. Will the same parameters as were passed to the FETCH be available to the STORE? If not, that again means that the programmer has to make provision for temporary (global) storage to retain those values between the calls to the FETCH and the STORE.

The "example code" shown that outlines the inline tie mechanism shows a TEMP method. This is provided in order to allow lvalue subs to be temporised. What happens if the programmer doesn't provide a TEMP method? Does that mean that this method cannot be temporised? Or will the system provide a default TEMP method?

Assuming the programmer does provide a TEMP method, what should it do? Provide a temporary lvalue that will not affect the actual attribute? Then if the TEMP value is never realised, then code will never call the STORE and that temporary value will what? When will the programmer know he can discard it?

And if it is realised, when the STORE method is called, how will I know that I have to copy the value from the temporary lvalue I returned from the TEMP method ? In other words, how will the STORE method know when the value being STOREd was assigned to an lvalue provided via the FETCH method and when it has been assigned to an lvalue provided by the FETCH method? More global flags for communicating this information between these disparate methods?

And I haven't even begun to consider the implications for multi-thread code where the FETCH and TEMP methods could be called several times before a STORE method is called. That would make the problem of trying to coordinate the cross-call, global metadata impossible.

It may well be that all this has been thought about and resolved--but if it has, it certainly isn't obvious from the Apos and Syns.

Most such validation should really be done by the subtype system in Perl 6.

Anyone who remembers writing Pascal and having:

TYPE ID = PACKED ARRAY [1..8] OF CHAR;
TYPE FULLID = PACKED ARRAY [1..10] OF CHAR;
TYPE NAME = PACKED ARRAY [1..32] OF CHAR;
TYPE FIRSTNAME = PACKED ARRAY [1..12] OF CHAR;
TYPE LASTNAME = PACKED ARRAY [1..20] OF CHAR;
[download]

and all the problems that it created, will be twice shy of attempting to use a type system to provide for data validation. It is the first step on the slippery slope towards deeply hierarchical class structures, layered one atop the other. Something I thought Perl was explicitely trying to avoid.

The obvious place to encapsulate all interactions with that attribute, is within that method.

Only if all of your validations are completely unique. Otherwise, that's lacking in abstraction. People are already getting sick of writing the same redundant validation code all over the place, hence the utility of Regexp::Common, Params::Validate and others. There is a proven need for abstraction here.

recieving the values one at a time through the STORE method of a tied array makes for horrible problems. […] What happens if the programmer doesn't provide a TEMP method? [a dozen questions of temporization semantics]

These are all good points. They need to be resolved as they affect uses of tie. The STORE issue is a problem in many contexts. The semantics you're asking about need to be clarified.

Discussing these issues in the context of lvalue subs is a red herring, though. Why not think about ways to fix the problems with tieing (which affect all uses of tieing and should be addressed in any case), rather than spending so much energy trying to invent a new (and likely also partially broken) mechanism to implement lvalue subs?

That's where Larry is…

Anyone who remembers writing Pascal and having:

I don't understand how that is relevant to the discussion at all. I don't know how that is supposed to show any validation attempt (are you trying to constrain the length of the strings?), and in any case, just because Pascal's type system sucked doesn't prove anything about type systems in general. Haskell and ML are counterexamples. I thought you liked Haskell?

Makeshifts last the longest.

Only if all of your validations are completely unique.

That isn't the point. If you want to call a common validation routine from the validation part of the subroutine, there is nothing to prevent that. The problem with tieing is that you loose all the contextual and ancillary information available from the call. Eg the parameters.

A general tie mechanism FETCH has none or one parameter. The STORE has one or two. Adapting the tie mechanism to provide access to the parameters to a general subroutine call--especially with all the variations of named, positional, slurpy & non-slurpy parameters that P6 allows--is simply impossible. How then to convey that information to the FETCH and STORE?

I don't understand how that (the pascal typing system) is relevant to the discussion at all

The example Pascal was intended to show that when trying to use the type system to validate parameters, it becomes necessary to create myriad individual types all slightly different. Once you have that, you then have to deal with the problem of trying to composite values together to form composite types.

The problem is not limited to Pascal's sucky type system, but to all type systems that attempt to use that typing system for value validation.

How do you define a type to validate a string only contains upper case chars? Or is less that 20 chars in length? Or is a prime number? Or a power of two? Or a number between 0 and 1?

How would you encapsulate the verification criteria for a list assignment where all the values must be:

1. unique (both within themselves and within the larger array to which they are being assigned through a slice operation).
2. Odd Even. (Updated to avoid the Odd implies non-zero sidebar).
3. Non-zero

How do you define that as a type?

Typing and validation are entirely different animals and attempting to use the former for the latter invites a huge mess.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.