On 2011-10-25 07:24, Robert Jacques wrote:
Aren't private methods by definition something people shouldn't be using?
Yes, that's what I mean. But sometimes it CAN be useful.
:) I don't know myself. I've just heard that the internals of Rails are
deep, dark and full of non-idiomatic Rudy code.
The parts that I've looked at from Rails are not that special.
On
the other hand it feels like I'm stretching D's metaprogramming
capabilities in my serialization library. That's just because D doesn't
have proper reflection.
I've written three serialization libraries and two versions of a runtime
reflection library; the first one was prior to the string bugs in CTFE
being fixed and ran DMD out of memory. I found serialization to be
simple and straight forward. And I found compiler bugs to be a greater
issue with reflection than any limits in D's capabilities. Indeed, given
I wrote the same library using two completely different mechanisms,
gives me great hope for D. So, I don't agree with your assessment, but I
do understand where you're coming from. A lot of D's metaprogramming
capabilities are undocumented, and knowing the right tool for the job is
essential to getting nice, clean code.
For example, getting the name of a instance variable:
T.tupleof[i].stringof[1 + T.stringof.length + 2 .. $];
I wouldn't consider that simple and straight forward. This works for
both D1 and D2, don't know if D2 has a better way.
Your serialization library only works on public fields? Doesn't sound
very useful.
(Just checking, but you do know D has static ctors.)
Yes.
Actually, you're not supposed to be able to; this is bug 1983.
http://d.puremagic.com/issues/show_bug.cgi?id=1983 and
https://github.com/D-Programming-Language/dmd/pull/71
I don't see what that has to do with private, it's about const, as far
as I can see. I don't see how calling a private method through a
delegate can be easily solved. I see three solutions:
1. Make it a compile time error to create a delegate from a private
method. This would not allow to call that method via a delegate in the
same module, which is possible if you call the method directly.
2. Implement some, most likely, very advanced data flow analysis in the
compiler to detect when a delegate pointing to a private method escapes
the module. Results in a compile time error. Will most likely not happen.
3. Make it a runtime error when the delegate is actually called. This
would probably need some pieces of 2 as well. I don't think the
community will be happy about adding runtime checks like these.
Oh, BTW the same needs to be done for function pointers as well since
you can build a delegate out of a function pointer and an object.
In Ruby an instance variable is always private. I don't think you can
declare a public instance variable, one uses setters/getters for that.
In D you can declare both private and public instance variables.
In Ruby you can get/set a value of an instance variable using
reflection, instance_variable_set/get.
In D you can get/set a value of a private instance variable using
compile time reflection, i.e. .tupleof.
Yes, but only for source code you control.
You don't need control of the source, you only need the static type. Of
course an opaque struct won't work.
Actually, baring bugs in DMD, .tupleof is the only way to access private
fields and there is _no way_ to access private members; And .tupleof
only works if you have access to the source code. Furthermore, .tupleof,
god-send that it is, isn't part of the D spec; unlike .stringof, it
didn't make it into TDPL nor into the D documentation. D's official
method of compile-time reflection is __traits. And __traits doesn't
bypass protection attributes. So precedence would be against
runtime-reflection having access to private members.
The compiler has .tupleof and it's mentioned in the spec at
d-programming-language.org: http://d-programming-language.org/struct.html
--
/Jacob Carlborg
