[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] Need reactions
From:       Kevin Reid <kpreid () mac ! com>
Date:       2006-11-09 16:06:09
Message-ID: B65C3E4D-932E-48CA-89B5-1D871ED705AB () mac ! com
[Download RAW message or body]

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/>


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]