On 11/01/2013 08:32 AM, Dmitry Olshansky wrote:

> In short we have 2 ways:
> 1) Ranges
> 2) opApply

As another shameless plug, those foreach methods are included in this chapter:

  http://ddili.org/ders/d.en/foreach_opapply.html

Ali

On Friday, November 01, 2013 19:32:35 Dmitry Olshansky wrote:
> 01-Nov-2013 16:43, John Colvin пишет:
> > On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:
> >> 2) opSlice
> >> 3) alias this
> > 
> > arguably these are the same in the context of the foreach loop. Both just provide direct access to the underlying array.
> 
> No quite. I'd say alias this is frankly a bad idea to provide iteration. In any case returning naked underlying array is most surely short-sighted.

Pretty much anytime that you're tempted to use alias this, you should reconsider. It _does_ have its uses, but implicit conversions tend to cause a lot problems - especially in generic code. And in this case, you can simply declare opSlice to return the underlying array, so there isn't really any benefit to using alias this other than the fact that it saves you a few characters (which isn't even vaguely worth the cost IMHO).

> In short we have 2 ways:
> 1) Ranges
> 2) opApply
> 
> And a couple of extra things on _top_ of that to keep in mind:
> 1) Implicit conversion -> hence alias this to a range/opApply type works
> 2) opSlice is called on foreach aggregate if it's not a range or doesn't
> have opApply by itself.

Yeah. Any user-defined type that's iterable via foreach uses either the range API or opApply. And in general, unless the range API isn't going to work for you, it's recommended to use the range API rather than opApply. opSlice comes into play when you want to iterate over something as a range without consuming it. The most common place to see opSlice would likely be on containers.

- Jonathan M Davis

Ali:

> As another shameless plug, those foreach methods are included in this
chapter:
> http://ddili.org/ders/d.en/foreach_opapply.htm<http://ddili.org/ders/d.en/foreach_opapply.html>

OMG. I just grokked opApply.

*epiphany moment*

Thanks a lot, Ali! I tried to get it for *years*!

On 11/01/2013 02:28 PM, Philippe Sigaud wrote:
> Ali:
>
>> As another shameless plug, those foreach methods are included in this
> chapter:
>> http://ddili.org/ders/d.en/foreach_opapply.htm<http://ddili.org/ders/d.en/foreach_opapply.html>
>
> OMG. I just grokked opApply.
>
> *epiphany moment*
>
> Thanks a lot, Ali! I tried to get it for *years*!
>

You made my day! :) I can't believe that the king of D templates learned something from my little chapter:

  https://github.com/PhilippeSigaud/D-templates-tutorial

Ali

On Fri, Nov 1, 2013 at 11:15 PM, Ali Çehreli <acehreli@yahoo.com> wrote:

>
>> You made my day! :) I can't believe that the king of D templates learned
> something from my little chapter:
>
>   https://github.com/**PhilippeSigaud/D-templates-**tutorial<https://github.com/PhilippeSigaud/D-templates-tutorial>
>
> ;-) You're too kind. I should dust this text somewhat.

My understanding of D templates is now years behind the compiler (see the
new `alias Name(T) = ...` syntax in 2.064. That's cool).

Anyway, back to opApply. I should write something using it before I forget how to use it :)

What did you use to generate your website, btw?

On 11/01/2013 03:51 PM, Philippe Sigaud wrote:

> What did you use to generate your website, btw?

It is a completely static web site (except the Google translate widget) that is produced by ddoc and a couple of Makefiles. The following is the Turkish readme file:

  https://code.google.com/p/ddili/source/browse/trunk/BENIOKU

The tools required for the site are just dmd and GNU make. The free pdf generator prince is used for the pdf versions of the books.

I just do

  make test

to produce the light-weight versions of the pages during development and

  make

to produce a single tar file to upload to the provider.

Ali

On Sat, Nov 2, 2013 at 12:08 AM, Ali Çehreli <acehreli@yahoo.com> wrote:

> On 11/01/2013 03:51 PM, Philippe Sigaud wrote:
>
> > What did you use to generate your website, btw?
>
> It is a completely static web site (except the Google translate widget) that is produced by ddoc and a couple of Makefiles.



This is something I'm looking for!



> The following is the Turkish readme file:
>
>   https://code.google.com/p/**ddili/source/browse/trunk/**BENIOKU<https://code.google.com/p/ddili/source/browse/trunk/BENIOKU>
>
> The tools required for the site are just dmd and GNU make. The free pdf generator prince is used for the pdf versions of the books.
>
> I just do
>
>   make test
>
> to produce the light-weight versions of the pages during development and
>
>   make
>
> to produce a single tar file to upload to the provider.


OK, that seems quite similar to what I want. Any limitation you hit with Ddoc?

Where can I get a view of the internal .ddoc file you used for the macro definitions? I found the source docs for your book text, but not the one containing definitions.

I'm planning to write a new text on D, and though I'm enamoured of Markdown, I'm willing to give Ddoc a chance, since Andrei pushes its usage.

I see three limitations:

- almost no one knows Ddoc. Markdown is simple and used by the entire
planet.
- no possibility to inject equations with Ddoc?
- no possibility to put images? (I may be wrong on this one).

The equation requirement might seem strange, but I'd like to write a ray-tracing tutorial in D, and ray-tracing 'theory' uses a lot of maths. Many markdown parser know LaTeX or MathML. Mayby with MathML and invoking HTML code inside Ddoc?

 Oh, and if you could find the time to translate the turkish page, that
would be great!

I will respond later with more information. Here is just the quick ones. :)

On 11/02/2013 01:34 AM, Philippe Sigaud wrote:

> Where can I get a view of the internal .ddoc file you used for the macro
> definitions?

They are the ones that end with .ddoc here:

  https://code.google.com/p/ddili/source/browse/trunk/#trunk%2Fsrc

and additionally in each book directory, e.g.:


https://code.google.com/p/ddili/source/browse/trunk/#trunk%2Fsrc%2Fders%2Fd.en

(Beware that there is some "technical debt" there. ;) )

Some ddoc files are auto generated by scripts such as this one:


https://code.google.com/p/ddili/source/browse/trunk/src/make_ders_macros.sh

That one deals with the Prev and Next links to point at the neighboring pages.

> - no possibility to inject equations with Ddoc?

I don't know anything about that. :(

> - no possibility to put images? (I may be wrong on this one).

By the IMG macro for img links like this one uses:


https://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/pdf_indir.d#10

>   Oh, and if you could find the time to translate the turkish page, that
> would be great!

To be continued... :)

Ali

Am Fri, 01 Nov 2013 08:50:19 -0700
schrieb Ali Çehreli <acehreli@yahoo.com>:

> On 11/01/2013 08:32 AM, Dmitry Olshansky wrote:
> 
> > In short we have 2 ways:
> > 1) Ranges
> > 2) opApply
> 
> As another shameless plug, those foreach methods are included in this chapter:
> 
>    http://ddili.org/ders/d.en/foreach_opapply.html
> 
> Ali
> 

I just saw a small mistake on that page:

".popFront() must move to the element that is one before the end (skips
the back element)"

popFront should be popBack.

On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:
> On Friday, 1 November 2013 at 11:41:52 UTC, Jonathan M Davis wrote:
>> On Friday, November 01, 2013 12:30:10 Gary Willoughby wrote:
>>> I have a class which contains an array as a core collection of
>>> data. I want to pass an instance of this class to a foreach loop
>>> and iterate through the enclosed array. How do i do this? I've
>>> asked this before and got an answer but i can't find anything now.
>>
>> In general, if you want to make something work with foreach, you either make
>> it a range, or you give it an opSlice which returns a range (another
>> alternative would be define opApply, but in general, code should be using the
>> range primitives rather than opApply). Given that you're looking to iterate an
>> array, and you presumably don't want the array to be consumed when iterating,
>> the simplest would be to simply declare an opSlice on the class returns the
>> array. e.g.
>>
>> class C
>> {
>>    int[] foo;
>>    auto opSlice() { return foo; }
>> }
>>
>> Then when you use the class in a foreach loop, it'll be sliced, and the return
>> value of opSlice (the array in this case) will then be iterated over.
>>
>> - Jonathan M Davis
>
> So we basically have 4 ways..?
> 1) popFront + front
> 2) opSlice
> 3) alias this
> 4) opApply

How about having a nested struct implementing a range interface + a method (@property) returning it + alias this on the property?

http://dpaste.dzfl.pl/230061d2