in reply to Re^5: Assignable Subroutines
in thread Assignable Subroutines

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.

Replies are listed 'Best First'.
Re^7: Assignable Subroutines
by BrowserUk (Patriarch) on Jan 26, 2005 at 16:44 UTC
    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.
[reply]

      it becomes necessary to create myriad individual types all slightly different.

      That's not better than a myriad validator routines all slightly different?

      How do you define a type to validate a string only contains upper case chars? Or [&hellip]

      Traits, tieing.

      Makeshifts last the longest.

[reply]
        That's not better than a myriad validator routines all slightly different?

        No. The validation is applied only to the value, and only where required.

        If I defined a 'string-that-can-only-contain-uppercase' type and a 'string-that-can-only-contain-decimal-digits' type and then later want to join my userids with their respective phone numbers for display, I have a type clash.

        This is conflating type validation with value validation.

        Traits

        How do traits validate an lvalue assignment to a partital field.

        eg. substr( $x, $start, $length ) = $str;

        tieing

        How does STORE gain access to the lvalue selection criteria from the lvalue sub call?

        Same example. How do I know at STORE time, what part of the string is affected?

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
[reply]
[d/l]
      I think you're suffering from tunnel vision. TimToady said that the typing mechanisms in Perl6 would help alleviate the validation issues you're running into. He didn't say that those mechanisms would be your only validation prospect. You should know by now that Perl doesn't say anything but TMTOWTDI.

      Now, if you wanted to use the typing mechanisms, you're more than welcome to it. And, there will be sufficient support that you can define your types in one place and use them everywhere.

      But, if you wanted to use, say, pre- and post-execution subroutines or Params::Validate or any other scheme ... go right ahead. If you wanted to use a mix of them ... go right ahead.

      The point is that typing exists and is expected to alleviate some of the validation burden. It's not going to be the only possibility. TMTOWTDI is where languages like Pascal fall down. It's not the typing system.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

        TMTOWTDI is where languages like Pascal fall down. It's not the typing system.

        Actually the type system is why vanilla Pascal is useless while C isn't. Pascal includes the length of an array in the type, which makes it impossible to pass a STRING[40] to a function with a signature expecting a STRING[100].

        Makeshifts last the longest.

[reply]
[d/l]
[select]

        Updated: to correct my misreading of who I was responding to. dragonchild's sudden interjection into what had been a two person thread caught me out. I apologise to dragonchild for my mis-attributions.

        I am not suffering from tunnel vision.

        You Someone else brought up the typing system--not I.

        I simply explained why typing is no alternative to validation.

        You are completly ignoring all the reasons I have outlined why the tie mechanism cannot be used to perform validation.

        But, if you wanted to use, say, pre- and post-execution subroutines or Params::Validate or any other scheme...

        When? How? Show me an example?

        I have, in answer to your previous assertions, shown how the mechanism described for validation of the value assigned won't work. Now you throw this in as if it answers something? It doesn't!

        All of the problems outlined still remain unanswered and this throwaway line doesn't even pretend to address them.

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
[reply]

In Section Meditations