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

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.

Replies are listed 'Best First'.
Re^8: Assignable Subroutines
by Aristotle (Chancellor) on Jan 26, 2005 at 17:56 UTC

    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]
        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.

        Only if one assumes that the various types don't have a stringify operator that will return a useful value. A bad assumption in Perl, I would think.

        Personally, I think that an optional type system that allows as much granularity as I want is a great thing. Enforcing it everywhere an assignment is made is also a great thing. As such, it's one tool in my toolbox. It's certainly not going to be the only validation tool I provide.

        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]

        STORE is part of a class and called on an instance of that class. The criteria would be part of of the instance, stored when the lvalue sub instantiates the class. Where's the problem?

        Traits by my latest understanding could be used to add hooks to a property.

        conflating type validation with value validation

        They are not separate in the first place, any more than compiled languages are separate from interpreted ones or hardware is from software. Read WhatAreTypes and ThereAreNoTypes and watch the tail-chasing.

        Makeshifts last the longest.

[reply]
Re^8: Assignable Subroutines
by dragonchild (Archbishop) on Jan 26, 2005 at 16:53 UTC
    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