Fully dynamic d by opDotExp overloading
Nick Sabalausky
a at a.a
Fri Apr 17 23:19:09 PDT 2009
"Leandro Lucarella" <llucax at gmail.com> wrote in message
news:20090417231958.GB27625 at homero.springfield.home...
> Nick Sabalausky, el 17 de abril a las 16:48 me escribiste:
>> "Leandro Lucarella" <llucax at gmail.com> wrote in message
>> news:20090417191634.GA15139 at homero.springfield.home...
>> > Steven Schveighoffer, el 17 de abril a las 11:27 me escribiste:
>> >>
>> >> Sure, but what is the reason to need dynamic methods? I'm just trying
>> >> to
>> >> understand the usefulness of it.
>> >
>> > RPC is an example that comes into mind
>> >
>> > There is plenty of magic you can do with dynamic methods. Just try
>> > a dynamic language and see =)
>>
>> But is there any that can't be done with a dispatch function?
>
> You can write anything even with brainfuck. There are no discussion about
> what's possible and what's not, we are just talking about syntax. I hope
> the "it can be done" argument stop poping out because we all agree that
> it's possible to do everything right now. The question is *how* you can do
> it.
>
Please, please, please, let's not delve into the "everything can be done"
argument. It only holds for a limited domain (theoretical turing machines
and turing computable problems, ie theoretical computability), which this
discussion is already well outside of. You can't rewrite Firefox in
brainfuck in 3 hours. You can't write a worthwhile embedded OS entirely in
JavaScript. You can't write a gameboy app to compute the movements of all
the particles in the universe until the end of time and have it run to
completion in three seconds. You can't. You can't. You can't. Can't can't
can't can't can't. Of course there are things that can't be done.
Obviously we're all well aware that computability has nothing to do with
this discussion, so I really don't see why you've brought it up. As you
said, the question is how we compute whatever we're computing and how we
write the code to do so. And there absolutely are indeed certain how's under
certain conditions that *cannot* be done.
And you did say "There is plenty of magic you can do with dynamic methods",
right? You don't want me to misuse the "it's possible to do everything"
argument to respond "If there's plenty of magic you can do with dynamic
methods, and everything is possible, then I can do all the same magic
without anything dynamic", do you? So please, please, please, let's never,
ever, ever, ever, ever get into the "everything can be done" again unless we
really are entirely within the bounds of theoretical computability.
So now, let's try this again:
What is this usefulness you speak of that traditional dynamic methods and/or
opDotSrc dynamic methods have that is more useful than a dispatch method?
Or, were you already counting dispatch methods as a form of dynamic method?
>> Besides, as I see it, the opDotExp-style syntax for calling a dynamic
>> method
>> is more limited because unless you're using a scripting language, you
>> can't
>> do:
>>
>> auto foo = new Foo();
>> char[] func = /* Get from user input */;
>> foo.func(); // Call function the user specified
>
> So?
>
I was merely refuting your impliction (or maybe I misunderstood you?) that
opDotExp dynamic methods were more useful.
>> But you can do that with either a dispatch method or a reflection API
>> that
>> supports invokation.
>
> I think the reflection API is needed too, but that's another topic. Both
> would be great.
>
Ok, glad we at least agree on the need for the reflection stuff :)
More information about the Digitalmars-d
mailing list