Re: tupleof for inherited classes.
I know you specifically asked for a way to do this without
templates, but this was my first thought on how to make it work
(and I confirmed it):
##
import std.stdio ,
std.traits ;
class Engine {
int publicField ;
void enumFields ( this Self ) ( bool heading = true ) {
auto self = cast( Self ) this;
if ( heading ) {
writeln( Engine prints: );
}
foreach( base ; BaseClassesTuple!Self ) {
static if ( is( base : Engine ) ) {
( cast( base ) self ).enumFields( false );
}
}
foreach( ref field ; self.tupleof ) {
writeln( '\t', field );
}
}
protected string protectedField = s ;
private bool privateField ;
}
class Some : Engine {
int oneMoreField = 11;
void enumFields2 () {
writeln( Some prints: );
foreach( field ; this.tupleof ) {
writeln( '\t', field );
}
}
protected string protectedField = o;
}
void main () {
auto objE = new Engine;
auto objS = new Some;
objE.enumFields();
objS.publicField = 4;
objS.enumFields();
objS.enumFields2();
( cast( Engine ) objS ).enumFields();
}
##
The downside is that the reference you invoke enumFields()
against must be of the lowest type to get all members, as that
last line demonstrates. Beyond this, I don't believe there is
any way for methods defined by Engine to see members of derived
classes. The first alternative I could think of, is to use NVI
(non-virtual interfaces).
##
import std.stdio ;
class Engine {
int publicField ;
final void enumFields () {
writeln( this.classinfo.name, prints: );
enumFieldsImpl();
}
protected string protectedField = s ;
protected void enumFieldsImpl () {
foreach ( field ; this.tupleof ) {
writeln( '\t', field );
}
}
private bool privateField ;
}
class Some : Engine {
int oneMoreField = 11;
protected override void enumFieldsImpl () {
super.enumFieldsImpl();
foreach ( field ; this.tupleof ) {
writeln( '\t', field );
}
}
protected string protectedField = o;
}
void main () {
auto objE = new Engine;
auto objS = new Some;
objE.enumFields();
objS.publicField = 4;
objS.enumFields();
( cast( Engine ) objS ).enumFields();
}
##
This works even in the last (previously degenerate) case, however
it naturally results in code duplication. Depending on what your
real scenario is, however, that may not be a severe issue.
-- Chris NS
Re: Optional extra return value? Multiple return values with auto?
On Tuesday, 24 July 2012 at 03:25:55 UTC, ReneSac wrote:
Do I really have to duplicate the function, in order to achieve
this?
In a nutshell, yes. Or else resort to bizarre sorcery such as
may rot the very heart from one's chest (or template ninjitsu,
whatever). But is it really so bad?
bool foo ( byte[] data, out int stats ) {
// do a bunch of stuff
}
bool foo ( byte[] data ) {
int dummy;
return foo( data, dummy );
}
One could possibly put together a template that automates this...
heck, here's a quick and dirty implementation of such:
##
import std.stdio ,
std.traits ;
template DummyLast ( alias Func ) {
ReturnType!Func DummyLast ( ParameterTypeTuple!Func[ 0 .. $ -
1 ] args ) {
ParameterTypeTuple!Func[ $ - 1 ] dummy;
return Func( args, dummy );
}
}
bool foo ( byte[] data, out int stats ) {
stats = 42;
return true;
}
alias DummyLast!foo foo;
void main () {
byte[] data;
bool result;
int stats;
result = foo( data, stats );
writeln( result, ' ', stats );
result = false;
stats = 0;
result = foo( data );
writeln( result, ' ', stats );
}
##
-- Chris NS
Re: Optional extra return value? Multiple return values with auto?
On Tuesday, 24 July 2012 at 08:56:21 UTC, David wrote:
Am 24.07.2012 05:25, schrieb ReneSac:
I whish there was:
auto foo() {
return Tuple!(foo, bar, 1, new Custum());
}
void main() {
auto (s1, s2, i, c) = foo();
}
I think the main blocker to something like that right now is the
compiler's ability to detect and guarantee that the returned
tuple will always be a specific series of types (or at least
implicitly convertible to a common series). And in order for
that, tuples would, I imagine, need to be a part of the language
proper. If I'm wrong about that last requirement, then I'm
honestly not sure what the main obstacle to this is.
-- Chris NS
Re: Tid is not a process id?
Not sure yet what your exactly issue is, but have you tried to reproduce it using register/lookup?
Compile-Time module info
Is there any means to get meaningful moduleinfo at compile time,
specifically a list of the local classes of a given module?
__traits(allMembers, mod) doesn't work: inverse.d(109): Error:
import data has no members.
I was hoping that something along these lines would be possible
in CTFE:
foreach ( decl ; __traits( allMembers, data ) ) {
if ( is( typeof( mixin( decl ) ) == class )
!__traits( isAbstractclass, mixin( decl ) ) ) {
// ...some code in here...
}
}
-- Chris NS
Re: Is this actually supposed to be legal?
It is indeed supposed to work, and was actually touted as a common and lauded example way back in the day. However, with the advent of this-params for templates it seems less useful now (once they've been through the ringer a little more at least). I did use this-params to great effect in Zeal, to auto-inject behavior into subclasses with the proper scoping and other concerns. The base class didn't even have to be a template itself (just the magical internals). https://github.com/csauls/zeal.d/blob/master/source/zeal/base/controller.d So, to repeat, yes it is supposed to work... but I'm not so sure it is such a good idea anymore -- assuming this-params will work on the class declaration. -- Chris NS
Re: ufcs and integer params
Having been around long enough to remember when the ability to call foo() as foo first appeared, I feel it necessary to point out that this was *not* in fact a deliberate design, but rather a sort of accident that arose out of D's first attempt at properties. It was the same accident loaded compiler release that gave us pseudo-members -- the precursors to UFCS. The community discovered that these things were accepted by the compiler -- which was actually against the language spec at the time -- and further that the resulting code did the intuitively correct thing. Response to the accidents being generally positive, it was decided to work toward making them legitimate language features. Some flavor of @property (or of a certain other proposal which was a mimicry of C# properties... I was in that camp) has been in the plan ever since. I find the ongoing debate/discussion of @property and -property to be... well, moot. But hey, I'm just one crazy among an army of crazies. -- Chris NS
Re: ufcs and integer params
On Monday, 16 July 2012 at 23:13:54 UTC, Timon Gehr wrote: On 07/16/2012 10:55 AM, Chris NS wrote: Having been around long enough to remember when the ability to call foo() as foo first appeared, I feel it necessary to point out that this was *not* in fact a deliberate design, but rather a sort of accident that arose out of D's first attempt at properties. Afaik this first attempt was implemented roughly as designed. It is my understanding that @property was added later in order to fix the introduced ambiguities. Effectively yes, this is why I put accident in quotes. The accidental part was that it was inadvertently extended to functions that it should not have been. Free functions, for example, were not really supposed to be callable in that way... it has turned out to sometimes be a nice and useful thing, of course, but it wasn't exactly the goal at the time. The goal was simply class/struct/union member functions that could be swapped out for exposed fields, or vice versa, without any change in user code. It was the same accident loaded compiler release that gave us pseudo-members -- the precursors to UFCS. I still wonder how that could possibly happen. You, me, and everyone else. I recall even Walter being a bit surprised by it and reviewing his code afterward. The oddity was identified, but at the same time (almost-) everyone rather liked it and it stuck. At the time I was maintaining an extensive library of array extensions, a spiritual ancestor to today's std.algorithm and std.range. (None of that code is in Phobos, mind you, but it served a similar purpose.) It was sort of like finding a peppermint in an old coat pocket. The community discovered that these things were accepted by the compiler -- which was actually against the language spec at the time -- and further that the resulting code did the intuitively correct thing. Response to the accidents being generally positive, it was decided to work toward making them legitimate language features. Some flavor of @property (or of a certain other proposal which was a mimicry of C# properties... I was in that camp) That would certainly be more pretty -- OTOH it is hard to think of a way to extend this to UFCS that is as natural as what happens if everything is conflated in functions. As I recall, that was essentially how the discussion went back then, too. I still like the C# style, personally, but I've found @property to be plenty usable, and even admittedly a bet more terse. has been in the plan ever since. I find the ongoing debate/discussion of @property and -property to be... well, moot. But hey, I'm just one crazy among an army of crazies. Well, this newsgroup has the property that the stuff that is actually important is usually unilaterally agreed upon rather quickly. :o) Yeah... usually. ;) I rarely speak up anymore, since I just don't have the time to commit to proving concepts and whatnot anymore. I'm old, Dean. So very old. I remember proposing a foreach statement (opApply was Walter's idea, though). I also remember the horror that was the 'instance' keyword... man do I ever love that beautiful !() operator now, no matter what anyone else says about it. Ultimately, I am quite satisfied with it all, even if the occasional dead horse takes a beating. I just find it strange that there's such heated debate over something that had seemed so settled. Which, I suppose, might just be an indicator that it isn't settled after all, eh? -- Chris NS
Re: immutability and constness
On Thursday, 12 July 2012 at 00:37:22 UTC, H. S. Teoh wrote: On Thu, Jul 12, 2012 at 02:14:30AM +0200, Minas Mina wrote: [...] ** wall o' text ** You forgot about their quantum uncertainty loving transvestite cousin: inout.
