I want to make a few (5-10?) D OOP tutorials for dsource.
That way I can learn about oop myself and help D, I hope :)

They should thus focus on people who never programmed in an oop style.

Every tutorial should elaborate on the previous one, but on themselves also
compile into something interesting||useful.
The filler code (not related to oop but necessary to make it a interesting
program) should not be too complex.

Anybody any idea which kind of program suits best?
The filler code in a ray tracer might just be a bit too complex.

On Mon, 03 Mar 2008 17:22:02 +0100, Saaa wrote:

> I want to make a few (5-10?) D OOP tutorials for dsource. That way I can
> learn about oop myself and help D, I hope :)
> 
> They should thus focus on people who never programmed in an oop style.
> 
> Every tutorial should elaborate on the previous one, but on themselves also compile into something interesting||useful. The filler code (not related to oop but necessary to make it a interesting program) should not be too complex.
> 
> Anybody any idea which kind of program suits best? The filler code in a ray tracer might just be a bit too complex.

I don't have any suggestions for interesting programs, but some ideas of how you may want to cover it. One thing you may want to do is not only build off past examples, but to show improvements with newly introduced tools.

** Start by writing a class.
**** Static data of a class
** Then extend the class for more use.
**** Keywords private, protected, public should be discussed in their
relationship to modules.
** Introduce interfaces, maybe turn the first class into an interface
** Concentrate on function overriding and down/up casting.
** Inner classes
** Operator overloading

I don't see templates as part of classes but still might be a good thing to cover.

Saaa Wrote:

> I want to make a few (5-10?) D OOP tutorials for dsource.
> That way I can learn about oop myself and help D, I hope :)
> 
> They should thus focus on people who never programmed in an oop style.
> 
> Every tutorial should elaborate on the previous one, but on themselves also
> compile into something interesting||useful.
> The filler code (not related to oop but necessary to make it a interesting
> program) should not be too complex.
> 
> Anybody any idea which kind of program suits best?
> The filler code in a ray tracer might just be a bit too complex.
> 
> 
> 
> 
Make sure you get someone who speaks English well and also knows something about the subject to proof read it for you . Most of the problems I find on the web tutorials are related to what you mean when you say "foo" as opposed to what I normally associate with "foo"

Thank you for your suggestions.
 Looking at the list tells me that I need a lot of help (I barely know what
half of them mean :)

What are the 2/4 asterisks for? Is that how you suggest I should build of
previous tutorials?
I think the list you gave would work just nice in a build-from-previous
setup or maybe I just don't understand it enough.

I'll write a class today (after reading about them on digitalmars)

For now I will only use D1 and phobos but its all open for additions ofcourse.

**signal & slots

>
> I don't have any suggestions for interesting programs, but some ideas of how you may want to cover it. One thing you may want to do is not only build off past examples, but to show improvements with newly introduced tools.
>
> ** Start by writing a class.
> **** Static data of a class
> ** Then extend the class for more use.
> **** Keywords private, protected, public should be discussed in their
> relationship to modules.
> ** Introduce interfaces, maybe turn the first class into an interface
> ** Concentrate on function overriding and down/up casting.
> ** Inner classes
> ** Operator overloading
>
> I don't see templates as part of classes but still might be a good thing to cover.

Yeah, I never understood the whole foo thingy :)
But I'll just post all of them here first.
btw. I didn't know my english was that bad  :D

> Make sure you get someone who speaks English well and also knows something about the subject to proof read it for you . Most of the problems I find on the web tutorials are related to what you mean when you say "foo" as opposed to what I normally associate with "foo"

I meant: I won't use foo nor bar :)
And I'll at least proofread the tutorials myself (wwhich can't be said of
any of posts here :D

>
>> Make sure you get someone who speaks English well and also knows something about the subject to proof read it for you . Most of the problems I find on the web tutorials are related to what you mean when you say "foo" as opposed to what I normally associate with "foo"
>
> 

Ok, I'll will use some sort of spelling checking as well.

LOL. And never use words more times then needed

> Ok, I'll will use some sort of spelling checking as well.
> 

On Tue, 04 Mar 2008 06:03:48 +0100, Saaa wrote:

> Thank you for your suggestions.
>  Looking at the list tells me that I need a lot of help (I barely know
>  what
> half of them mean :)
> 
> What are the 2/4 asterisks for? Is that how you suggest I should build
> of previous tutorials?
> I think the list you gave would work just nice in a build-from-previous
> setup or maybe I just don't understand it enough.
> 
> I'll write a class today (after reading about them on digitalmars)
> 
> For now I will only use D1 and phobos but its all open for additions ofcourse.
> 
> **signal & slots
> 
> 
>> I don't have any suggestions for interesting programs, but some ideas of how you may want to cover it. One thing you may want to do is not only build off past examples, but to show improvements with newly introduced tools.
>>
>> ** Start by writing a class.
>> **** Static data of a class
>> ** Then extend the class for more use. **** Keywords private,
>> protected, public should be discussed in their relationship to modules.
>> ** Introduce interfaces, maybe turn the first class into an interface
>> ** Concentrate on function overriding and down/up casting. ** Inner
>> classes
>> ** Operator overloading
>>
>> I don't see templates as part of classes but still might be a good thing to cover.

I was trying to do bullet points, doing just a single will case bolding to happen (at least for me) and the 4 would be as sub of the 2.

Anyway I tried to keep to the building off of the previous, but depending on the project example it may not be possible all the way through, thus needing to start a new example (which would be fine).

I figured that it would also serve as a good list of things that you should look for when learning.

>
> I was trying to do bullet points, doing just a single will case bolding to happen (at least for me) and the 4 would be as sub of the 2.
>
> Anyway I tried to keep to the building off of the previous, but depending on the project example it may not be possible all the way through, thus needing to start a new example (which would be fine).
>
> I figured that it would also serve as a good list of things that you should look for when learning.

Thanks, I hope my previous post didn't come off too inappreciative.

As I said, I barely understand half of the list which shows that I really need the help :)