www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Short overview on D

reply "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
A small background on this:

I'm a university student about to start my graduation project 
with two teammates, both of which have a C/Java/Python background 
and I suggested we use D for our project. They're not familiar 
with it, so I wrote a short tutorial for them here: 
https://github.com/bayanr/d-tutorial.

I wanted to see what you guys thought, and if this could be a 
useful introduction for people with similar backgrounds. It's a 
first draft so it probably has a lot of mistakes, omissions, etc. 
so any criticism is welcome.
Aug 03 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2014 7:36 p.m., Bayan Rafeh wrote:

 A small background on this:

 I'm a university student about to start my graduation project with two
 teammates, both of which have a C/Java/Python background and I suggested
 we use D for our project. They're not familiar with it, so I wrote a
 short tutorial for them here: https://github.com/bayanr/d-tutorial.

 I wanted to see what you guys thought, and if this could be a useful
 introduction for people with similar backgrounds. It's a first draft so
 it probably has a lot of mistakes, omissions, etc. so any criticism is
 welcome.


Your introduction to templates is far too simplistic.
What you introduced was template blocks. But showing them as templated 
classes.
There is also templated functions, methods ext. After all.
It may also be wise to introduce CTFE as well. But not so important.

I.e.

class ArrayList(T) {
     T[] l;
}

alias IntList = ArrayList!int;
IntList list = new IntList();

would probably be better.
That way also the compiler doesn't have initiate the entire template 
just to get one class definition out of it.

Everything else looks good including mixin templates. But just for food 
for thought. With statements are cool.

Hope to hear more of how the project goes.
Aug 03 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 3 August 2014 at 08:07:04 UTC, Rikki Cattermole wrote:

 Your introduction to templates is far too simplistic.


You can use this[1] as a source to beef things up there.

http://nomad.so/2013/07/templates-in-d-explained/
Aug 03 2014
prev sibling parent reply "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
Wow clearly I misunderstood a lot of stuff.

On Sunday, 3 August 2014 at 08:07:04 UTC, Rikki Cattermole wrote:

 On 3/08/2014 7:36 p.m., Bayan Rafeh wrote:

 A small background on this:

 I'm a university student about to start my graduation project 
 with two
 teammates, both of which have a C/Java/Python background and I 
 suggested
 we use D for our project. They're not familiar with it, so I 
 wrote a
 short tutorial for them here: 
 https://github.com/bayanr/d-tutorial.

 I wanted to see what you guys thought, and if this could be a 
 useful
 introduction for people with similar backgrounds. It's a first 
 draft so
 it probably has a lot of mistakes, omissions, etc. so any 
 criticism is welcome.


 Your introduction to templates is far too simplistic.
 What you introduced was template blocks. But showing them as 
 templated classes.
 There is also templated functions, methods ext. After all.
 It may also be wise to introduce CTFE as well. But not so 
 important.


That's definitely going in there but I'm just making sure I fix 
everything I have so far. If the responses so far are any 
indication there is a lot of fixing that needs to be done.


 I.e.

 class ArrayList(T) {
     T[] l;
 }

 alias IntList = ArrayList!int;
 IntList list = new IntList();

 would probably be better.


Could you give any suggestions for some example use cases that 
can properly demo templates? If not I'll think of some.


 Everything else looks good including mixin templates. But just 
 for food for thought. With statements are cool.


I'll be sure to add those as well. I just remembered I forgot to 
add scope too.

 Hope to hear more of how the project goes.


We're presenting at the end of the next spring semester, I'll be 
sure to share it here once it's complete.



 -- Functions --


 Ref implies the type is a reference type, i.e. changes inside 
 the functions will change the variable outside the function. 
 in means immutable out is an alias for ref(preferably used for 
 parameters)


 `ref` doesn't "imply" a reference, it "declares" or "states" or
 something.


I'm basing this on the wiki: http://dlang.org/function.html
"ref	parameter is passed by reference"

If that is not the case, in practical terms what does that mean 
exactly?


 `in` doesn't mean immutable, it means scope const.
 `out` is similar to `ref`, but it's not an alias. Unlike `ref`,
 an out "parameter is initialized upon function entry with the
 default value for its type".


Sorry I'll fix those shortly.

 -- Operator Overloading --

 The wording suggests that the list of operators is supposed to 
 be
 exhaustive. It's not.


I intended it to be comprehensive(with regard to types at least). 
What am I missing regarding the different types of operators 
besides the opAssigns?


 unitary


 unary


Ah crap, ok will fix that as well.

 -- Templates --


 Templates are D's response to Java generics and C++ templates.


 At least put C++ first if you have to include Java ;)


Riots would ensue. To put it lightly we're not fans of C++. Well 
we're not exactly fans of Java either :p


 Basically templates are metaclasses that take types as 
 parameters.


 Template parameters are not restricted to types. They can also 
 be values or symbols.


I guess I need a more exhaustive list of examples.


 alias List!int.ArrayList IntList;


 Maybe use the more fashionable assignment syntax:
 alias IntList = List!int.ArrayList;

 -- Arrays --


 a[x..y] is an array containing a[x] all the way to a[y]


 To avoid confusion: all the way up to, but not including, a[y].


Will fix that as well.

PS. I applied some of the changes, though I left the stuff that I 
need clarification on.

Thank you very much for the comments so far, please keep them 
coming.
Aug 03 2014
next sibling parent "anonymous" <anonymous example.com> writes:
On Sunday, 3 August 2014 at 10:57:26 UTC, Bayan Rafeh wrote:

 -- Functions --


 Ref implies the type is a reference type






[...]

 `ref` doesn't "imply" a reference, it "declares" or "states" or
 something.


 I'm basing this on the wiki: http://dlang.org/function.html
 "ref	parameter is passed by reference"

 If that is not the case, in practical terms what does that mean 
 exactly?


I'm just picking on the word "implies". Making the parameter be
passed by reference is `ref`'s sole purpose. When you say that
`ref` implies pass by reference, I'd expect it to mainly do
something else, which it doesn't. I'm not a native English
speaker, though, so I may be completely off here.


 -- Operator Overloading --

 The wording suggests that the list of operators is supposed to 
 be
 exhaustive. It's not.


 I intended it to be comprehensive(with regard to types at 
 least). What am I missing regarding the different types of 
 operators besides the opAssigns?


There's logical operators (&& ||), bitwise operators (& | ^ <<
etc), ~ for array concatenation, and others. These all fall under
opBinary, but calling them mathematical would be misleading (at
least to me).

`c ? t : f` is the "ternary operator". It can't be overloaded,
though.

You can overload `cast` (opCast) and `foreach` (range primitives
or opApply). I'm not sure if they're proper operators.

There's probably more.


 -- Templates --


 Templates are D's response to Java generics and C++ templates.


 At least put C++ first if you have to include Java ;)


 Riots would ensue. To put it lightly we're not fans of C++. 
 Well we're not exactly fans of Java either :p


The point is, D's templates are related more closely to C++'s
template than to Java's generics.
Aug 03 2014
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2014 10:57 p.m., Bayan Rafeh wrote:

 Wow clearly I misunderstood a lot of stuff.

 On Sunday, 3 August 2014 at 08:07:04 UTC, Rikki Cattermole wrote:

 On 3/08/2014 7:36 p.m., Bayan Rafeh wrote:

 A small background on this:

 I'm a university student about to start my graduation project with two
 teammates, both of which have a C/Java/Python background and I suggested
 we use D for our project. They're not familiar with it, so I wrote a
 short tutorial for them here: https://github.com/bayanr/d-tutorial.

 I wanted to see what you guys thought, and if this could be a useful
 introduction for people with similar backgrounds. It's a first draft so
 it probably has a lot of mistakes, omissions, etc. so any criticism
 is welcome.


 Your introduction to templates is far too simplistic.
 What you introduced was template blocks. But showing them as templated
 classes.
 There is also templated functions, methods ext. After all.
 It may also be wise to introduce CTFE as well. But not so important.


 That's definitely going in there but I'm just making sure I fix
 everything I have so far. If the responses so far are any indication
 there is a lot of fixing that needs to be done.


 I.e.

 class ArrayList(T) {
     T[] l;
 }

 alias IntList = ArrayList!int;
 IntList list = new IntList();

 would probably be better.


 Could you give any suggestions for some example use cases that can
 properly demo templates? If not I'll think of some.


Templates are a very complex beast to give examples for. But here are 
some simple ones:

1.

class Something : ASomething {
     void dosomething(T : ASomething2)(T value) {
         import std.stdio;
         writeln(value.getter);
     }
}

2.

class List(T : Object) {
    T[] items;
}

3.

std.regex.ctRegex (I'll let you grab that).

4.

Dump from a side project I'm working on.

module dwc.interfaces.eventable;
import std.string : toUpper;
import std.algorithm : filter, moveAll;

/**
  * Provides an interface version of an eventing mechanism.
  *
  * See_Also:
  * 		Eventing
  */
mixin template IEventing(string name, T...) {
	mixin("void add" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(bool 
delegate(T));});
	mixin("void add" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(void 
delegate(T));});

	mixin("void remove" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(bool 
delegate(T));});
	mixin("void remove" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(void 
delegate(T));});
	
	mixin("void " ~ name ~ q{(T args);});
	mixin("void clear" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(T args);});
	
	static if (T.length > 0) {
		static if (__traits(compiles, typeof(this)) && is(typeof(this) : T[0])) {
			mixin("void " ~ name ~ q{(T[1 .. $] args);});
		}
	}
}


/**
  * Implements an eventable interface for something.
  * Includes support for bool delegate(T) and void delegate(T).
  * Will consume a call to all delegates if it returns true. Default false.
  *
  * Example usage:
  * 		mixin Eventing!("onNewListing", ListableObject);
  *
  * If is(T[0] == typeof(this)) then it'll use this as being the first 
argument.
  */
mixin template Eventing(string name, T...) {
	mixin(q{bool delegate(T)[] } ~ name ~ "_;");
	mixin(q{bool delegate(T)[void delegate(T)] } ~ name ~ "_assoc;");

	mixin("void add" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(void 
delegate(T) value) {
			mixin(name ~ "_ ~= (T args) => {value(args); return false;}();");
			mixin(name ~ "_assoc[value] = " ~ name ~ "_[$-1];");
		}});
	mixin("void add" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(bool 
delegate(T) value) {
			mixin(name ~ "_ ~= value;");
		}});

	mixin("void remove" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(bool 
delegate(T) value) {
			mixin("moveAll(filter!(a => a !is value)(" ~ name ~ "_), " ~ name ~ 
"_);");
		}});
	mixin("void remove" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(void 
delegate(T) value) {
			mixin("moveAll(filter!(a => a !is " ~ name ~ "_assoc.get(value, 
null))(" ~ name ~ "_), " ~ name ~ "_);");
		}});
	
	mixin("void " ~ name ~ q{(T args) {
			foreach (del; mixin(name ~ "_")) {
				del(args);
			}
		}});
	
	mixin("void clear" ~ toUpper(name[0] ~ "") ~ name[1 ..$] ~ q{(T args) {
			mixin(name ~ "_") = [];
		}});
	
	static if (__traits(compiles, typeof(this)) && is(typeof(this) : T[0])) {
		mixin("void " ~ name ~ q{(T[1 .. $] args) {
				foreach (del; mixin(name ~ "_")) {
					if (del(this, args))
						return;
				}
			}});
	} else {
		mixin("void " ~ name ~ q{(T args) {
				foreach (del; mixin(name ~ "_")) {
					if (del(args))
						return;
				}
			}});
	}
}


 Everything else looks good including mixin templates. But just for
 food for thought. With statements are cool.


 I'll be sure to add those as well. I just remembered I forgot to add
 scope too.


With statements are just so neat in my opinion. Just think of the 
possibilities for GWT like libraries.

WebPage page;
with(page ~= new Layout) {
     with(~= new Button) {
         label = "Some text";
     }
     type = Layouts.Sequential;
     //...
}


 Hope to hear more of how the project goes.


 We're presenting at the end of the next spring semester, I'll be sure to
 share it here once it's complete.



 -- Functions --


 Ref implies the type is a reference type, i.e. changes inside the
 functions will change the variable outside the function. in means
 immutable out is an alias for ref(preferably used for parameters)


 `ref` doesn't "imply" a reference, it "declares" or "states" or
 something.


 I'm basing this on the wiki: http://dlang.org/function.html
 "ref    parameter is passed by reference"

 If that is not the case, in practical terms what does that mean exactly?


ref is like how in c++ has &var for function arguments. Basically passes 
a value by pointer while not requiring you on the caller end to pass by 
pointer and at the callee end use it as a pointer.


 `in` doesn't mean immutable, it means scope const.
 `out` is similar to `ref`, but it's not an alias. Unlike `ref`,
 an out "parameter is initialized upon function entry with the
 default value for its type".


 Sorry I'll fix those shortly.

 -- Operator Overloading --

 The wording suggests that the list of operators is supposed to be
 exhaustive. It's not.


 I intended it to be comprehensive(with regard to types at least). What
 am I missing regarding the different types of operators besides the
 opAssigns?


 unitary


 unary


 Ah crap, ok will fix that as well.

 -- Templates --


 Templates are D's response to Java generics and C++ templates.


 At least put C++ first if you have to include Java ;)


 Riots would ensue. To put it lightly we're not fans of C++. Well we're
 not exactly fans of Java either :p


 Basically templates are metaclasses that take types as parameters.


 Template parameters are not restricted to types. They can also be
 values or symbols.


 I guess I need a more exhaustive list of examples.


 alias List!int.ArrayList IntList;


 Maybe use the more fashionable assignment syntax:
 alias IntList = List!int.ArrayList;

 -- Arrays --


 a[x..y] is an array containing a[x] all the way to a[y]


 To avoid confusion: all the way up to, but not including, a[y].


 Will fix that as well.

 PS. I applied some of the changes, though I left the stuff that I need
 clarification on.

 Thank you very much for the comments so far, please keep them coming.
Aug 03 2014
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
-- Functions --


 Ref implies the type is a reference type, i.e. changes inside 
 the functions will change the variable outside the function. in 
 means immutable out is an alias for ref(preferably used for 
 parameters)


`ref` doesn't "imply" a reference, it "declares" or "states" or
something.
`in` doesn't mean immutable, it means scope const.
`out` is similar to `ref`, but it's not an alias. Unlike `ref`,
an out "parameter is initialized upon function entry with the
default value for its type".

-- Operator Overloading --

The wording suggests that the list of operators is supposed to be
exhaustive. It's not.


 unitary


unary

-- Templates --


 Templates are D's response to Java generics and C++ templates.


At least put C++ first if you have to include Java ;)


 Basically templates are metaclasses that take types as 
 parameters.


Template parameters are not restricted to types. They can also be
values or symbols.


 alias List!int.ArrayList IntList;


Maybe use the more fashionable assignment syntax:
alias IntList = List!int.ArrayList;

-- Arrays --


 a[x..y] is an array containing a[x] all the way to a[y]


To avoid confusion: all the way up to, but not including, a[y].
Aug 03 2014
prev sibling next sibling parent reply "Nobody" <Nobody nowhere.rk> writes:
On Sunday, 3 August 2014 at 07:36:43 UTC, Bayan Rafeh wrote:

 A small background on this:

 I'm a university student about to start my graduation project 
 with two teammates, both of which have a C/Java/Python 
 background and I suggested we use D for our project. They're 
 not familiar with it, so I wrote a short tutorial for them 
 here: https://github.com/bayanr/d-tutorial.

 I wanted to see what you guys thought, and if this could be a 
 useful introduction for people with similar backgrounds. It's a 
 first draft so it probably has a lot of mistakes, omissions, 
 etc. so any criticism is welcome.


I think that people who knows and masters another OOP lang. could 
digest the official doc ;) . So if I were you I'd rather simplify 
the offical docs: rephrasing, removing the details and 
subtilities and a mention at the end of each simplified chapter: 
'learn more', with a link to the official page.
Aug 03 2014
parent "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
On Sunday, 3 August 2014 at 11:12:45 UTC, Nobody wrote:

 On Sunday, 3 August 2014 at 07:36:43 UTC, Bayan Rafeh wrote:

 A small background on this:

 I'm a university student about to start my graduation project 
 with two teammates, both of which have a C/Java/Python 
 background and I suggested we use D for our project. They're 
 not familiar with it, so I wrote a short tutorial for them 
 here: https://github.com/bayanr/d-tutorial.

 I wanted to see what you guys thought, and if this could be a 
 useful introduction for people with similar backgrounds. It's 
 a first draft so it probably has a lot of mistakes, omissions, 
 etc. so any criticism is welcome.


 I think that people who knows and masters another OOP lang. 
 could digest the official doc ;) . So if I were you I'd rather 
 simplify the offical docs: rephrasing, removing the details and 
 subtilities and a mention at the end of each simplified 
 chapter: 'learn more', with a link to the official page.


I did that for some things, but I probably should do it for all 
the fields. My goal with this is to give them enough background 
to be able to comfortably be able to navigate the official docs 
themselves.
Aug 03 2014
prev sibling parent reply "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
Small question. Can anyone give me an example of when one would 
use a parametrized block as opposed to a parameterized class or 
method?
Aug 03 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 3/08/2014 11:53 p.m., Bayan Rafeh wrote:

 Small question. Can anyone give me an example of when one would use a
 parametrized block as opposed to a parameterized class or method?


mixin templates take the context for which they are mixed in. Basically:


mixin template FooT() {
	void FooT() {
		//...
		writeln(bar);
	}
}

void myfunc() {
	string bar;
	//...
	mixin FooT;
}

Templated classes/structs/unions/method or functions are used for if you 
want to modify code gen itself.
Aug 03 2014
parent reply "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
On Sunday, 3 August 2014 at 11:56:32 UTC, Rikki Cattermole wrote:

 On 3/08/2014 11:53 p.m., Bayan Rafeh wrote:

 Small question. Can anyone give me an example of when one 
 would use a
 parametrized block as opposed to a parameterized class or 
 method?


 mixin templates take the context for which they are mixed in. 
 Basically:


 mixin template FooT() {
 	void FooT() {
 		//...
 		writeln(bar);
 	}
 }

 void myfunc() {
 	string bar;
 	//...
 	mixin FooT;
 }

 Templated classes/structs/unions/method or functions are used 
 for if you want to modify code gen itself.


I'm not sure if we're going to be using templates much so I'm 
going to include a couple of examples you gave, plus the link 
that Gary posted which is better than anything I could write 
right now. Do you think that's enough?

And I see what you mean with the with statement. It certainly is 
an intriguing concept, and I would love to see something like 
that.

Anonymous: I see. C++ first it is.
Aug 03 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 4/08/2014 12:30 a.m., Bayan Rafeh wrote:

 On Sunday, 3 August 2014 at 11:56:32 UTC, Rikki Cattermole wrote:

 On 3/08/2014 11:53 p.m., Bayan Rafeh wrote:

 Small question. Can anyone give me an example of when one would use a
 parametrized block as opposed to a parameterized class or method?


 mixin templates take the context for which they are mixed in. Basically:


 mixin template FooT() {
     void FooT() {
         //...
         writeln(bar);
     }
 }

 void myfunc() {
     string bar;
     //...
     mixin FooT;
 }

 Templated classes/structs/unions/method or functions are used for if
 you want to modify code gen itself.


 I'm not sure if we're going to be using templates much so I'm going to
 include a couple of examples you gave, plus the link that Gary posted
 which is better than anything I could write right now. Do you think
 that's enough?


If you're using writeln, you're using templates. Pretty much, once you 
start using them, you'll realize inherently how powerful they are. 
That's why I believe it should be more then just touched upon :)


 And I see what you mean with the with statement. It certainly is an
 intriguing concept, and I would love to see something like that.


It's quite underused. It'll be quite exciting to see it being actually 
used in frameworks.


 Anonymous: I see. C++ first it is.
Aug 03 2014
parent "Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:
On Sunday, 3 August 2014 at 13:27:40 UTC, Rikki Cattermole wrote:

 On 4/08/2014 12:30 a.m., Bayan Rafeh wrote:

 On Sunday, 3 August 2014 at 11:56:32 UTC, Rikki Cattermole 
 wrote:

 On 3/08/2014 11:53 p.m., Bayan Rafeh wrote:

 Small question. Can anyone give me an example of when one 
 would use a
 parametrized block as opposed to a parameterized class or 
 method?


 mixin templates take the context for which they are mixed in. 
 Basically:


 mixin template FooT() {
    void FooT() {
        //...
        writeln(bar);
    }
 }

 void myfunc() {
    string bar;
    //...
    mixin FooT;
 }

 Templated classes/structs/unions/method or functions are used 
 for if
 you want to modify code gen itself.


 I'm not sure if we're going to be using templates much so I'm 
 going to
 include a couple of examples you gave, plus the link that Gary 
 posted
 which is better than anything I could write right now. Do you 
 think
 that's enough?


 If you're using writeln, you're using templates. Pretty much, 
 once you start using them, you'll realize inherently how 
 powerful they are. That's why I believe it should be more then 
 just touched upon :)


Very well then. I will try my best to do them justice.


 And I see what you mean with the with statement. It certainly 
 is an
 intriguing concept, and I would love to see something like 
 that.


 It's quite underused. It'll be quite exciting to see it being 
 actually used in frameworks.


I'll add it in there on the off chance that someone designing a 
framework will stumble upon this tutorial and make use of if.


 Anonymous: I see. C++ first it is.
Aug 03 2014