Le 30/11/2011 06:56, Allen Wirfs-Brock a écrit :
On Nov 30, 2011, at 10:24 AM, David Bruant wrote:
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
...
Objects serve as one of our primary abstraction mechanisms (the other is
functions and function closures have similar allocation issues).
On Tue, Nov 29, 2011 at 11:03 AM, David Bruant bruan...@gmail.com wrote:
Le 29/11/2011 19:05, Mark S. Miller a écrit :
On Tue, Nov 29, 2011 at 10:01 AM, David Bruant bruan...@gmail.com wrote:
Le 29/11/2011 18:40, Tom Van Cutsem a écrit :
[...]
The general rule here is: if your code
Le 29/11/2011 21:24, Mark S. Miller a écrit :
On Tue, Nov 29, 2011 at 11:03 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 29/11/2011 19:05, Mark S. Miller a écrit :
On Tue, Nov 29, 2011 at 10:01 AM, David Bruant
bruan...@gmail.com
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
On Nov 30, 2011, at 8:15 AM, David Bruant wrote:
Avoiding an extra allocation is the only worry for this last point.
Very much like Tom worried about mirror allocation at
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018734.html
On Nov 30, 2011, at 10:24 AM, David Bruant wrote:
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
...
Objects serve as one of our primary abstraction mechanisms (the other is
functions and function closures have similar allocation issues). Anytime you
you tell programmers not to
2011/11/28 Allen Wirfs-Brock al...@wirfs-brock.com
too many ways to do the same thing is desirable. We already have a number
of reflection functions hung off of Object. Your proposal replicates
most of those and adds others as functions in the @reflect module. Such
duplication is
Le 28/11/2011 01:07, Allen Wirfs-Brock a écrit :
On Nov 26, 2011, at 11:52 AM, David Bruant wrote:
Le 24/11/2011 22:29, Tom Van Cutsem a écrit :
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
If we are going to have a @reflection module that is of
On Nov 26, 2011, at 11:52 AM, David Bruant wrote:
Le 24/11/2011 22:29, Tom Van Cutsem a écrit :
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
If we are going to have a @reflection module that is of broader
applicability then just writing proxy handlers I'd like us to consider a
On Nov 26, 2011, at 3:55 AM, David Bruant wrote:
Le 26/11/2011 01:52, David Bruant a écrit :
Le 24/11/2011 22:29, Tom Van Cutsem a écrit :
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
At the core is a root question whether we want to expose a functional or
object-oriented API for
On Nov 24, 2011, at 7:37 AM, David Bruant wrote:
Le 24/11/2011 16:04, Sam Tobin-Hochstadt a écrit :
You can't do the following:
import {new, delete} from @reflect;
because you can't bind `new' and `delete'. Even if this were allowed,
then `new(...)' would still be a syntax error.
Oh
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
If we are going to have a @reflection module that is of broader
applicability then just writing proxy handlers I'd like us to consider a
Mirrors style API. Otherwise I'm a concern will continue to have a
proliferation of reflection APIs as
11 matches
Mail list logo
