Front page | perl.perl5.porters |
Postings from August 2023
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 >