[e-lang] Need reactions
Kevin Reid
kpreid at mac.com
Thu Nov 9 10:06:09 CST 2006
On Nov 9, 2006, at 3:12, Mark S. Miller wrote:
> Hi Kevin,
>
> In preparation for the imminent release of 0.8.37c, please check
> out the
> recent bug reports at
> <https://sourceforge.net/tracker/?
> func=browse&group_id=75274&atid=551529> and
> let me know if they capture your sense of what we agreed on
> tonight. Thanks!
They all look fine except for 'Retiring __getPropertySlot':
> Steps: By 0.9, we should deprecate it, and have any use
> of it generate a warning in the trace log.
>
> Afterwards, we should change the dot-props syntax, if
> it remains, to expand to a call to a function providing
> similar functionality.
I believe 0.9 should change the expansion. This way 'modern' (0.9+)
programs can stop worrying about implementing/forwarding
__getPropertySlot.
> Also, please let me know your reaction to the "followup" note at
> the bottom of
> https://sourceforge.net/tracker/index.php?
> func=detail&aid=1260156&group_id=75274&atid=551529
> Thanks.
Quoting it:
> Witness has been renamed Audition.
> ask is given only an Audition.
> The Auditor asks the Audition for the source.
> Perhaps we still need an Audition guard, in which case the Java
> Audition interface should be declared a marker interface. Until
> this is resolved, this bug remains open.
A guard is needed for auditors to verify that the audition they
receive will behave properly in its ask/1 method. Without that guard,
you merely can't use ask if you don't want the auditor you provide to
it to be revealed/fiddled with/whatever.
Furthermore, I think there ought to be a separate EAudition guard,
which passes witnesses providing getObjectExpr/0 and scope
examination, etc. This is so that if we introduce auditing of other
or not-quite-E languages in the same 'ELib', programs can avoid
accidentally approving something that doesn't match the semantics
they assumed.
--
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang
mailing list