|
I don't agree. I learned most of what i know by reading all the intellisense methods + documentation of objects, and without trial and error noone would ever be a coder. That said, i used C# and read object documentation as a hobby...
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
And that's why I state that exams should verify a knowledge which cannot be gained from documentation.
"Hey, there is ain't knowledge which wouldn't be in documentation" you say. Huh, then ask a "senior programmist" and he'll give you a 30-min speech on the topic: "Why you should be on my lectures instead of reading damn stupid books not written by me or surfing the Internet.". Well, I think he'll be right in most cases.
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
Heh, I do about the same.
Especially since the Microsoft documentation is a bad joke as it doesn't actually contain any more information than the tooltips in VS.
And the vast majority of articles on websites like this one or in books, which aren't about the basics of the basics, rely too much on the context.
If you want to know more about class x, the articles usually don't provide much information on the general usage and behavior but only in the specific context of the example, which barely ever has the slight similarity to do with what you need it for.
Also, the vast majority of all programming exams consist of scribbling on paper.
If not, they usually consist of doing a project and sending in the result.
Paper is okay, at least if the reviewer isn't too strict.
Subtracting too many points for missing semicolons and such is just stupid.
Anyway, the topic really belongs here. Sounds like college/University the creator attends teaches a lot of bad practices.
|
|
|
|
|
gajatko wrote: In this semester I've got a new subject: "Object-oriented programming".
[Bogus misuse of object orientation]
Flee! As fast as you can. You are to be brainwashed.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Oh com'n we've got sooo much mathematics here. I couldn't just leave it. A lot of unrevealed algebra awaits... 
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
public sealed class ClassName: ClassNameBase<br />
{<br />
<br />
internal ClassName(Type1 param1, Type2 param2) :base( param1, param2)<br />
{<br />
}<br />
}
Whats the beauty of it ?? The class does not have a single static member, and is compiled all by itself to a DLL.
|
|
|
|
|
Well - it does provide a concrete implementation of ClassNameBase, so it would work. OK - perhaps ClassNameBase shouldn't be an abstract class (I'm assuming that it is abstract), but this would work.
|
|
|
|
|
Not sure I see your point. The Class is sealed - therefore it can not be inherited. The constructor is internal and the class is in a DLL, therefore you can't create an instance of the class either.
ClassNameBase has nothing to do with anything at all.
|
|
|
|
|
VentsyV wrote: ClassNameBase has nothing to do with anything at all.
Actually, it does. It's the constructor that has nothing to do with it.
You could create this with:
ClassNameBase myclass = new ClassNameBase();
ClassName concreteImpl = myClass; I'm not sure how useful this would be, but it could be done.
|
|
|
|
|
Pete O'Hanlon wrote: ClassNameBase myclass = new ClassNameBase();ClassName concreteImpl = myClass;
I'm not sure how useful this would be, but it could be done.
Actually it cant be done :p You would need an implicit cast from a base class to it's parent derivation, and the CLR does not permit that. 
See my post for the likely explanation why it is sealed with an internal constructor.
|
|
|
|
|
You're right of course. How could I have missed that? A 5 for spotting my stupidity.
|
|
|
|
|
VentsyV wrote: The constructor is internal and the class is in a DLL, therefore you can't create an instance of the class either.
That is correct, but it's likely the library writer wants to expose the instance via a member, but still disallow instantiation. IMO, this shows a very good knowledge of the language/platform being dealt with (unless it really was a mistake!).
|
|
|
|
|
If the class is laid out without any other members (as in the OP) then this wouldn't be it.
|
|
|
|
|
Pete O'Hanlon wrote: If the class is laid out without any other members (as in the OP) then this wouldn't be it.
You missed the '//Stuff' bit?
|
|
|
|
|
Damn - I did  . If I'd seen that, I'd have answered the same as you - I guess I have "stuff" blindness (I'd normally put this in as // Do Something here).
|
|
|
|
|
leppie wrote: That is correct, but it's likely the library writer wants to expose the instance via a member, but still disallow instantiation
Can you explain this ?? I can't make sense out of it. What instance ?? There is no way you can create any instance of this class, as it is in assembly by itself.
|
|
|
|
|
VentsyV wrote: There is no way you can create any instance of this class, as it is in assembly by itself.
First off, if this class in an assembly by itself and the assembly does not have any friend assemblies, the rest that follow is irrelevant. Then it means he uses reflection for something stupid.
You need to understand that you dont need to create an instance.
Lets take a 'real world' example (this is in xacc.ide, not sure how real world it is ):
public sealed class TextBuffer
{
internal TextBuffer(AdvancedTextBox atb) { ... }
}
public class AdvancedTextBox
{
public TextBuffer Buffer {get {return buffer;}}
public AdvancedTextBox()
{
buffer = new TextBuffer(this);
}
}
Now I dont want anyone to use the TextBuffer class without using my AdvancedTextBox class. In other words, the author states the class is not usable without accessing it thought an AdvancedTextBox instance, for whatever reason that may be (perhaps unstable, restricted, propriety, etc).
Note: the example is not exactly like it is in xacc.ide, I rather use the better approach of making TextBuffer a nested class of AdvancedTextBox, thus giving me even more flexibility on usage. 
|
|
|
|
|
Might there be a factory method?
|
|
|
|
|
No, he states that there are no static members.
|
|
|
|
|
Oh, yeah, I knew that...
|
|
|
|
|
Thats exactly what I've been saying all along. The class is in assembly by itself and there are no friend assemblies declared. There are no static members either.
I'm not an expert in C# but to me that makes no sense whatsoever.
Also, in the example you gave, you did create an instance of TextBuffer, and by the way, you have to declare buffer (lowercase 'b') somewhere or you'll get a compiler error.
|
|
|
|
|
I once asked another 'senior' programmer to check his work again for bugs, and his reply was: "Alright, I'll check my codes."
Me: It's "code", not "codes".
Every time someone calls it "codes" instead of "code", it feels like I'm getting stabbed in the ear with a ice pick. Does anyone else here get the same feeling when people can't seem to say things correctly when it comes to programming?
|
|
|
|
|
Philip Laureano wrote: Every time someone calls it "codes" instead of "code", it feels like I'm getting stabbed in the ear with a ice pick. Does anyone else here get the same feeling when people can't seem to say things correctly when it comes to programming?
Personally, I think it feels like I'm using a cheese grater on my ears.
|
|
|
|
|
Philip Laureano wrote: Every time someone calls it "codes" instead of "code", it feels like I'm getting stabbed in the ear with a ice pick.
How about "softwares"?
|
|
|
|
|
Nemanja Trifunovic wrote: How about "softwares"?
That one too. My favorite one has to be when someone pronounces C# as "C Pound"...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
