ScanIAm wrote:

Exactly, and I'm fine with that, now, but it doesn't 'feel' right.  That's my own cross to bear

string s = "bob";
if(s!=null)
   Console.WriteLine(bob.Length);

just seems safer.

Curt Nichols wrote:

...

[Edge case ahead.]

Now, in the case of

    new MyObject().LongRunningMethod();

the instance of MyObject may be garbage collected before LongRunningMethod returns. This usually doesn't cause a problem, but it can; to cause a problem usually involves a questionable design decision (e.g., a disposed MyObject cleans up a field, and this happens to occur after LongRunningMethod's last reference to your MyObject instance but before using a locally stored reference to that field). I can make it happen but I don't expect to see it in the wild.

corona_coder wrote:

Of course, Mac OS X based on Unix, Windows not.  Linux is still safer than both.  What I like is how the anti-virus guys trying to spread the FUD.

the fact that the compiler doest't isues a warning for my class, it can just as easily isue a warning if it gets implemented ...

the code works even it's just a warning , something to be aware of. and if you instantiate a
Snapshot<SnapshotBase>  sn = new Snapshot<SnapshotBase>() you should be fully aware of the fact that you're using the instantiated' class methods primarely or if you want to use the base class' methods you can cast. Or maybe there's anothe way around this to be sure all of the time what method you are calling.

Maybe generic clases that extend other types should't even be allowed to have non virtual or non explicit interface methos. The best way can found to solve this.

But I don't see why generics cand be brought to the next level by parametrising more of their elements.

Generics started a new programing paradigm parametrisable code. And it should keep evolving and not stop right here.

I' dont see any benefits from stoping.

using System;

using System.Collections.Generic;

using System.Windows.Forms;

namespace Testing {

static class Program {

static void Main(string[] args)

{

      BaseClass bc = new Class2();

      bc.Write();

     ((Class2)bc).Write();

      Console.ReadKey();
}
}
public class BaseClass {
   public void Write() {
      Console.WriteLine("1");
   }
}
public class Class2 : BaseClass {
   public void Write() {
      Console.WriteLine("2");
   }
}

}

Results :

1
2

[EDITED]

leeappdalecom wrote:

wait it's all just made sense now lol

Inherit and extend the capabilities of different types using generics rather than extending every type you have created and it still be the same type of object in the end.

leeappdalecom wrote:

Ok i think i see what your saying. One thing springs to mind how would you store these snapshot objects without a container object?

If you modify your enitity to be a container then it wont be an entity anymore.

I dont see why you cant use the BindingList<> class to do something similar.

(tell me if i totally got the wrong end of the stick lol)

leeappdalecom wrote:

This is something like recursive generics lol

Your saying a container class that is the same type as the type it consumes?

I dont actually see a use for this apart from recursively creating a data structure that can consume itself.  Why would you need this?

TomasDeml wrote:

AndyC wrote: You can solve this sort of problem with Multiple Inheritance, C# doesn't support this although the CLR does. I think only C++ provides it at the moment.

What? CLI (and IL) supports multiple inheritance? Since when? If I missed something, correct me...

dwoodard wrote:

Unless you are using SSL, you realize that this is not secure? A hacker wouldn't need to do anything but capture the hash and that would be as good as having the password itself.

{

string toEncode = "This will be base64 encoded!";

string encoded = Convert.ToBase64String(System.Text.Encoding.Default.GetBytes(toEncode));

Console.WriteLine(encoded);

}


Be sure to have the same Defaul Encoder where you decode the string

class MyClass : string {  // not legal 'String' is sealed class
}
VS Error :
"Error 1 'Testing.MyClass': cannot derive from sealed type '"

so should be :

MyClass<String> instance; 


I don't see any where your objections are coming from.

I dind't try to sugest a way to break encapsulation but a way to construct a generic type that subclases another type at use time.

And I'm not sugesting any new features or anithing that can't be done with curent language and platform features

         - in the first case the same implemetation must be done for every new type (Copy code)

         - in the second case the ineritance chain is lost so the container type can't be used in place o the actual type.

Other useful usages caul be somethin like DataTable<Person> or DataTable<Company> where the DataTable<> type ads an ItemArray property, and RowVersionPropery etc. an actualy makes extens the class so it can be added to an datatable ...

Anyone else had those kind of ideeas before?