On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
> On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today.

I use a *lot* of import() (one of my work projects imports()
about 140 files!) but I fairly rarely use mixin with it.

What I love about it is simply having a one-piece
executable. All your default data is right there. Deployment
is easy. If replacement files exist at runtime, you might
use them, but if not, you always have a default built in!


It is much easier than external resource files, and being
able to process is a nice win.

> On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
>> On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today.

Definitely.... mixin imports and ctfe gets my 3 votes!

On Wednesday, 21 March 2012 at 19:11:08 UTC, Nick Sabalausky wrote:
> Although, while it wasn't a major selling point in and of itself, the ability to put underscores in numeric literals

Aye, that's a nice touch.

> Heh, really?

Oh yes, I was a staunch defender of C++ for a while.

"garbage collection? gah apparently you don't know how to
use RAII"

"header files? more like good thing, it's called a clean
interface"


BTW one thing I do kinda like is how you can group member
functions however you want in C++. For example, in the dmd
source, you have special features in separate files, with
all the functions still virtual from the header.

void InvariantDeclaration::toJsonBuffer(OutBuffer *buf)  { }
void DtorDeclaration::toJsonBuffer(OutBuffer *buf)       { }
void StaticCtorDeclaration::toJsonBuffer(OutBuffer *buf) { }

etc.


That's actually pretty cool. I like that kind of organization.




But, eh, D pwns C++ in so many ways that while I still
like C++, I'm no longer in the camp of "c++ is obviously
great and totally sufficient and if you don't see it,
you must be some kind of idiot" like I was for a while.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:vuegxcpcbsefvmjdqesp@forum.dlang.org...
> On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
>> On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today.
>
> I use a *lot* of import() (one of my work projects imports()
> about 140 files!) but I fairly rarely use mixin with it.
>
> What I love about it is simply having a one-piece executable. All your default data is right there. Deployment is easy. If replacement files exist at runtime, you might use them, but if not, you always have a default built in!
>
>
> It is much easier than external resource files, and being able to process is a nice win.

Yea. It especially would have been great back when I was doing GBA homebrew. With that stuff having been in C/C++, just to include *any* real binary data, we had to use external tools (as a pre-compilation build step) to convert the binary data files into C files that contained "char myData[] = [0x01, 0x5B, 0xFF, 0x80, ...];" (or something like that - my C muscles have atrophied). And then later on someone made sort of a mini file-system where you could add data to a ROM image and then query/access it from your code in the ROM.

If we had been doing things in D, we could all have just typed import("myData.dat") and been *done*. None of those extra tools or MIME-like-bloating^H^H^H^H^H^H^H^Hencoding bullshit.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:utkgtgcgguydxrabkily@forum.dlang.org...
>
> But, eh, D pwns C++ in so many ways that while I still
> like C++, I'm no longer in the camp of "c++ is obviously
> great and totally sufficient and if you don't see it,
> you must be some kind of idiot" like I was for a while.

Heh, yea. I think in a way that's kind of the problem with C++: It can be technically considered "sufficient"...but that's it - it's *merely* sufficient. "Why have a Pop-Tart(tm) when you can have a warm delicious Pillsbury(tm) Toaster Strudel(tm)?" ;)

On Thursday, 22 March 2012 at 04:49:24 UTC, Nick Sabalausky wrote:
> And then later on someone made sort of a mini file-system where you could add data to a ROM
> image and then query/access it from your code

Now, this reminds me, what if you want to access the
compile time files from runtime?

For instance, one of my projects lets you include other
files in the html. (Something I actually don't like, but
it is an easy crutch.)

You can also replace these at runtime, so the other team
members can change stuff without access to the compiler.

Here's what I ended up writing:


// filesystem alternatives...
string getFile(string name)() {
    if(std.file.exists(dir ~ name))
        return std.file.readText(dir ~ name);
    else
        return import(name);
}

// runtime fetching
string getIncludeFile(string name) {
	enum manifest = ["file1.html", "file2.html", ......];
	string manifests() {
		string cases;
		foreach(f; manifest)
			cases ~= "case \""~f~"\": return getFile!(\""~f~"\");";
		return cases;
	}
	switch(name) {
		default: assert(0, name);
		mixin(manifests());
	}
}



I'm a bit disappointed that I needed a list of files duplicated
there. With import(), if it is in the import directory, it just
works, but then the name must be known at compile time.


This is the best I have so far... and i like it,
but it isn't quite ideal yet.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:oyqxvngsgjfmrlrwhohf@forum.dlang.org...
> On Thursday, 22 March 2012 at 04:49:24 UTC, Nick Sabalausky wrote:
>> And then later on someone made sort of a mini file-system where you could
>> add data to a ROM
>> image and then query/access it from your code
>
> Now, this reminds me, what if you want to access the compile time files from runtime?
>
> For instance, one of my projects lets you include other
> files in the html. (Something I actually don't like, but
> it is an easy crutch.)
>
> You can also replace these at runtime, so the other team members can change stuff without access to the compiler.
>
> Here's what I ended up writing:
>
>
> // filesystem alternatives...
> string getFile(string name)() {
>     if(std.file.exists(dir ~ name))
>         return std.file.readText(dir ~ name);
>     else
>         return import(name);
> }
>
> // runtime fetching
> string getIncludeFile(string name) {
> enum manifest = ["file1.html", "file2.html", ......];
> string manifests() {
> string cases;
> foreach(f; manifest)
> cases ~= "case \""~f~"\": return getFile!(\""~f~"\");";
> return cases;
> }
> switch(name) {
> default: assert(0, name);
> mixin(manifests());
> }
> }
>
>
>
> I'm a bit disappointed that I needed a list of files duplicated there. With import(), if it is in the import directory, it just works, but then the name must be known at compile time.
>
>
> This is the best I have so far... and i like it,
> but it isn't quite ideal yet.

Clever idea, I like it.

On Wednesday, 21 March 2012 at 19:11:08 UTC, Nick Sabalausky wrote:

> Although, while it wasn't a major selling point in and of itself, the
> ability to put underscores in numeric literals *really* helped tell me, "Now
> *this* is a language that's very well thought out and values pragmatism."
> And *that* was the other main thing about D that grabbed me.

I take that feature for granted! Try using it in other languages and am always taken back on what it is complaining about, its just a stupid integer literal... oh.

On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu wrote:
> I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches.
>
> What are your faves? I have a few in mind, but wouldn't want to influence answers.
>
>
> Thanks,
>
> Andrei

It isn't mainline yet, but UFCS from git has made working with std.algorithm much nicer. Instead of something like array(filter!"a > 0"(map!((a){return somefunc(a);})(data))) where you can quickly drown in parenthesis and the order seems somewhat backwards, you can use data.map!((a){return somefunc(a);}).filter!"a > 0".array

Matt Peterson:

> It isn't mainline yet, but UFCS from git has made working with std.algorithm much nicer. Instead of something like array(filter!"a > 0"(map!((a){return somefunc(a);})(data))) where you can quickly drown in parenthesis and the order seems somewhat backwards, you can use data.map!((a){return somefunc(a);}).filter!"a > 0".array

I suggest to compile all your D2 code with -wi (or -w) and -property.

And one bug of UFCS will be probably fixed by Hara (http://d.puremagic.com/issues/show_bug.cgi?id=7722 ), so map and filter will require an ending () (I have closed my http://d.puremagic.com/issues/show_bug.cgi?id=7723 ).

So your last line is better written like this:

data.map!somefunc().filter!q{a > 0}().array()

This is indeed a significant improvement in D syntax for functional-style code, because this reduced nesting a lot, making such code significantly more readable.

Bye,
bearophile