Mailing List Archive

As I understand it, Oshun provides a syntax for asserting "checks" when
assignments to variables are made. In the MVP each "check" is
system-defined/built-in and has basics like integer/number/etc.

I'm saying that there's no reason those built-in checks have to be implemented
by casting the value as a string and performing a regular expression pattern
match on the result.

Instead I would expect these built-in checks to not perform any casting and
instead evaluate the candidate values as-is using the most efficient known
methods like asking is this an IV etc in the "integer" check.

As far as I know that's the same strategy Perl::Types would be using.

Neither would unconditionally be using regular expressions to ask if a value was
an integer.

-- Darren Duncan

On 2023-08-22 9:21 p.m., Avery Adams wrote:
> Resending to list.
>
> ---------- Forwarded message ---------
> From: *Avery Adams* <oldtechaa@gmail.com <mailto:oldtechaa@gmail.com>>
> Date: Wed, 23 Aug 2023 at 15:55
> Subject: Re: PPC Elevator Pitch for Perl::Types
> To: Darren Duncan <darren@darrenduncan.net <mailto:darren@darrenduncan.net>>
>
>
> With Oshun providing dynamic "types", I would have to imagine it would be less
> performant even using the same approach to data checking, simply because the
> types aren't predefined with known structure/characteristics. Would that not be
> the case?
>
> Avery
>
> On Wed, 23 Aug 2023 at 15:29, Darren Duncan wrote:
>
> On 2023-08-22 8:13 p.m., Oodler 577 via perl5-porters wrote:
> >> I would expect Oshun to follow the same kind of path Corinna did, which
> >> yielded a very tight and efficient implementation in principle.
> >
> > Why would you expect that?
>
> I would expect Oshun to not use regular expressions to evaluate fundamental
> types because that is the best solution.  If Perl::Types can find a better way
> than using regular expressions, then Oshun can apply the same better solution
> directly as well.  Why would this not be a reasonable assumption?
>
> -- Darren Duncan
>