I just wanted to quickly remind people that this workshop is geared towards beginning C# programmers, and doesn't really require any previous programming experience. As this is the first week, we're doing a brief overview of the language syntax and semantics.

PLEASE, PLEASE, PLEASE ask your questions about anything you don't understand from chapters 1 and 2. Myself, and anyone else with sufficient experience with the C# language will try our best to answer your questions quickly and accurately.

....PLEASE, PLEASE, PLEASE do NOT ask those questions about polymorphism or how to disassemble IL code, which you've been dying to ask. [smile]

If you've just been DYING to ask a question about a super complex C# issue, either wait until we cover the topic within the workshop, or ask in .NET, GP, or FB.

My point is, these workshops work best if everyone's focused on the same topics and the same problems. Please try and focus on the content within the assigned chapters. Doing otherwise can just cause additional confusion for those following the workshop as they get inundated with separate conversations about topics they've not yet covered deeply enough to understand.

General questions about the .NET Framework Library, the CLR, or IL should be addressed to the .NET forum until we reach such topics within the C# Workshop.

Thanks Everyone!

Quote: Original post by Rahl
Hey, no questions yet, but I was wondering if you were going to post the fist project, because you said in the introduction thread that you would post it at the very beginning of the workshop so we could fill in the gaps as we moved along. Thanks.

Good point. Let me explain. I wanted to make sure the workshop was as cohesive as possible, that the exercises gave accurate experience dealing with the topics in the review questions, and that the projects built up to something greater than each individually.

As a result, I decided to work backwards. I've written a design document and have begun implementing the final project for the workshop. Once this is complete I will break the final project up into smaller sub-projects, and then draw problems from each of the projects to be used as exercises for the weekly threads. When all of this is complete, anyone who can answer the review questions should be able to do the exercises; anyone who does the exercises will be working their way towards completing the bi-weekly projects; and anyone who completes the bi-weekly projects will, in the end, have completed the final project - a Single-Player Text RPG with built in support for multiplayer capabilities.

So why isn't project 1 posted yet?!?! Simple, because it's taking me more than the month I gave myself to prepare all the materials for the workshop, which includes completing the final project. In other words, I haven't posted project 1 yet (and probably wont until after week 2) because I'm not sure what components of the final project will be addressed in project 1.

Sorry about that, I'll get the project description out as quickly as I can, based upon my completion of the final project, breaking it up into sub-projects, and then pulling exercises out. Please be patient, I'm only one man. [smile]

Cheers!

Quote: Original post by Rahl
I have a little experience with C#, but not much, and I am finding it confusing as hell. I even looked past the first two chapters at the 3rd one, because I figured it would be easier to understand since it doesn't throw everything at you at once...it wasn't easier :(

I just want to see the project; I learn better when I have something to work at while I'm learning. It's like math, I can never understand it just by listening to the professor lecture, but rather by working the examples.

What in particular are you finding confusing? Speak up, man, that's why we're here!! [smile]

Looking past the first two chapters wont help make anything more clear, if you haven't read the first two chapters. Once the authors explore the concepts of the language a little, they assume that you are at least that familiar with the topics when moving forward.

The unfortunate truth is that each week is roughly 50 pages, and the only way to move forward is to read those pages, ask your questions, and make sure you absorb the information they've presented.

Not asking questions, or assuming the questions will be answered later in the text will only allow you to get more confused. So if there's something you don't understand from chapter 1 or chapter 2, please ask. We're happy to help.

Start by making sure you can answer the review questions I posted at the beginning. If you can answer all those correctly, you've learned the information you need for the week.

Cheers!

Well then I'll speak up!

Explicit interface member implementations. First, the obligatory, "huh?". Second, why would I want to use this? It sounds like a way to have more correct OOD/OOP. But I see no benefit to doing such a thing and not make the interface methods public.

Also, I don't understand why this code errors:

Quote: Original post by Alpha_ProgDes
Well then I'll speak up!

Explicit interface member implementations. First, the obligatory, "huh?". Second, why would I want to use this? It sounds like a way to have more correct OOD/OOP. But I see no benefit to doing such a thing and not make the interface methods public.

Also, I don't understand why this code errors:
*** Source Snippet Removed ***

If two interfaces define methods with the same signature, you can use explicit interface implementation to provide different meanings for each interface. This is even unavoidable if both interfaces define methods with the same name and argument list, but different return value.

For your example, in order to be able to invoke Paint without having to cast to IControl, you can define Paint as a normal method, and have the explicit interface implementation call it.

The reason it's an error to call a Paint through the EditBox-reference is again the same as above: it could be that there are two methods with the same signature, and the compiler won't know which one you mean. They could have added shortcuts (such as allowing to call it through EditBox if there are no name clashes), but I guess they must have had their reasons not to do that. Perhaps the fact that client code would break if you'd add an extra name-clash-causing interface afterwards.

Quote: Original post by Alpha_ProgDes
Well then I'll speak up!

Explicit interface member implementations. First, the obligatory, "huh?". Second, why would I want to use this? It sounds like a way to have more correct OOD/OOP. But I see no benefit to doing such a thing and not make the interface methods public.

Also, I don't understand why this code errors:
*** Source Snippet Removed ***

Aren't members of a class assumed private unless declared public?

I'm working on the questions still, but I thought I'd post my console app:


[Edited by - dusty_one on July 1, 2007 8:25:07 PM]

Quote: Original post by dusty_one

Quote: Original post by Alpha_ProgDes
Well then I'll speak up!

Explicit interface member implementations. First, the obligatory, "huh?". Second, why would I want to use this? It sounds like a way to have more correct OOD/OOP. But I see no benefit to doing such a thing and not make the interface methods public.

Also, I don't understand why this code errors:
*** Source Snippet Removed ***

Aren't members of a class assumed private unless declared public?

No. That's the case in C++, but not in C#. In C#, members are internal by default. (I guess I was thinking of java)

Yes, you are right: from 3.5.1

Quote:
Class members can have any of the five kinds of declared accessibility and default to private declared accessibility.

Woot I remembered something! Of course it took 3 or 4...or 6 rereadings before things start to stick, but stick they will!

One thing that's puzzled me in any oop language, the idea behind protecting class members. I don't see why one would want to mak esome things inaccessable, or if you can get to it, you do it only through getters and setters. What's the logic in making a member protected?