View mode: basic / threaded / horizontal-split · Log in · Help
May 18, 2009
Re: The Final(ize) Challenge
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:34 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> I think you need to operate exclusively with string mixins in Finalize, so
>> __ident would be of marginal help there. Also, static foreach is much more
>> necessary.
> 
> I have used string mixins extensively in my own code, not just in this
> one example.

Then implement Finalize. Too much foreplay.

Andrei
May 18, 2009
Re: The Final(ize) Challenge
On Mon, May 18, 2009 at 2:48 PM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:

>
> Then implement Finalize. Too much foreplay.

I thought it was already established that it's currently impossible.
Ctors?  Ref/out params?  Hello?
May 18, 2009
Re: The Final(ize) Challenge
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Ok, now with the advent (or rediscovery) of allMembers which I had no idea
>> existed, we're ready to start some serious butt-kick reflection facilities.
>>
>> For starters, I'd like to present you with the following challenge. Given
>> any class C, e.g.:
>>
>> class C
>> {
>>    void foo(int) { ... }
>>    int bar(string) { ... }
>> }
>>
>> define a template class Finalize(T) such that Finalize!(C) is the same as
>> the following hand-written class:
>>
>> final class FinalizeC : C
>> {
>>    final void foo(int a) { return super.foo(a); }
>>    final int bar(string a) { return super.bar(a); }
>> }
>>
>> Finalize is cool when you need some functionality from an exact class and
>> you don't want to pay indirect calls throughout. All calls through
>> Finalize!(C)'s methods will resolve to static calls.
> 
> There are two challenging aspects that I'm running into.
> 
> The first is a more general statement about trying to generate
> functions with D's metaprogramming.  It is a huge pain in the ass to
> actually create a function with a given name, because the only way
> that I know this can be done is with a string mixin.  As soon as we
> venture into that territory, we have to consider things like how to
> convert a parameter type tuple into a string, and whether or not the
> .stringof a type will be correctly qualified (I've run into problems
> with this before, where some code in a library is not able to mix in a
> string because it doesn't import the same modules that the calling
> code does, and then you just get undefined identifier errors).  For
> the love of all that is holy, can we PLEASE get something like
> __ident("blah")?  This would be so much easier and would probably
> drastically reduce my use of string mixins in general.

Better __traits(ident, "blah")?
May 18, 2009
Re: The Final(ize) Challenge
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:48 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Then implement Finalize. Too much foreplay.
> 
> I thought it was already established that it's currently impossible.
> Ctors?  Ref/out params?  Hello?

I just showed you how to do ctors. I know how to do ref but why don't 
you do your due diligence. I don't think "out" is doable. Implement what 
you can and bugzillize what you can't.

Andrei
May 18, 2009
Re: The Final(ize) Challenge
Andrei Alexandrescu wrote:
> I don't think "out" is doable.

I take that back. It is doable. The code below prints "void function(out 
int _param_0)":

struct S
{
    void blah(out int) {}
}

void main()
{
    writeln(typeof(&S.blah).stringof);
}


Andrei
May 18, 2009
Re: The Final(ize) Challenge
On Mon, May 18, 2009 at 2:55 PM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:

> I just showed you how to do ctors.

No, you showed me how ctors would be done if I had a
correctly-functioning compiler.  Which I don't.

> I know how to do ref but why don't you do
> your due diligence.

My "due dilligence"?  I wasn't aware that I was under contract!
May 18, 2009
Re: The Final(ize) Challenge
On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
> Andrei Alexandrescu wrote:
>>
>> I don't think "out" is doable.
>
> I take that back. It is doable. The code below prints "void function(out int
> _param_0)":
>
> struct S
> {
>    void blah(out int) {}
> }
>
> void main()
> {
>    writeln(typeof(&S.blah).stringof);
> }

Wonderful, I can extract information about parameters through a
completely undocumented mechanism.  What guarantee do I have that this
will work with another frontend or version of DMD?
May 18, 2009
Re: The Final(ize) Challenge
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:55 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> I just showed you how to do ctors.
> 
> No, you showed me how ctors would be done if I had a
> correctly-functioning compiler.  Which I don't.

I'm not seeing the bugzilla you submitted.

>> I know how to do ref but why don't you do
>> your due diligence.
> 
> My "due dilligence"?  I wasn't aware that I was under contract!

Your whining is contract-binding.


Andrei
May 18, 2009
Re: The Final(ize) Challenge
Jarrett Billingsley wrote:
> On Mon, May 18, 2009 at 2:57 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Andrei Alexandrescu wrote:
>>> I don't think "out" is doable.
>> I take that back. It is doable. The code below prints "void function(out int
>> _param_0)":
>>
>> struct S
>> {
>>    void blah(out int) {}
>> }
>>
>> void main()
>> {
>>    writeln(typeof(&S.blah).stringof);
>> }
> 
> Wonderful, I can extract information about parameters through a
> completely undocumented mechanism.  What guarantee do I have that this
> will work with another frontend or version of DMD?

Submit a bug report asking for documentation. You'd be able to whine to 
an eskimo that there's too much snow on your sidewalk.

Andrei
May 18, 2009
Re: The Final(ize) Challenge
On Mon, 18 May 2009 14:37:51 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> Back to your idea...
>>  This feature that you suggest seems very trivial for the compiler to  
>> implement, while extremely hard to do it via reflection.
>
> The problem is, there are a million things that are trivial for the  
> compiler to implement and harder with libraries. But that approach just  
> doesn't scale. Finalize is only the beginning and pretty much a working  
> example to flesh out library primitives. Don't get bogged down by it.

Sure, there's a library solution.  But what I'm saying is, it coincides  
with a different problem, where both can be solved by adding some  
intuitive syntax.

Without adding the cruft of a dispatch function, D can provide an  
intuitive way to specify the layout of the vtable.  And that would make  
your problem easier to solve.  Not only that, the performance of simply  
copying the function in the vtable is impossible to achieve through a  
library solution.

-Steve
1 2 3 4 5 6
Top | Discussion index | About this forum | D home