vslangfutures Forum Rss Feed

NEW POST: Future Focus: Document Map Margin

Rykie — Thu, 22 Oct 2009 02:04:02 GMT

Ok, I love this, but can somebody please tell me how to enable it in my VS 2010 B2. For the love of this product, I cannot see how to enable/install it!

NEW POST: optional keyword for interfaces

JamesCurran — Fri, 18 Sep 2009 21:01:33 GMT

Wait a minute, I forgot that OptionalMethod, if implemented could throw an exception, which we don't want to lose.

IMyInterface obj = GetAnIMyInterfaceObject();
obj.NotOptionalMethod();
try
{
obj.OptionalMethod();
}
catch(NotImplemetedException nex)
{}
catch(Exception)
{
throw;
}

And if that's not example enough, consider if there were three optional method in that interface. For my technique, it's just:

obj.NotOptionalMethod1();
if(obj2 != null) obj2.OptionalMethod1();
obj.NotOptionalMethod2();
if(obj2 != null) obj2.OptionalMethod2();
obj.NotOptionalMethod3();
if(obj2 != null) obj2.OptionalMethod3();

Try duplicating that with try/catch.....

NEW POST: optional keyword for interfaces

JamesCurran — Fri, 18 Sep 2009 16:39:48 GMT

>> . You are saying that if I'm using some new feature of the language, I'll destroy the point of the base of that feature.

Of course I'm not. You are not merely adding some new feature, you are changing the way an existing feature works. A more relevant example would be to ask that this would work:

var i = 0;
i = "Hello, World";

In the first line, i is an int regardless of whether you use "var" or "int". However, to allow the second line to work, you must change the very definition of what it means to be an int. No one could ever again trust an int to be an int, even if they didn't use that new feature. Which brings us to you major point:

>> If you will not going to use this keyword, you'll still have the same "fixed " contract.

No I don't. The purpose is interface isn't for classes that I implement & use --- They are for classes implemented by one person and used by another. If you were to give me a class that you wrote and tell me that it implements IMyInterface, then I have the right to assume that it implements ALL of the interface. But with your proposal, I can no longer do that. Every place I use OptionalMethod(), I now have to wrap in in a try block to catch a potenial NotImplemetedException. The POINT of interfaces is knowing that the implementation is there without having to worry about that. (Which is why I said that using NotImplementException is cheating--- An interface method should NEVER throw NotImplementException; the method should be implemented)

I think the best way to show the problem is with an example of use:
Task: Given an object which implements IMyInterface, call NotOptionalMethod(), and, if present, OptionalMethod():

Your plan, with optional members:
IMyInterface obj = GetAnIMyInterfaceObject();
obj.NotOptionalMethod();
try
{
obj.OptionalMethod();
}
catch {}

My plan, with two interfaces:

IMyInterfaceBasic obj = GetAnIMyInterfaceObject();
obj.NotOptionalMethod();
var obj2 = obj as IMyInterfaceExtended;
if (obj2 != null)
obj2.OptionalMethod();

Which is easier to read & understand? which will run faster?

NEW POST: optional keyword for interfaces

eusebiu — Fri, 18 Sep 2009 11:50:06 GMT

Well James, maybe this is why I don't "like" interfaces. Because they are "fixed" contracts. :)

But I don't understand why are you keep saying that this keyword will destroy the point of interfaces. If you will not going to use this keyword, you'll still have the same "fixed " contract. You are saying that if I'm using some new feature of the language (let's say declaring a variable using var) I'll destroy the point of the base of that feature(e.g. declaration of an int. I can easily write var i = 0; of cource I can write int i = 0;)

Thowing the NotImplementedException is not cheating. It's a fact! If you try to invoke a method at run-time of an object that has no implementation of that method, you will get an exception - it's real life, it's a fact!
Regarding your example with two interfaces (don't get me wrong, I have nothing against interfaces... they are usefull in some cases, in other cases abstract classes are the way to go)... maybe I don't need to implement all methods exposed by an interface. Of course, I could use two interfaces as a workaround - no objection to that. If you want to implement only OptionalMethod(), what would you do? Create a third interface that implements both interfaces to ensure both OptionalMethod and NotOptionalMethod functionalities...

Anyways, thanks for posting! :)

NEW POST: optional keyword for interfaces

JamesCurran — Thu, 17 Sep 2009 18:31:01 GMT

So, basically, "optional" is a marker, telling the compiler to generate a simple method for those members which do not provide one. That's probably better handled with an attribute than with a keyword, but you still have the fundelmental problem.

The point of interfaces is to have a fixed contract. Technically, having a interface method that throws NotImplementedException is cheating.

As I user of a class which implements IMyInterface, I want to avoid calling a method which will throw a NotImplemented Exception. How could I know that under your proposal. In theory, if a class implements IMyInterface, then I should know with certitude that all it's methods are implemented. That is the purpose of interfaces, and your purposal destroys that.

OTOH, using two interfaces, I know immediately (using a simple test, built into the language) that MyClass2 implements OptionalMethod while MyClass1 does not.

What is your opposition to using two interfaces??? (They're FREE! Use as many as you want!)

NEW POST: optional keyword for interfaces

eusebiu — Thu, 17 Sep 2009 17:18:30 GMT

First of all, thanks for posting...

@danielerwicker: If you call an optional method that has no implementation in the class, a NotImplementedException() will throw. Of course, you can write classes that implements the optional method too.

@JamesCurran: I don't think it will destroy the point of interfaces. This keywork will allow interfaces to be more extensible (in my opinion! :) ). And I will use only one interface... not two!

NEW POST: optional keyword for interfaces

JamesCurran — Fri, 11 Sep 2009 14:33:47 GMT

I fail to see a problem that would to solve, and as daniel points out, causes new one. (it would, in fact, completely destroy the point of interfaces, which are a fixed contract of members provided)

This could very easily (and safely) been done today --- by just using two interfaces:

| interface IMyInterfaceBasic
| {
| void NotOptionalMethod();
| }

| interface IMyInterfaceEnhanced : IMyInterfaceBasic
| {
| void OptionalMethod();
| }

| public class MyClass1 : IMyInterfaceBasic {..... }
| public class MyClass2 : IMyInterfaceEnhanced {..... }

NEW POST: optional keyword for interfaces

danielearwicker — Fri, 11 Sep 2009 12:30:56 GMT

What would happen if I called an optional method that the class did not implement?

NEW POST: optional keyword for interfaces

eusebiu — Thu, 03 Sep 2009 10:54:02 GMT

Wouldn't be nice if C# had a optional keyword for the methods/properties in an interface?
interface IMyInterface
{
optional void OptionalMethod();

void NotOptionalMethod();
}

public class MyClass1 : IMyInterface
{
public void NotOptionalMethod()
{
//implement the method...
}
}

public class MyClass2 : IMyInterface
{
public void NotOptionalMethod()
{
//implement the method...
}

public void OptionalMethod()
{
//implement the method...
}
}

NEW POST: parent Keyword in C#

danielearwicker — Sat, 13 Jun 2009 09:08:18 GMT

This is basically the same thing as inner classes in Java, also known as non-static nested classes. The compiler automatically adds a reference to the outer class, and ensures that it is initialised in construction (as long as the 'new' happens inside a method of the outer class).

C# already has something more powerful along the same lines: general closures. You can write an anonymous method and it can refer to anything visible in the context it refers to. Java's inner classes are like a poorer version of this.

NEW POST: parent Keyword in C#

JamesThomas — Thu, 28 May 2009 22:21:33 GMT

I was working on some class structures over the past couple of days and it occurred to me that it would be extremely nice if a member class could directly impact the parent without the need to pass in a reference to the parent, like this:

public class x
{
public void DoSomethingToParent()
{
parent.DoSomething(); // OK
parent.DoSomethingElse(); // NOT OK - method not exposed (see below)
}
}

public class y
{
private x m_x;

public y()
{
x.DoSomethingToParent();
}

ExposeToMemberClass
public void DoSomething()
{
return "Hello World";
}

public void DoSomethingElse()
{
return "Can't use me with parent keyword";
}
}

If the method isn't exposed to member classes, then it can't be called from within the member class. Constructors couldn't be exposed and neither could private methods/properties/etc.

Simple enough request - just occurred to me today. Would make things simpler in my opinion.

Thanks,

James

NEW POST: C# native tuple support?

rendle — Tue, 19 May 2009 11:18:02 GMT

Wow. Loads of Tuples.

http://msdn.microsoft.com/en-us/library/dd383325(VS.100).aspx

No syntactic sugar, but never mind.

NEW POST: Call Hierarchy

dan20 — Mon, 11 May 2009 17:18:46 GMT

In reply to your Furture Focus posting on Call Hierarchy:

> How would you like to see us integrate the Call Hierarchy into the Call View, Object Browser, or other parts of the IDE.

I definitely have a integration suggestion I do not yet see discussed in this thread.

It has been my practice the last 16 years to represent the call hierarchy within the (released) source code comments in method headers, for methods (many or most of them) having at most several callers and up to some maximum depth, like several levels above. This way, the comment addresses the second of these most important questions to the reader: What is to occur? How did I get here? What special considerations should I have in mind? I have found my code maintainability substantially enhanced by having the call hierarchy in the comments, though the presence there would be enhanced by tool support to keep the hierarchy current as the code evolves. Like my internal documentation, my preference is to embed this information in the code comments where it is significantly more likely to be referenced than if a tool action is required in order to view it, and where it will be included and appropriately placed in print outs of the code.

As mentioned, I am well aware approaches to include the call history in the code comments will have limitations and not be workable for all cases. My point is rather the frequent cases where it is quite viable, and greatly promotes readability / maintainability. An imperfect approach that would be often usable, would be extremely helpful. Of course, a condensed representation would be the greatest help in this usage. For example, in my hand notation of the call hierarchy, I use where practicable a (nestable of course) comma delimited list of callers to a common child level. This is the type of thing however where discussion of representation could be paralyzing to delivery of the feature: just have the designer pick a reasonable representation appropriate for use within code comments and run with it. I do think if you agree with the basic feature, an additional comment type such as "called by" would be appropriate.

Thank you for your consideration and discussion toward supporting call hierarchy within source comments, and for all your fabulous work (I get 10 times more done now thanks to your great tools, and I am looking forward to another 10x boost from you in the foreseeable future).

NEW POST: Static Extension Methods

avalon — Wed, 04 Mar 2009 10:40:38 GMT

//sorry double post

NEW POST: Static Extension Methods

avalon — Wed, 04 Mar 2009 10:40:35 GMT

I think this should be possible aswell.
I was looking for a static Copy() method in the Directory class but couldn't find any so decided to add it as an extension.
But because an extension can only be added to a non-static class I had to add it to the DirectoryInfo class.
Now everytime I want to copy a folder, I have to create an instance of the DirectoryInfo class and use my Copy extension.

Extending a static method to a static class would make this sooo much nicer!
Why isn't this possible?
And I don't want the 'create your own class' response, the Directory and DirectoryInfo classes are sealed.

here's my extension code:

    public static class DirectoryInfoExtensions
    {
        public static bool Copy(this System.IO.DirectoryInfo dir, string SourceFolder, string DestinationFolder)
        {
            if (!Directory.Exists(DestinationFolder))
                Directory.CreateDirectory(DestinationFolder);
            string[] files = Directory.GetFiles(SourceFolder);
            foreach (string file in files)
            {
                string name = Path.GetFileName(file);
                string dest = Path.Combine(DestinationFolder, name);
                File.Copy(file, dest);
            }
            string[] folders = Directory.GetDirectories(SourceFolder);
            foreach (string folder in folders)
            {
                string name = Path.GetFileName(folder);
                string dest = Path.Combine(DestinationFolder, name);
                Copy(dir, folder, dest);
            }
            return true;
        }
 
    }

NEW POST: AOP support in c# v4

Sharas — Mon, 09 Feb 2009 21:02:46 GMT

Hi,

Not sure this is the right place, but I would like to know will proper aspect oriented programming be supported in c# v4? By proper I mean unintrusive AOP with pointcuts separately defined and configurable, not just attributes applied directly to target types or methods.

Regards,

Sharas

NEW POST: C++ style arithmetic conversions

JeremyAtGosub — Wed, 10 Dec 2008 21:42:32 GMT

A better way to implement this (without adding new constructors to the built in types) is to have the compiler use conversion operators as well as constructors:

int i = int(Math.sin(a)*100);

When the compiler sees "int" (or "new int"), it first looks for a constructor. Finding none, it looks for an implicit conversion operator. Finding none, it uses the explicit double to int conversion operator.

-Jeremy

NEW POST: C++ style arithmetic conversions

JeremyAtGosub — Wed, 10 Dec 2008 20:35:49 GMT

One of my pet peeves is having to use a cast to convert between simple types, like this:

int i = (int)(Math.sin(a)*100);

I propose we do two things that will make the code easier to read. First, add constructors to the built in types that can convert. This allows:

int i = new int(Math.sin(a)*100);

Second, make the "new" keyword optional when creating a struct. Keep the "new" keyword mandatory for classes. This allows:

int i = int(Math.sin(a)*100);

I'm not sure how much code this would break, but I bet the compiler can figure it out 99.9% of the time (and flag it as an error in the other 0.1%)

Another problem with the base classes is that many of the struct types don't define the math operators and conversions. Many times, I find myself wishing I could use operators on them:

Point p = myOldPoint + myCalculatedPoint*2;

-Jeremy

NEW POST: I want Spec# (and Boogie)

Coder — Thu, 04 Dec 2008 15:33:06 GMT

I saw that, and was greatly pleased. It's going to make our testing cycle even more fun.

NEW POST: I want Spec# (and Boogie)

mstrobel — Wed, 03 Dec 2008 18:33:26 GMT

Microsoft Research has created a Code Contracts library for .NET (http://research.microsoft.com/contracts/). As a standalone framework, it can be used from any .NET language (not just C#), and it also includes compile-time static analysis similar to what was introduced in Spec#.

I believe this library will be integrated into the .NET Base Class Library in v4.0.