Collection Templates 2.0 released

Chris,

I'm OK with removing the sync wrappers. I know I voted for keeping them, but it's really not that big of a deal to use a seperate lock. I'm a fan of simplifying things as well so I will most likely update to this version in the 2.6 release.

I am wondering if you could get rid of all the virtual methods then you would get another substantial perf improvement, correct? It looks like the only reason they are still there is for the read only wrapper. Maybe that could be a immutable flag when creating the collection?

Also, I have some feedback for you. I'd like to see you move to a code-behind model rather than the include model you are currently using for your CommonScript.cs file. If you take these methods and create a real class that inherits from CodeSmith.Engine.CodeTemplate and then in your CodeTemplate directive in your templates set the Src= attribute to your .cs file and the Inherits= attribute to the name of the class in the CommonScript.cs file then I think that is a much cleaner solution than having a .cs file that can't be opened in VS.NET. Let me know what you think.

Thanks,
Eric J. Smith

Eric,

The read-only wrapper unfortunately has to remain a wrapper; that is, we must have a writable collection that accesses the same data. I haven't yet figured out how to do this without overrides, or how to do it efficiently at any rate. If I used a completely separate collection class I'd have to duplicate all the read access properties & methods which isn't very appealing.

I'm afraid you're losing me with your next paragraph. You're talking about code-behind, and I don't even know what that means. Seriously. I think it's a web programming term, and I'm not familiar with that stuff. All I want is to instantiate templates from the command line, and without requiring the use of Visual Studio at all. The resulting .cs file should be static and completely self-contained.

Honestly, CodeSmith is a great tool but I don't understand 90% of the discussions on these forums, or the VS integration features of CodeSmith itself for that matter. I really would appreciate if someone else could take the "official" maintenance of the collection templates off my hands, with code-behind and web programming and databases and all that new-fangled stuff. And I could just release my own Neanderthal command-line templates every once in a while. :)

Cheers, Chris

Chris,

Could you have a read only flag on some of the constructor overloads that take an initial set of data for the collection and then mark the collection as read only? Also, maybe you could have some static factory methods to create read only collections based on a given collection of the same type or a strongly typed array. I would think that you would want to do something like this to create your read only collection:

SomeObjectCollection writableCollection = new SomeObjectCollection();
writableCollection.Add(someObject1);
writableCollection.Add(someObject2);
SomeObjectCollection readOnlyCollection = new SomeObjectCollection(writableCollection, true);

I would think you would just need to have a immutable read only flag in your collection that can be set during construction and then it can't be changed. I'm probably missing something though.

As far as the second part of my post, there is no need to think about it as a web programming thing. Basically what you are doing is creating a template that inherits from your special class and therefore gets access to the extra methods it provides rather than simply including a class fragment into your template like you are currently doing. So your CommonScript.cs would become a fully fledged .NET class file and then you would setup your template to automatically compile that class along with your template and to also inherit from that class rather then inheriting from the default CodeSmith.Engine.CodeTemplate class. So basically you are introducing a layer of inheritance between your template and the base CodeSmith.Engine.CodeTemplate class and therefore getting access to all methods contained in that class. Here is what your CodeTemplate directive would look like:

<%@ CodeTemplate Language="C#" TargetLanguage="C#" Src="CommonScript.cs" Inherits="CommonScript.SomeClassName" Description="Generates a strongly typed ArrayList collection." %>

I don't think your collections are Neanderthal at all. I think they are quite awesome. I can understand if you don't want to maintain them anymore though. I can certainly take over their maintenance if you like, but I am hoping to not have 12 flavors of collection templates all over the place. I'd rather have one really good set of collection templates and when it makes sense to add something to them to make them better, then we can do that. It's up to you, if you would like me to take over their maintenance, I can certainly do so.

Thanks,
Eric J. Smith

PS: In view of the upcoming .NET generics, I would also advise you not to put too much work into the Collection Templates either. The new Framework will contain generic versions of all collections, and there's a separate work group called "Power Collections" whose goal is to devise new and better collection classes.

I don't think it will make sense to use CodeSmith for a task that is more than adequately served by the Framework itself. As the other (much livelier!) forums indicate, CodeSmith is most popolar for its web and database programming capabilities. These areas are not likely to be handled adequately by .NET 2.0 so IMO it would make sense to focus and them, and drop the collections when generics become available.

Chris,

I absolutely agree. Generics in .NET 2.0 are definately an awesome feature and I for one will be making MUCH use of them. Since .NET 2.0 is still probably a year away and then probably another year or so for everyone to migrate to it, I think there will be a need for these templates for a while still. But they're definately not something that I am planning to spend a lot of time on.

Thanks,
Eric J. Smith

Hi Chris,

Have you ever thought of having the I<T>Enumerator interfaces inherit from System.Collections.IEnumerator, having Current : object and and <T> : <T> properties?
Some thoughts:
- Current<T> : <T> would do if having the type name as a property name is a pain.
- IDictionaryEnumerator follows this approach, where it's Current property is inherited from IEnumerator and it has a separate Entry property.
- Being able to cast to System.Collections.IEnumerator is a big plus.
- I guess once you start down this path, you would have all the interfaces inherit from the System.Collections equivalents. Does this sound like a good idea?
- You can more easily implement what I've had to do, but are yet to include them in any template. That is, a list that implements its item's parent class list interface.

Cheers,
Ben

Ben,

As a matter of fact, all instances of any I<T>Enumerator interface already implement IEnumerator as well.

That's because any return type for the I<T>Enumerator.Current property also satisfies the IEnumerator.Current property. If you look at the IEnumerable.GetEnumerator implementations for the various collections, you'll see that they simply cast the I<T>Enumerator instance to IEnumerator. So this is already possible.

You could also implement I<T>Enumerator the way you describe, but then you wouldn't get automatic strong typing with drop-in compatibility.

As far as I'm aware C# cannot "narrow" an interface definition, so there's no way to derive I<T>Enumerator from IEnumerator while maintaining the current instance compatibility.

Does that answer your questions? I'm not sure what you were referring to in your last paragraph.

Cheers, Chris

Ben, the "drop-in" requirement is that you get strong typing without changing your code. You just write Current, swap your ArrayList for the template, and recompile. Now Current will produce the correct type automatically.

This is very important for value types. When you do a foreach loop over a value type collection, the compiler auto-generates Current accesses which are then typecast to the desired element type if necessary. In your proposed implementation, Current would return an Object. That means the value type would be boxed, then unboxed again. That's extremely expensive if you don't do much else in the loop.

Chris,

I see the requirement for "drop-in" functionality from a code management point of view.

Re. the compiler. Are you saying that if you have a "public I<T>Enumerator GetEnumerator()" method and a "IEnumerator IEnumerable.GetEnumerator()" method, the C# compiler will use the former in a foreach statement? And again if you have a "public <T> Current" property and an "object IEnumerator.Current" property, it will use the former?

If so, then there is a definite performance loss in having different property names. Does that not also suggest that enumerating over dictionary elements (DictionaryEntry structs) is sub-optimal in .Net?

Casting I<T>Enumerator instances to IEnumerator is a general polymorphic requirement, ie I have functions that work on generic enumerators. This is for business objects, which are reference types (so therefore no boxing hit). I find enumerators useful when querying subsets of a large collections.

Re. "list inheritance", it's only up-casting (casting to parent classes/interfaces) that I'm interested in. I'll extend the previous example to illustrate the need for this at the list level:
- CricketTeam inherits from Team, and Cricketer inherits from Player
- The Team class has a "IPlayerList Players" collection, and a number of related operations.
- The CricketTeam class has a "ICricketerList Cricketers" collection, and a number of related operations.
Now the CricketTeam.Cricketers association needs to override the Team.Players collection, and to do that the CricketTeam class needs to tell the Team class "this is my player list", and that player list needs to realise IPlayerList. Assuming we do wan't strong typing, this can either be done via a wrapper which up-casts on reading and down-casts on writing, or if the CricketerList implements IPlayerList itself. Thus far I have modified your templates to do the latter.

Interesting discussion thus far!

Yes!  If there are public GetEnumerator and Current methods, the compiler will use them and ignore the explicit interface implementations.  Pretty cool, isn't it?