November 02, 2011
On 02.11.2011 03:57, bcs wrote:
> On 11/01/2011 10:04 AM, kenji hara wrote:
>> --1;
>>
>> It you want to reduce duplication of long code, you can use string mixin.
>> enum code = q{ ...long code... };
>> static if (is(typeof({ mixin(code); })))
>> {
>> mixin(code);
>> }
>> else
>> {
>> ...
>> }
>>
>
> Please no! I've thought for years that string mixins are seriously
> overused in D. IMnsHO they should only be used as a method of last
> resort. For every case I've seen where there is a alternative to a
> string mixin, the alternative was cleaner.
>
> If people don't like the static try/catch, how about: static try/else?

Probably worth noting that in the latest release, you can instantiate a template from inside an is(typeof()), and if it fails to compile, the template instantiation will be discarded. (Prior to 2.056, if the template instantiation failed, compilation would fail).

This means you can now factor out "does it compile?" tests into a template, to reduce code duplication.
November 02, 2011
On 11/1/2011 11:55 PM, Don wrote:
> On 31.10.2011 02:21, Mehrdad wrote:
>> I've written this piece of code a fair number of times:
>>
>> static if (is(typeof(foo()))) { foo(); }
>> else { bar(); }
>>
>> When the expression inside the condition (i.e. the call to foo()) gets
>> complicated, you get lots of code duplication and things become harder
>> to read.
>
> IMHO the only problem is the is(typeof()) syntax.
> Otherwise I don't see how this has any more code duplication than:
>
> if( foo(lots_of_parameters) )
>     foo(lots_of_parameters);
> else bar();
Huh?

sorry but I'm confused as how that's related to static try/catch...
November 02, 2011
Le 31/10/2011 23:29, Mehrdad a écrit :
> On 10/31/2011 4:16 AM, deadalnix wrote:
>> Le 31/10/2011 02:21, Mehrdad a écrit :
>>> I've written this piece of code a fair number of times:
>>>
>>> static if (is(typeof(foo()))) { foo(); }
>>> else { bar(); }
>>>
>>> When the expression inside the condition (i.e. the call to foo()) gets
>>> complicated, you get lots of code duplication and things become harder
>>> to read.
>>>
>>> So I'm thinking, why not just introduce a 'static try'?
>>>
>>> Something like:
>>>
>>> static try
>>> {
>>> foo();
>>> }
>>> catch // (string ex) // perhaps let them know what the error is?
>>> {
>>> bar();
>>> }
>>>
>>> It's a clean and immensely readable improvement IMO, and it doesn't
>>> introduce any new keywords or any breaking changes to anything.
>>>
>>> How's the idea?
>>
>> That sound dangerous. You can get some compile error and not notice it.
> Huh? How is that any worse than is(typeof({ some random code })), which
> we're already doing all over the place?

At least, this if(is(typeof())) isn't executed and isn't supposed to be executed.

Here you just created a piece of code that you don't know if it will be executed and that will silently fail with no error message.

It remind me INTERCAL and it's styupid comment mecanism (at least, it was intentionnaly stupid with INTERCAL) : http://en.wikipedia.org/wiki/INTERCAL
November 02, 2011
On 02.11.2011 09:38, Mehrdad wrote:
> On 11/1/2011 11:55 PM, Don wrote:
>> On 31.10.2011 02:21, Mehrdad wrote:
>>> I've written this piece of code a fair number of times:
>>>
>>> static if (is(typeof(foo()))) { foo(); }
>>> else { bar(); }
>>>
>>> When the expression inside the condition (i.e. the call to foo()) gets
>>> complicated, you get lots of code duplication and things become harder
>>> to read.
>>
>> IMHO the only problem is the is(typeof()) syntax.
>> Otherwise I don't see how this has any more code duplication than:
>>
>> if( foo(lots_of_parameters) )
>> foo(lots_of_parameters);
>> else bar();
> Huh?
>
> sorry but I'm confused as how that's related to static try/catch...

The only benefit you'd get from static try/catch is a small reduction in code duplication, in one specific idiom. I'm arguing that the code duplication is no worse in this case than in anything other case in the language. I'm not seeing why that particular idiom is so phenomenally important that it deserves its own syntax to obtain such a tiny benefit.
November 02, 2011
Le 02/11/2011 08:24, Don a écrit :
> On 02.11.2011 03:57, bcs wrote:
>> On 11/01/2011 10:04 AM, kenji hara wrote:
>>> --1;
>>>
>>> It you want to reduce duplication of long code, you can use string
>>> mixin.
>>> enum code = q{ ...long code... };
>>> static if (is(typeof({ mixin(code); })))
>>> {
>>> mixin(code);
>>> }
>>> else
>>> {
>>> ...
>>> }
>>>
>>
>> Please no! I've thought for years that string mixins are seriously
>> overused in D. IMnsHO they should only be used as a method of last
>> resort. For every case I've seen where there is a alternative to a
>> string mixin, the alternative was cleaner.
>>
>> If people don't like the static try/catch, how about: static try/else?
>
> Probably worth noting that in the latest release, you can instantiate a
> template from inside an is(typeof()), and if it fails to compile, the
> template instantiation will be discarded. (Prior to 2.056, if the
> template instantiation failed, compilation would fail).
>
> This means you can now factor out "does it compile?" tests into a
> template, to reduce code duplication.

This look like a cleaner solution.
November 03, 2011
On 11/02/2011 12:24 AM, Don wrote:
> On 02.11.2011 03:57, bcs wrote:
>> On 11/01/2011 10:04 AM, kenji hara wrote:
>>> --1;
>>>
>>> It you want to reduce duplication of long code, you can use string
>>> mixin.
>>> enum code = q{ ...long code... };
>>> static if (is(typeof({ mixin(code); })))
>>> {
>>> mixin(code);
>>> }
>>> else
>>> {
>>> ...
>>> }
>>>
>>
>> Please no! I've thought for years that string mixins are seriously
>> overused in D. IMnsHO they should only be used as a method of last
>> resort. For every case I've seen where there is a alternative to a
>> string mixin, the alternative was cleaner.
>>
>> If people don't like the static try/catch, how about: static try/else?
>
> Probably worth noting that in the latest release, you can instantiate a
> template from inside an is(typeof()), and if it fails to compile, the
> template instantiation will be discarded. (Prior to 2.056, if the
> template instantiation failed, compilation would fail).
>
> This means you can now factor out "does it compile?" tests into a
> template, to reduce code duplication.

That still has the (potential) issue of putting the code out-of-line.
1 2
Next ›   Last »