Lazy eval -- an example issue
kris
foo at bar.com
Mon Aug 21 16:57:09 PDT 2006
Frank Benoit wrote:
> I think the lazy eval is a great feature, but in this form it has also
> great drawbacks.
>
> The code isn't that much readable as it was before. You don't know what
> will happen. Will that expression be evaluated or not? Or will it be
> evaluated more than once?
>
> There is no possibility to choose between
>
> func( char[] a ) vs. func( char[] delegate() dg )
>
> func( funcRetInt() ); vs. func( &funcRetInt );
>
> It would be really important for me to have readable code. I want to
> look at the code, and want to have an impression what will happen.
>
> What really would help, is if the the delegate is marked in some way as
> such. In the last releases of DMD the {} syntax was there. With it you
> needed the return statement. Perhaps we can choose the {} syntax with an
> optional return statement....
>
>
> { "abc" } => char[] delegate()
> { return "abc"; } => char[] delegate()
>
> func( "abc" ) calls func( char[] a )
> func({ "abc" }) calls func( char[] delegate() dg )
> func({ return "abc"; }) calls func( char[] delegate() dg )
>
> With that syntax one can immidiatly see "this is a delegate, if it is
> called or not or more than once depends on func()" and the more typing
> of {} is not too much.
So, we have some existing code for logging. Very efficient, and highly
flexible. It follows the design patterns popularized by Log4J, with
Appenders, Layouts, etc
The D version of a logger has five 'levels' of logging:
log.trace (char[])
log.info (char[])
log.warn (char[])
log.error (char[])
log.fatal (char[])
and the intent (with dmd.164) was to add these flavours, specifically to
address the point Walter makes about unnecessary message construction:
log.trace (char[] delegate() dg)
log.info (char[] delegate() dg)
log.warn (char[] delegate() dg)
log.error (char[] delegate() dg)
log.fatal (char[] delegate() dg)
The support code was installed fairly recently, and the above
delegate-wrappers were on the todo list.
However, dmd.165 will presumeably not compile this code? Won't there be
an overload ambiguity? If so, it illustrates a serious shortcoming in
the new syntax
More information about the Digitalmars-d
mailing list