Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Blob.EVAL method #3432

Open
p6rt opened this issue Jul 9, 2014 · 5 comments
Open

Implement Blob.EVAL method #3432

p6rt opened this issue Jul 9, 2014 · 5 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Jul 9, 2014

Migrated from rt.perl.org#122256 (status was 'open')

Searchable as RT122256$

@p6rt
Copy link
Author

p6rt commented Jul 9, 2014

From @coke

S29 says that EVAL should work on Buf in addition to Str; There is one
test in S29-context/eval.t that tests for this but is skipped.

Could probably use more tests.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented May 12, 2016

@coke - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Oct 4, 2017

From @zoffixznet

Quoting the relevant portion of S29 that describes how the buf needs to be processed​:

  Execute C<$code> as if it were code written in C<$lang>. If C<$code>
  is of type C<Buf>, the same decoding techniques are applied as a compiler
  for C<$lang> would usually do to input files.
 
  The default for C<$lang> is the language in effect at the exact
  location of the C<EVAL> call.

@p6rt
Copy link
Author

p6rt commented Oct 5, 2017

From @zoffixznet

On Wed, 09 Jul 2014 07​:10​:31 -0700, coke wrote​:

S29 says that EVAL should work on Buf in addition to Str; There is one
test in S29-context/eval.t that tests for this but is skipped.

Could probably use more tests.

Everything is now implemented[^1] with more tests added[^2], and I unfudged[^3] one
of the two pre-existing tests. However, the remaining one tests for existence
of Blob.EVAL **method**.

Feels like it shouldn't be added at all. I heard people in the past express
desire to remove Str.EVAL, especially because it (currently) by-passes[^4]
the MONKEY restriction. It's a security-sensitive part of machinery and
doesn't feel right to add many places where it's available; especially
since subform can even by called as a method via `.&EVAL`; so why add
an explicit method?

Personally, I'd toss that fudge and not implement the method, but leaving
this ticket open as RFC for now. Below is also a diff that adds the EVAL
method to Blob.

[1] rakudo/rakudo@6c928d61d9
[2] Raku/roast@6949cb13ad
[3] Raku/roast@60f4bd7850
[4] https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128684#ticket-history

Inline Patch
diff --git a/src/core/Buf.pm b/src/core/Buf.pm
index eca050e..faf7ead 100644
--- a/src/core/Buf.pm
+++ b/src/core/Buf.pm
@@ -101,6 +101,10 @@ my role Blob[::T = uint8] does Positional[T] does Stringy is repr('VMArray') is
         )
     }
 
+    method EVAL(*%opts) {
+        EVAL(self, context => CALLER::, |%opts);
+    }
+
     multi method Bool(Blob:D:) { nqp::p6bool(nqp::elems(self)) }
 
     multi method elems(Blob:D:)   { nqp::p6box_i(nqp::elems(self)) }

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
@lizmat
Copy link
Contributor

lizmat commented Jan 11, 2020

Feels to me this should just be implemented, or Str.EVAL should be deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

2 participants