How about: 1) write a badass virus. 2) Unleash it to the world. 3) Have your friend rat you out. 4) Take some of your share of the bounty and hire a good lawyer :)
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
I agree. I've seen developers who know "ALL" the design patterns but can't write methods properly.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
I'd go for the simplest solution first, which is onStart (also takes care of Restart)
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Google "simple .net instant messenger" and click I'm feeling lucky
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Awwwww :D
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Jim Crafton wrote:
Well, in honor of Windows Azure, why not Windows Puce
Windows Puse. LOL. The Mac guys will have a field day with that name.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
It's okay to sleep. :-D
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
This may be old news (hopefully it's not a repost). Eric Lippert responded to the heated discussion we had the other day here. See http://blogs.msdn.com/ericlippert/archive/2008/10/08/the-future-of-c-part-one.aspx[^]
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Jon Rista wrote:
Extension Method Best Practices[^]
Thanks for that link.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
aa) If I didn't notice Microsoft placed all related extension methods in an (almost) extension-method only namespace. I would be placing regular methods and etension methods in the same namespace.
Jon Rista wrote:
b) Extension methods usually implement an algorithm. bb) First off, implementation of the method isn't the point, its the feature itself. Second, don't all methods implement an algorithm, however simple that algorithm may be?
I mean most LINQ extension methods implement a generic algorithm that works with any object as opposed to a function that performs an action on one object. On most blogs i've read, developers want to extend a type with a function they want so badly instead of considering deriving from that type and adding the function. cc) Since Microsoft developed this feature and must have researched it intensively, they should have at least warned us about it.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Jon Rista wrote:
Well, LINQ syntax comes to mind. The C# compiler translates LINQ into expression trees, which are a part of the .NET 3.5 framework. LINQ is syntactic sugar for a complex framework feature. Seems to be bound to a particular framework to me.
The foreach keyword binds to .NET's IEnumerable pattern, the lock keyword binds to .NET's Monitor.Enter/Monitor.Exit methods. There is nothing new in the C# 3 compiler translating LINQ's query expressions to .NET 3.5's expression trees. Anybody developing a compiler targeting a particular framework will decide how they want these keywords to work. Do they bind to a framework library? Do they generate their own code? etc.
Jon Rista wrote:
Come on man, have some common sense. If A, then B. If you need portable code, then use a portable language version. It's a simple concept. Don't go all about being the antagonist nay-saying useful language features that, apparently, you want to use, and are just miffed that the third-party projects like Mono havn't caught up with yet. It's like your a little kid, "If I can't have it, no one will!!"
LOL. You are right, but bear in mind that developers routinely port code someone else wrote. If I'm given a task to port C# 3 code to a C# 2 platform. I'm not going to sit around waiting for the third party platform to catch up. I should be able to do it because the .NET framework for both platforms are binary compatible. If I run into expression trees and Linq query syntax. I'll simply write a substitute class that performs the same functionality (provided the original author properly packaged those statements in classes). You have said good things about C# 3 and you have been correct (I personally love lambda expressions), however, we should call a spade a spade and that black sheep is called Extension methods. If their is something wrong with a product, the consumers have every right to voice their concerns and my concern is nobody except Microsoft knows how to properly use Extension methods. If you notice they: a) Package extension methods in exclusive namespaces. b) Extension methods usually implement an algorithm (not a function) c) Don't tell anyone else how to properly use it (I for one haven't seen a best practices paper on extension methods) The goto keyword is in every major programming language but it has been repeatedly advised not to be used unless y
Jon Rista wrote:
C# is a language, but it is tightly integrated with the .NET framework.
Is there any keyword in the C# language that suggests the use of a particular framework? What is to stop any one with the talent and time to write a C# compiler/framework that targets a currently unsupported platform?
Jon Rista wrote:
you just can't take advantage of new language versions until the third-parties catch up.
So what do i do if I need to port the code right now?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
James Lonero wrote:
Maybe, Microsoft, in their zeal to make it easier to write software, is turning C# into an all in one language where you can get a job done any way you want.
C++?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Not every developer writing C# code targets the .NET framework. I used IEnumerable.Where as an example which everyone would understand but it could be any set of extension methods from XYZ company.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Jon Rista wrote:
And that functionality is accessed through class INSTANCES...not static methods or utility types.
:omg: This is exactly why I said extension methods should come with a warning tag.
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Jon Rista wrote:
Portability? Where are you going to "port" a C# or VB.NET app to...they only run on the .NET platform anyway.
Wrong. Look up Portable.NET[^] and Mono[^] There are also other compilation techniques out there. See IL2CPU on Cosmos[^] and Bartok used for the Singularity project.[^] I don't understand why programmers can't seem to separate C# from .NET. C# is a programming language with a syntax and rules. The C# life cycle of your project ends after you successfully compile your project. The framework you are using then executes the compiled binaries (and it doesn't have to be IL).
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
Shog9 wrote:
If you're a newbie programmer, then it doesn't matter - it'll suck. If you're just new to C#, then you'll want to play around with the tools, and it'll probably still suck.
Yeah, I guess it's always good to have newbies around to laugh at! :)
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
S. Senthil Kumar wrote:
I get that they can pollute the list of methods in a class and can cause calls to unintended methods
BINGO!! Someone finally said it. Extension methods should come with a warning label. If you search the blogosphere, you'll see developers talking about how GREAT extension methods are and how they are going to add these great "extensions" that they always wanted to the classes that came with the class library. Imagine if I'm a newbie C# programmer and I want to perform a lot of strings to base64 encoded strings. I could create a static method and call that often, I could create a new class that has an implicit string operator that will perform the conversion or I could simply extend the string class? Which do you think I'd choose?
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
On Portability: 1) Imagine if I had to port some C# code from one framework/platform to another. Before C# 3.0, I'd had to make sure I have compatible libraries in the new framework. But now, I also have the added headache of figuring out where ALL the referenced extension methods in the code are and make sure they exist in the new framework (or write equivalent ones). It doesn't help that extension methods share the same dot notation with regular methods. I can't tell what an extension method is just by looking at the call. I'd have to write some tool that will check all referenced assemblies to point out the extension methods in the code. 2) Let's say I'm using LINQ's IEnumerable.Where extension method on a collection class someone else wrote, BUT I didn't realize the other developer had included a .Where regular method that returns an IEnumerable. My code will compile superbly without any warnings. The best part is that this code will work for months until THE CONDITION that differentiates the developer's .Where method and the LINQ's .Where method occurs. On Object Orientedness: Developer A uses List.SingleOrDefault() extensively, developer B creates a new class derived from List but would like .SingleOrDefault() to work a little differently so that all the pre-existing code will work properly with objects derived from his new class. He's stuck. :(
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry
There are so many things wrong with extension methods that I *still* get baffled how the geniuses at M$ included that as a feature. I guess LINQ must have been a HUGE thing for every team to bend their libraries and languages to 'force' it to fit in. I just want the option not to use it or make me use it in the "good way". This is just like the way you could set option strict in classic VB. Luckily almost all Microsoft extension methods come with in their exclusive namespaces. So all I have to do now is not include those namespaces BUT that doesn't prevent some other genius at XYZ company to pack extension methods with regular methods in their libraries and forcing ME to write bad code. Chip on my shoulder :)
Sunny Ahuwanya "The beauty of the desert is that it hides a well somewhere" -- Antoine de Saint Exupéry