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: Just where has this language gone wrong?
On Tuesday, 24 July 2012 at 02:51:44 UTC, H. S. Teoh wrote: Reminds of a certain individual who shall remain unnamed, with whom I argued about why he should *not* implement IPv6 prefix checking by converting the address and prefixes to strings and then using strncmp()... Truly boggles the mind. I'm reminded of a close friend of mine... once he was asked to review some code, after the sole author had spent a few weeks on it. I was lucky (?) enough to be in the room to hear him actually say: That's... cute. Not *wise* but cute. Do you remember what functions are? I don't recall there being a response. -- Chris NS
Re: feature request: with(var decl) {}
I can't help thinking it sounds rather like a job for... named
parameters. Just imagine it:
##
void foo ( bool closeButton = true, int width = 600 ) {
writeln( closeButton, , , width );
}
void main () {
foo( closeButton: false );
}
##
With output:
false, 600
Gosh, that'd sure be swell. (Either that or find a way to sanely
allow non-static struct initializers, at least for rvalue
arguments.)
-- Chris NS
Re: feature request: with(var decl) {}
On Tuesday, 24 July 2012 at 23:03:39 UTC, Adam D. Ruppe wrote: On Tuesday, 24 July 2012 at 07:03:05 UTC, Chris NS wrote: I can't help thinking it sounds rather like a job for... named parameters. Just imagine it: Yeah, that could do it too, but named parameters have been brought up a few times too and there's opposition to it. I kinda prefer the struct to named params anyway because you can store it for later too. But I could go either way. Oh I know; which is why I wrote in a slightly snarky manner. I still hold out hope. Your reuse argument for structs is, of course, completely valid and compelling. Another possibility, in cases like that presented in the original post, is to write a single struct to be used with all the relevant functions -- but then there's the problem of memory abuse. In some cases it may be fine, but tossing around several copies of a very large struct, and only using two or three of the fields in a given case, is just unreasonable. -- Chris NS
Re: Just where has this language gone wrong?
On Tuesday, 24 July 2012 at 22:38:07 UTC, Era Scarecrow wrote:
[code]
//remember, java
String toGuid(byte input[16]) {
String ID = {;
if (Integer.toHexString(input[5]).length 2)
ID = ID + 0;
ID = ID + Integer.toHexString(input[5]);
if (Integer.toHexString(input[6]).length 2)
ID = ID + 0;
ID = ID + Integer.toHexString(input[6]);
//repeat for other 14 bytes, plus adding dashes and ending brace
return ID;
}
[/code]
I just died a little inside...
If not for Andrei's little joke, I don't know what I might have
done.
Erm, so that I'm not completely off-topic: I know where D has
truly gone wrong. There's just too many damn semi-colons!
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?
Re: of Conditional Implementation vs Assertive Input Validation
It certainly makes sense. Maybe the long term solution would be
a way to embed those assertions in the conditions, but in the
meantime the proposal would alleviate the error message issue. I
know I've often enough stared long and hard at a volume of
template instantiation errors waiting for the real mistake to
jump out at me.
--
And for the curious, what I mean by embedding assertions in the
conditions is quite literally what it sounds like:
Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!Range, minPos cannot operate on infinite
ranges. )
{
...
}
In which case the compiler would merge the condition expressions
of the assertions into the if-condition, and remember the message
strings associated with them.
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: D versionning
On Tuesday, 17 July 2012 at 18:12:28 UTC, Iain Buclaw wrote: On 17 July 2012 12:05, Wouter Verhelst wou...@grep.be wrote: Chris NS ibisbase...@gmail.com writes: +1 for a 2.breaking.bugfix scheme. I've used this scheme on anything serious for years, and know many others who have; so it is not only popular but also quite tried and proven. Not for every project, of course (although I don't understand why the Linux kernel team dropped it with 3.x), but for the majority it seems to work wonders. They haven't, on the contrary. 3.x is a release with new features 3.x.y is a bugfix release. Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was confusing, because many people thought there was going to be a 2.8 at some point when there wasn't. The reason for the move to 3.x is in the announcement. http://lkml.org/lkml/2011/7/21/455 But yes, it simplifies the stable vs development kernel versioning. I don't recall where I first got my information, but clearly I was mistaken. And I'm happy to have been so. Maybe if I actually kept up more with the info on kernel releases I'd have known... alas. -- Chris NS
Re: D versionning
On Tuesday, 17 July 2012 at 06:29:46 UTC, Jacob Carlborg wrote: On 2012-07-16 23:36, SomeDude wrote: It's *not* textual search and replace. It's compiler checked semantic refactoring. Yet again we need a compiler as a library :) I find myself agreeing more and more.
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: D versionning
+1 for a 2.breaking.bugfix scheme. I've used this scheme on anything serious for years, and know many others who have; so it is not only popular but also quite tried and proven. Not for every project, of course (although I don't understand why the Linux kernel team dropped it with 3.x), but for the majority it seems to work wonders. Rest of the thread seems like so much unnecessary politic.
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: All right, all right! Interim decision regarding qualified Object methods
I say: finally. I've long felt that Object was already too heavy, but hadn't worried about it much in years (since there was no apparent solution at that time). Just as notifyRegister/notifyUnRegister were eventually moved out to the runtime, it should be possible to do the same for these, if we cannot just obviate them outright.
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.
Re: JPG and PNG decoder
I second the request for a PNG encoder. You just saved me a lot of trouble, as I was about to implement my own PNG loader... and now I don't have to. ^_^ I'll glance over your code in full sometime and see if I notice any readily apparent improvements.
Re: JPG and PNG decoder
On Sunday, 17 June 2012 at 20:10:28 UTC, cal wrote: though I have worlds of trouble with const-ness, I will endeavour to add those guarantees :) What I usually do, unless it's just an obvious case, is write code without concern for const-ness, then write a thorough test and step through one function/whatever at a time and apply const/inout/pure/nothrow/etc, do any apparent refactoring, and check the test. Writing the test helps me grok as many imaginable cases as possible, and doing it incrementally avoids massive error cascades from the compiler.
Re: Introducing vibe.d! SOAP .. REST?
I've been playing around with vibe in my free time the last few days, and here are the beginnings of a stab at REST: https://github.com/csauls/zeal.d/blob/master/source/zeal/http/router.d Admittedly it rips off the Rails way of recognizing and pathing the REST actions, but I admit a small bias as someone who uses Rails often. That said, I've been trying to dream up a more D-like way to do it.
Re: DIP16: Transparently substitute module with package
On Saturday, 31 March 2012 at 06:39:07 UTC, Nick Sabalausky wrote: Chris NS ibisbase...@gmail.com wrote in message news:ugopmohijjcnnrchu...@forum.dlang.org... I'm pretty impressed with the idea, and look forward to its implementation, but I do have one question. How does this affect (if at all) the implicit friend relationship of declarations? Since package foo.bar is treated as a single module, do the classes in foo/bar/alpha.d and foo/bar/beta.d have access to each other's private members? I'm not sure whether I favor them losing or keeping their friend status. There's always the package access specifier. True, though it bears revisiting in its own right. I've never been completely satisfied with the horizontal visibility, and would have preferred 'package' be defined as visible within current package, *and subpackages* of the current. But now I'm getting a bit off-topic.
Re: DIP16: Transparently substitute module with package
I'm pretty impressed with the idea, and look forward to its implementation, but I do have one question. How does this affect (if at all) the implicit friend relationship of declarations? Since package foo.bar is treated as a single module, do the classes in foo/bar/alpha.d and foo/bar/beta.d have access to each other's private members? I'm not sure whether I favor them losing or keeping their friend status. -- Chris NS
Re: Poll of the week - How long have you been in the D world?
On Friday, 30 March 2012 at 22:28:40 UTC, H. S. Teoh wrote: On Fri, Mar 30, 2012 at 11:17:47PM +0100, Stewart Gordon wrote: On 26/03/2012 02:18, dnewbie wrote: Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f I see that the numbers are almost evenly balanced between the four categories. But does this really mean that we've attracted more people in the last two years than in all earlier years combined, or that an awful lot of old-timers have left? [...] That would be cause of great concern. Are the D1 people still around? T Some of us are -- though I don't know how many are actually still D1 people per se... I'd say most have made the jump by now. What I feel from the numbers is simply that we have a mostly steady rate of community growth.
