Delphi 2007 Language Feature: Generics
Rod
I have made an example of the upcoming Generics syntax in Delphi 2007
for Win32 & .Net. It is being inspired a little from Nicks video.
type
TList<AnyType> = class
FList: TList;
procedure Add(Item: AnyType);
function Extract(Item: AnyType): AnyType;
end;
procedure TList<AnyType>.Add(Item: AnyType);
begin
FList.Add(TObject(Item));
end;
function TList<AnyType>.Extract(Item: AnyType): AnyType;
begin
Result := FList.Extract(TObject(Item)) as AnyType;
end;
type
TComponentList = TList<TComponent>;
TIntegerList = TList<Integer>;
TFloatList = TList<Extended>;
var
ComponentList: TComponentList;
IntegerList: TIntegerList;
FloatList: TFloatList;
begin
ComponentList := TComponentList.Create;
ComponentList.Add(Form1);
...
IntegerList := TIntegerList.Create;
IntegerList.Add(1234);
...
FloatList := TFloatList.Create;
FloatList.Add(3.14);
...
end.
TObject
Mark Andrews (The Other One)
very interesting to me.
Is there a problem with the following declarations?
> function TList<AnyType>.Extract(Item: AnyType): AnyType;
> begin
> Result := FList.Extract(TObject(Item)) as AnyType;
> end;
>
>
> type
> TFloatList = TList<Extended>;
Extended is greater than 32 bits but you are casting it to a 32-bit
value in the Extract method. Is this intended?
Cheers,
Mark.
Rod
Markus.Humm
thanks for this short introduction.
I always wondered what generics are but hand't yet foudn the time to
look it up. Now I know some basics.
Greetings
Markus
TObject
"Michael C." <Mic...@Anonymous.net> wrote in message news:45ad...@newsgroups.borland.com...
> > Semasiologically, I would recommend replacing "AnyType" with "AType" or "T"
>
> I actually like AnyType better because it emphasizes plurality.
>
Your old trusty TList is a list of any type.
The beauty of generics is in type safety: your generic list is not a list of any type; it is a list of a type.
Michael C.
> Semasiologically, I would recommend replacing "AnyType" with "AType" or "T"
>
>
I actually like AnyType better because it emphasizes plurality.
Rod
correct.
IntegerList := TIntegerList.Create;
IntegerList.Add('Nick');
won't compile!
Chris Morgan
> function TList<AnyType>.Extract(Item: AnyType): AnyType;
> begin
> Result := FList.Extract(TObject(Item)) as AnyType;
> end;
...
> TIntegerList = TList<Integer>;
...
> IntegerList: TIntegerList;
...
> IntegerList := TIntegerList.Create;
> IntegerList.Add(1234);
Will the 'as' cast work with an integer type?
Cheers,
Chris
Rod
I have seen that in the video.
Up to now I have no Delphi 2007 on my PC ;-)
Chris Morgan
>>
>
> Up to now I have no Delphi 2007 on my PC ;-)
So 'as' is being extended to work like a regular hard typecast?
Or will it just work work in this new way in
generic class methods?
Or does it involve intrinsic boxing of native types
into objects, like Java integer to Integer conversions?
Cheers,
Chris
Chris Burrows
news:45ad...@newsgroups.borland.com...
> Rod, I know nothing of, and have read nothing on, generics so this looks
> very interesting to me.
>
I was in the same boat as you until a few days ago when I found a very
thorough and understandable explanation in a chapter titled 'Generics' from
the book 'Essential C# 2.0" by Mark Michaelis. You can download a copy of
the whole chapter from:
http://mark.michaelis.net/essentialcsharp/
For those who are familiar with the similar, but different, feature of
templates (e.g. as in C++), this document does a good job of highlighting
the differences between them.
I'd be interested to know if Win32 D2007 is going to include all of the
Generics features detailed in this chapter or just a subset? There may well
be some aspects that are not applicable to Win32 - I don't know.
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp
Mark Andrews (The Other One)
> I was in the same boat as you until a few days ago when I found a very
> thorough and understandable explanation in a chapter titled 'Generics' from
> the book 'Essential C# 2.0" by Mark Michaelis.
Cool. Thanks, Chris. I've downloaded the chapter and will read it.
Cheers,
Mark.
Robert Giesecke
>
> I'd be interested to know if Win32 D2007 is going to include all of the
> Generics features detailed in this chapter or just a subset? There may well
> be some aspects that are not applicable to Win32 - I don't know.
>
Hmm... I think _native_ Delphi can go even further with generics than what is possible in .Net.
In .Net, you can have a constraint, that a type parameter must have a public constructor w/o parameters.
Since Delphi is not only an IDE or a language, it has also its own RTL. Basically it could be possible to enforce T
to have a specific constructor signature, or more than one.
Maybe even constraints that require the type to have certain operators, combined with some sort of slots in the
precompiled generic to be filled with the actual operators.
Bob
>
> http://mark.michaelis.net/essentialcsharp/
>
> For those who are familiar with the similar, but different, feature
> of templates (e.g. as in C++), this document does a good job of
> highlighting the differences between them.
>
> I'd be interested to know if Win32 D2007 is going to include all of
> the Generics features detailed in this chapter or just a subset?
> There may well be some aspects that are not applicable to Win32 - I
> don't know.
I havent read the article yet, but in reading this post, a thought
crossed my mind. When you create the "template" code for your generic
class, you have AnyType which could be anything. For simple classes
this is fine, but for complex classes, I can imagine needing to
possibly make decisions on what AnyType is and have the code act
differently. Would it be possible to do something like:
if AnyType is string then
DoSomethingStringSpecific;
--
Eric Grange
[...]
> Result := FList.Extract(TObject(Item)) as AnyType;
Boxing? Isn't the whole point of genericity to be able to avoid boxing in the
first place?
Eric
Joanna Carter [TeamB]
45add06f$1...@newsgroups.borland.com...
Absolutely. This has to be the worst possible example of how to implement a
generic list class; especially since you could use the
System.Collections.Generic.List<T> class. The example could, at least, have
used a typed array, even if that meant handling the resizing; in fact, that
is what the .NET library uses.
I guess for some Delphi coders, old habits die hard :-)
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Joanna Carter [TeamB]
45ad9790$1...@newsgroups.borland.com...
| I havent read the article yet, but in reading this post, a thought
| crossed my mind. When you create the "template" code for your generic
| class, you have AnyType which could be anything. For simple classes
| this is fine, but for complex classes, I can imagine needing to
| possibly make decisions on what AnyType is and have the code act
| differently. Would it be possible to do something like:
|
| if AnyType is string then
| DoSomethingStringSpecific;
If you have to do this kind oif thing, then you have not designed your
generic clas correctly. the whole point of a generic class is that it will
work with *any* type within the constraints set in the definition of the
class.
e.g. (C#)
class MyClass<T> where T : struct
{
// works with any value type - int, double, struct type
}
class MyClass<T> where T : class
{
// works with any reference type - AClass, BClass, etc
}
class MyClass<T> where T : MyBaseClass, IMyInterface
{
// works with any derivative of MyBaseClass and IMyInterface
Joanna Carter [TeamB]
45ad...@newsgroups.borland.com...
| Hmm... I think _native_ Delphi can go even further with generics than what
is possible in .Net.
| In .Net, you can have a constraint, that a type parameter must have a
public constructor w/o parameters.
| Since Delphi is not only an IDE or a language, it has also its own RTL.
Basically it could be possible to enforce T
| to have a specific constructor signature, or more than one.
| Maybe even constraints that require the type to have certain operators,
combined with some sort of slots in the
| precompiled generic to be filled with the actual operators.
Before Delphi for Win32 can support generics, it will need to, at least,
support somewhere near the depth of reflection that .NET gives. I often need
to construct instances of bound generic types at runtime and this requires
more metadata than Delphi for Win32 can presently provide.
class MyGenericClass
{
...
}
class MyGenericClass<T> : MyGenericClass
{
...
}
class Customer
{
...
}
{
Type genericType = typeof(MyGenericClass<>);
Type[] bindingTypes = new Type[] { typeof(Customer) };
Type customerListType = genericType.MakeGenericType(bindingTypes);
Type[] ctorParamsTypes = new Type[] { typeof(string) };
ConstructorInfo ci = genericType.GetConstructor(ctorParamTypes);
object[] ctorParams = new object[] { "Hello World" }
MyGenericClass mgc = ci.Invoke(ctorParams);
...
}
Somehow, I don't see the present RTTI coping with that :-))
Eric Grange
> support somewhere near the depth of reflection that .NET gives.
Supporting generics for all types known to be instanced at compile time
would be more than enough.
> I often need to construct instances of bound generic types at runtime
IMO this is a bit on the dangerous side. As all late-bound or runtime
evaluated/compiled logic does, it encourages coding patterns where what
could have been compile-time errors (cheap to fix) turn into runtime
errors (expensive to fix).
Eric
Joanna Carter [TeamB]
45adfb37$1...@newsgroups.borland.com...
| > I often need to construct instances of bound generic types at runtime
|
| IMO this is a bit on the dangerous side. As all late-bound or runtime
| evaluated/compiled logic does, it encourages coding patterns where what
| could have been compile-time errors (cheap to fix) turn into runtime
| errors (expensive to fix).
Nonetheless, within the bounds of a class factory or visitor pattern, this
kind of thing is very common and, provided sufficient testing is done, it is
safe.
Eric Grange
When the cat is out of the box, it's out of the box... You can only
enforce the "within" by code reviews, ie. extra $$$.
> provided sufficient testing is done, it is safe.
In other words: it's intrinsically unsafe, and making it safe involves
extra $$$.
QED ^_^
Eric
Robert Giesecke
Well, I think the OP didn't think long enough before posting his code. ;-)
TList handles pointers, not TObject. *g*
This won't work at all for reference counted types like AnsiString.
(The pointer inside the TList won't prevent the Removal of the String)
A relatively safe way to do it would be to start a new container from scratch using a dynamic array of T to hold the instances.
Basically reinventing TList with T instead of Pointer.
btw: There's no boxing in native Delphi. *g*
And if he meant Delphi.Net, then holy shi**: Why not using List<T>? 8-0
Lars Fosdal q
I like the idea of generics, but there is one challenge that I don't
see how they intend to solve. Most lists that I use, are not just
simple arrays or chains - but they typically would be sorted or
filtered on some criteria.
How do you make a sortable generic list? How do you decide on what to
sort on?
mamcx
> sort on?
Making a comparator. For example:
function Compare(a,b:AnyType)
begin
if a<b then Return 1 else Return 0;
end;
Something like that...
Joanna Carter [TeamB]
6u5sq2dr5l73q8f5c...@4ax.com...
| I like the idea of generics, but there is one challenge that I don't
| see how they intend to solve. Most lists that I use, are not just
| simple arrays or chains - but they typically would be sorted or
| filtered on some criteria.
|
| How do you make a sortable generic list? How do you decide on what to
| sort on?
In C#, you can use all sorts of methodologies, including the fact that
List<T> has a default Sort() method which sorts in ascending order.
static int ReverseIntegers(int x, int y)
{
if (x == y)
return 0;
if (x > y)
return -1;
else
return 1;
}
static void Main(string[] args)
{
List<int> intList = new List<int>();
intList.Add(6);
intList.Add(1);
intList.Add(10);
intList.Add(8);
// use the default sort
intList.Sort();
// or you can reverse the sort
intList.Sort(ReverseIntegers);
foreach (int i in intList)
Console.WriteLine(i);
Console.ReadKey();
Lars Fosdal q
comparators - but let's say that I want to make a list of TMyObject's
and either sort it on attribute X or attribute Y of TMyObject?
How do I let the generic container know that I want to search or order
on a specific attribute?
Lars F.
Gerrit Beuze
> the
> | first place?
> Absolutely. This has to be the worst possible example of how to implement a
> generic list class; especially since you could use the
> System.Collections.Generic.List<T> class. The example could, at least, have
> used a typed array, even if that meant handling the resizing; in fact, that
> is what the .NET library uses.
But what if this were Delphi Win32 generics ;-)
Sure the poster forgot about not boxing being one of the most
important things about generics, but System.Collections.Generic.List<T>
is not available in Win32 - is it?
Gerrit Beuze
ModelMaker Tools
Robert Giesecke
> OK, for basic types this is trivial since they have implicit
> comparators
No, generics don't cannot access operators or static other members in .Net.
The primitive types implement IComparable<T> (whereas T is the type itself), and that's how List<T> tries to do a default
sort. (Or more precise: that's how Comparer<T> does it)
function Compare<T>(const left, right : T) : Integer;
where T is IComparable<T>;
begin
Result := left.CompareTo(right);
end;
That's how a default comparison could work.
> - but let's say that I want to make a list of TMyObject's
> and either sort it on attribute X or attribute Y of TMyObject?
> How do I let the generic container know that I want to search or order
> on a specific attribute?
Using a delegate (or function pointer).
Here's another abstract sample:
type TComparison<T> = function(const left, right : T) : Integer;
function CompareMyClass(const left, right : TMyClass) : Integer;
begin
Result := left.SomeField - right.SomeField;
end;
var
list : TList<TMyClass>
begin
...
list.Sort(CompareMyClass);
Lars Fosdal q
TY, Robert - Excellent example.
I finally got it :) This looks promisng.
Lars Fosdal q
>Robert Giesecke <sp...@spam.spam> wrote:
>>function CompareMyClass(const left, right : TMyClass) : Integer;
>>begin
>> Result := left.SomeField - right.SomeField;
>>end;
>>
>>var
>> list : TList<TMyClass>
>>begin
>> ...
>> list.Sort(CompareMyClass);
>
>TY, Robert - Excellent example.
>I finally got it :) This looks promisng.
Some followup thoughts - If your list is polymorphic, this would still
require you to beware of mixing apples and pears, ie specific
comparisons will still require the programmer to ensure that he only
have decendants of TMyClass in the list, but that doesn't really
matter as you still can do the generic algorithims untyped.
I would probably prefer a design where you can assign the comparator
as early as possibly - maybe even with an implicit assignment based on
a default compare in TMyClass. I prefer that my lists (or hashlist,
tree, whatever) do sorted inserts.
How much of a speed penalty could we be looking at here? How many
indirections?
Eric Grange
I personally would hope that boxing will never be introduced to Win32 in
any standard form, variants already bring enough maintainance trouble.
Eric
Eric Grange
Yeah, and this actually made me worried, variants are already trouble
enough... I would rather see them buried than see any form of
runtime-only type-checking take over.
Eric
Bob Dawson
>
> How do I let the generic container know that I want to search or order
> on a specific attribute?
Constrain the AnyType that it must descend from a specific class, implement
a specific interface, etc.
See http://msdn2.microsoft.com/en-us/library/d5x73970.aspx
That gives you a typesafe ability to assume AnyType has what you need within
the generic class.
The .NET framework has a good number of very generic interfaces predefined
to let you do this sort of thing. In this case, you might want your object
to implement IComparable. Works very similar to defining a SortCompare
method in Delphi: the list just uses the ability of any two members to
return -1, 0, or 1, and sorts them based on that while itself staying
ignorant of the details.
bobD
Michael C.
> "Michael C." <Mic...@Anonymous.net> wrote in message news:45ad...@newsgroups.borland.com...
>
>>> Semasiologically, I would recommend replacing "AnyType" with "AType" or "T"
>> I actually like AnyType better because it emphasizes plurality.
>>
>
> Your old trusty TList is a list of any type.
Actually, I think of TList as list of pointers.
> The beauty of generics is in type safety: your generic list is not a list of any type; it is a list of a type.
Also, the elegance of a generic list is that it's
generic until it's declared as being specific.
If I were writing a generic list,
I would be writing it for use with many types.
That's why I would be using "AnyType" not "AType".
Robert Giesecke
> Some followup thoughts - If your list is polymorphic, this would still require you to beware of mixing apples and pears,
> ie specific comparisons will still require the programmer to ensure that he only have decendants of TMyClass in the list,
> but that doesn't really matter as you still can do the generic algorithims untyped.
Lets imagine you made your own container class, based on an internal array.
type
TList<T> = class
private
fArray : array of T;
fCount : Integer;
public
property Count...
function Add(item : T) : Integer;
property Item[index : Integer] : T ...
end;
You can manage the grow factory of that array and so on, bla bla...
Everything that is publicly accessible is fully type safe and even the internal array is.
Now you descend "real" type from this generic class:
type
TMyClassList = class(TList<TMyClass>)
end;
Doing this will "seal" all generic advantages to T = TMyClass.
Say you have TMyDescendant, which descends from TMyClass.
When descending a TMyDescendantList from TMyClassList you will face the very same things you have to do now when descending
from TObjectList.
There's one way to get a base class for TMyClass and its descendants, that can safely make assumptions of its element type.
Simply constrain T to be a TMyClass:
type
TMyClassList<T> = class(TList<T>)
where T is TMyClass;
end;
Now you can use all instance members of TMyClass without loosing the type parameter.
> I would probably prefer a design where you can assign the comparator as early as possibly - maybe even with an implicit
> assignment based on a default compare in TMyClass. I prefer that my lists (or hashlist, tree, whatever) do sorted
> inserts.
>
To add to the samples above: If TMyClass introduced a property "SomeProperty", you could write a default sorting in
TMyClassList<T>.
When using it this way:
var
list : TMyClassList<TMyDescendant>;
item : TMyDescendant;
begin
...
item := list[0];
list does not have anything typed to TMyClass, it only knows about TMyDescendant.
Hope I wasn't to abstract...
> How much of a speed penalty could we be looking at here? How many
> indirections?
>
Sorted inserts aren't exactly fast, as you know. Using generics or not.
And frankly, I don't know why a Hash list would be sorted. ;-)
Oh, and btw: I have not the slightest idea of how generic constraints would look like in Delphi.
What I wrote is kinda mixture between Chrome generic syntax and Delphi.
Joanna Carter [TeamB]
| OK, for basic types this is trivial since they have implicit
| comparators - but let's say that I want to make a list of TMyObject's
| and either sort it on attribute X or attribute Y of TMyObject?
static int SortCustomers(Customer x, Customer y)
{
return String.Compare(x.Name, y.Name);
}
static void Main(string[] args)
{
List<Customer> custList = new List<Customer>();
custList.Add(new Customer("Joanna"));
custList.Add(new Customer("Lars"));
custList.Add(new Customer("Nick"));
custList.Add(new Customer("Bob"));
custList.Sort(SortCustomers);
foreach (Customer cust in custList)
Console.WriteLine(cust.Name);
Console.ReadKey();
}
| How do I let the generic container know that I want to search or order
| on a specific attribute?
Usually by passing in a specific comparer, but there are other generic
interfaces and classes that help with this in the .NET framework as well.
Joanna Carter [TeamB]
45ae2b67$1...@newsgroups.borland.com...
| No, generics don't cannot access operators or static other members in
.Net.
|
| The primitive types implement IComparable<T> (whereas T is the type
itself), and that's how List<T> tries to do a default
| sort. (Or more precise: that's how Comparer<T> does it)
They also implement IEquatable<T> which can be very useful.
| function CompareMyClass(const left, right : TMyClass) : Integer;
| begin
| Result := left.SomeField - right.SomeField;
| end;
This can't work as arithmetic operators are not allowed on generic types
parameters
Christopher Ireland
| "Robert Giesecke" <sp...@spam.spam> a écrit dans le message de news:
| 45ae2b67$1...@newsgroups.borland.com...
|
| types parameters
You can "cludge" them though:
http://www.codeproject.com/csharp/genericnumerics.asp
--
Christopher Ireland
Robert Giesecke
>
> They also implement IEquatable<T> which can be very useful.
>
*Very* useful indeed. And being some sort of standard, there're a lot of types that implement those interfaces.
Not just the ones provided by MS.
> | function CompareMyClass(const left, right : TMyClass) : Integer;
> | begin
> | Result := left.SomeField - right.SomeField;
> | end;
> This can't work as arithmetic operators are not allowed on generic types
> parameters
Hah! Busted!
That method is not generic. :-P
Joanna Carter [TeamB]
45ae3220$1...@newsgroups.borland.com...
| Yeah, and this actually made me worried, variants are already trouble
| enough... I would rather see them buried than see any form of
| runtime-only type-checking take over.
The beauty of .NET metadata is that System.Object can be assigned any type,
so it is a sort of variant, but it is still strictly typed so that the
assigned value really is still a strict type. e.g. you cannot call a member
of the string class on an integer stored in an object variable. The .NET
compiler will complain about a lot more runtime "assumptions" than you would
get on pointers in Delphi for Win32.
Fortunately, generics really do remove a great many places where you might
be tempted to use System.Object as a prameter to a "generic" method. It is
unusual in well-written (not including some of the legacy .NET framework)
.NET 2.0 code to see a method that takes a System.Object parameter
Joanna Carter [TeamB]
45ae37b1$1...@newsgroups.borland.com...
| Lars Fosdal wrote:
| > Some followup thoughts - If your list is polymorphic, this would still
require you to beware of mixing apples and pears,
| > ie specific comparisons will still require the programmer to ensure that
he only have decendants of TMyClass in the list,
| > but that doesn't really matter as you still can do the generic
algorithims untyped.
|
| Lets imagine you made your own container class, based on an internal
array.
This really isn't necessary; List<T> is fine.
| Now you descend "real" type from this generic class:
|
| type
| TMyClassList = class(TList<TMyClass>)
| end;
Neither is this necessary as you can create an instance "sealed" or more
correctly bound list type just by declaring an instance of it bound to the
relevant type.
{
List<Person> custList = new List<Person>;
...
}
Now, assuming that Employee and Customer derive from Person, you are
perfectly free to add Employee and Customer instances to a List<Person>.
| There's one way to get a base class for TMyClass and its descendants, that
can safely make assumptions of its element type.
| Simply constrain T to be a TMyClass:
|
| type
| TMyClassList<T> = class(TList<T>)
| where T is TMyClass;
| end;
|
| Now you can use all instance members of TMyClass without loosing the type
parameter.
The syntax may be wrong here, but, yes, this is a possibility :-)
| > I would probably prefer a design where you can assign the comparator as
early as possibly - maybe even with an implicit
| > assignment based on a default compare in TMyClass. I prefer that my
lists (or hashlist, tree, whatever) do sorted
| > inserts.
As Robert says, don't try to do sorted inserts by yourself. If you want
objects accessible by a key value, then use a Dictionary<K,V> which can use
any type as the key, not just string or integer, otherwise, ensure that your
business classes implement IComparable<T> in a way that suits the desired
default sorting.
| Oh, and btw: I have not the slightest idea of how generic constraints
would look like in Delphi.
| What I wrote is kinda mixture between Chrome generic syntax and Delphi.
It shows :-)
Bob
>
> If you have to do this kind oif thing, then you have not designed
> your generic clas correctly.
>
Yes, I agree with that. And its probably why I can't come up with a
good example. It was just a gut feeling I had given past experiences
that this kind of thing tends to creep in on large projects.
As I write this I thought of a silly (bad design) example though...
What if I was to create a TNumber<AnyType> class.
{$incorrect Syntax warning off}
TNumber<AnyType> = class
function Add(aRHS: <AnyType>): <AnyType>
...
end;
and then try something like this:
foo:= TNumber<string>.Create('123')
foo:= foo + '456';
In this case, wouldn't the add method need to know "something" about
its underlying type?
If treated as a truely generic type, my result in this case would
probably be '123456' as opposed to my expected result of '579'.
--
Joanna Carter [TeamB]
45ae...@newsgroups.borland.com...
| You can "cludge" them though:
| http://www.codeproject.com/csharp/genericnumerics.asp
Hmmmm. Hardly a fit sight for beginners :-)
Robert Giesecke
> "Robert Giesecke" <sp...@spam.spam> a écrit dans le message de news:
> 45ae37b1$1...@newsgroups.borland.com...
> | Lars Fosdal wrote:
> | > Some followup thoughts - If your list is polymorphic, this would still
> require you to beware of mixing apples and pears,
> | > ie specific comparisons will still require the programmer to ensure that
> he only have decendants of TMyClass in the list,
> | > but that doesn't really matter as you still can do the generic
> algorithims untyped.
> |
> | Lets imagine you made your own container class, based on an internal
> array.
> This really isn't necessary; List<T> is fine.
>
I wasn't talking about .Net here, actually.
> | Oh, and btw: I have not the slightest idea of how generic constraints
> would look like in Delphi.
> | What I wrote is kinda mixture between Chrome generic syntax and Delphi.
>
> It shows :-)
Yes, I wanted to prevent irritations of you flied testing TeamB'ers. ;-)
Serious though: Are you allowed to show how type constrains look like in Delphi?
I found Chrome's syntax "where T is IComparable<T>, T has constructor,..." to be very elegant and nice to read.
Given that the CG guys probably knew that syntax I'd be very interested what they made better, or why they consider it
better. :-)
Joanna Carter [TeamB]
| Serious though: Are you allowed to show how type constrains look like in
Delphi?
| I found Chrome's syntax "where T is IComparable<T>, T has constructor,..."
to be very elegant and nice to read.
There have been several options floating around in SpeculationLand but
nothing has been confirmed or denied by anyone of importance.
Don't forget that we all have to try and avoid any C#isms creeping into the
purity of the Pascal language <gd&r>
Joanna Carter [TeamB]
45ae41cd$1...@newsgroups.borland.com...
| Yes, I agree with that. And its probably why I can't come up with a
| good example. It was just a gut feeling I had given past experiences
| that this kind of thing tends to creep in on large projects.
<smug mode> Not in mine though </smug mode>
| As I write this I thought of a silly (bad design) example though...
|
| What if I was to create a TNumber<AnyType> class.
|
| {$incorrect Syntax warning off}
|
| TNumber<AnyType> = class
| function Add(aRHS: <AnyType>): <AnyType>
| ...
| end;
|
| and then try something like this:
|
| foo:= TNumber<string>.Create('123')
| foo:= foo + '456';
|
| In this case, wouldn't the add method need to know "something" about
| its underlying type?
This is where the Arithmetic example pointed to by Christopher could be both
useful and dangerous :-)
Robert Giesecke
> | Serious though: Are you allowed to show how type constrains look like in
> Delphi?
> | I found Chrome's syntax "where T is IComparable<T>, T has constructor,..."
> to be very elegant and nice to read.
> There have been several options floating around in SpeculationLand but
> nothing has been confirmed or denied by anyone of importance.
Ok, I guess I'll see it way before I can play with it.
So this is just me being childishly impatient. *g*
> Don't forget that we all have to try and avoid any C#isms creeping into the
> purity of the Pascal language <gd&r>
*g*
That can turn out to be problem, IMHO. Not everything in C# is ugly.
e.g. enforcing parameters on methods/delegate calls makes it perfectly clear when to use the method or delegate as an object
in its own right and when to call it.
Eric Grange
> so it is a sort of variant,
Indeed.
> but it is still strictly typed so that the assigned value really
> is still a strict type.
Why 'but'? It's exactly the same with variants: they can take many
forms, and each of these forms is that of a strict type.
> e.g. you cannot call a member of the string class on an integer
> stored in an object variable.
You can cast and call. The cast will be type-checked at runtime.
It's similar in behavior to variant runtime evaluation, when they're
cast back to strongly typed values: if it's not possible/allowed you get
an exception at runtime, and nothing at compile-time.
> Fortunately, generics really do remove a great many places where you might
> be tempted to use System.Object as a prameter to a "generic" method.
The primary sin is having automagic boxing in the first place, generics
remove many places, but they do not remove the automagicity.
> It is unusual in well-written (not including some of the legacy .NET framework)
> .NET 2.0 code to see a method that takes a System.Object parameter
Well, there are two conditionals in your sentence "unusual" -- which
means it still happens -- and "well-written" -- which means uncommon ;)
Eric
Joanna Carter [TeamB]
| That can turn out to be problem, IMHO. Not everything in C# is ugly.
Totally agreed. I have never made a secret of the fact that I prefer C-style
syntax; after all, I am meant to be in TeamB to look after C#builder :-)
GrandmasterB
practical use of them than the usual 'collection' example? I can see what
they're for, but other than saving me the time of coding to create my own
typed TList, are there any concrete advantages of them when applied to less
trivial code?
TObject
"GrandmasterB" <Fiz...@shizzle.com> wrote in message news:45ae8e63$1...@newsgroups.borland.com...
That's the biggest advantage, right there. Instead of spending time
creating a tangled web of boilerplate list classes, like TMyCustomerList,
you can just use TList<TMyCustomer>.
The other advantage, more errors are potentially caught at compile time, due to type safety.
One more advantage, using generics, at least in .NET, usually produces
code that executes faster than the equivalent code without generics.
Warren Postma
Mark Reichert
news:45ae5ff9$1...@newsgroups.borland.com...
> "Robert Giesecke" <sp...@spam.spam> a écrit dans le message de news:
> 45ae4601$1...@newsgroups.borland.com...
>
> | That can turn out to be problem, IMHO. Not everything in C# is ugly.
>
> Totally agreed. I have never made a secret of the fact that I prefer
> C-style
> syntax; after all, I am meant to be in TeamB to look after C#builder :-)
Not much traffic in Borland.Public.CSharpBuilder groups? Remembering your
excellent posts involving Class structure in oodesign and the language
groups, I took a look at your Google Groups profile and notice how much more
often you were posting in the Delphi groups.
Micha Nelissen
> Nonetheless, within the bounds of a class factory or visitor pattern, this
> kind of thing is very common and, provided sufficient testing is done, it is
> safe.
Why not use virtual methods or an interface ?
Micha
Joanna Carter [TeamB]
45ae...@newsgroups.borland.com...
| Why not use virtual methods or an interface ?
To achieve what ?
Joanna Carter [TeamB]
45ae9b4d$1...@newsgroups.borland.com...
| Not much traffic in Borland.Public.CSharpBuilder groups?
;~}
| Remembering your
| excellent posts involving Class structure in oodesign and the language
| groups, I took a look at your Google Groups profile and notice how much
more
| often you were posting in the Delphi groups.
That was before they invented C# <g>
Jolyon Smith
>
> "GrandmasterB" <Fiz...@shizzle.com> wrote in message news:45ae8e63$1...@newsgroups.borland.com...
> > Generics look interesting... but could someone provide a more real-world,
> > practical use of them than the usual 'collection' example? I can see what
> > they're for, but other than saving me the time of coding to create my own
> > typed TList, are there any concrete advantages of them when applied to less
> > trivial code?
>
> That's the biggest advantage, right there. Instead of spending time
> creating a tangled web of boilerplate list classes, like TMyCustomerList,
> you can just use TList<TMyCustomer>.
And then when you discover that a list of TCustomers actually has very
specific needs which aren't met and cannot sensibly be provided in TList
<Any>, you curse the day you couldn't be bothered to implement a true
TCustomerList because now you have to and you have a huge impact
analysis to conduct and deal with on the code that uses the now
inappropriate TCustomerList.
Maybe.
:)
> The other advantage, more errors are potentially caught at compile
> time, due to type safety.
When compared to a non-type safe approach, yes.
When compared to a type safe approach, no. e.g. descendant of a general
purpose list type, the type safety is the same.
i.e. you don't have to choose between a TList<Customer> and a TList with
lots of type casts, you also have the choice of a TCustomerList = class
(TList) with a type safe implementation built in.
In fact, this latter is arguably MORE type safe than a generics based
approach.
When you implement TList<Any> you cannot possibly anticipate (since you
don't know) all the types that your implementation might be used for.
Your TList<Any> may well be type safe from a compilation point of view,
but not type safe from a runtime behaviour point of view.
(This is also the reason it's so hard to come up with realistic uses for
generics in anything other than "trivial" classes, like simple
collections - complexity usually goes hand in hand with specialisation)
If on the other hand, you take the time to decide what is needed from a
TCustomerList, whether that is implemented as a complete list in it's
own right, or as a type safe extension to a general list base class, you
are more likely to identify any potential gotchas up front (and will be
in a better position to deal with any unforeseen gotchas that arise in
the future).
> One more advantage, using generics, at least in .NET, usually produces
> code that executes faster than the equivalent code without generics.
Easy to demonstrate, not so easy to substantiate.
Just as it is easy to show "some code that doesn't use pointers that is
faster than this code which does use pointers". That doesn't
necessarily mean that using pointers is slower than not using pointers,
it could just mean that you had an example of some slow code that
happened to use them, and could probably have been vastly improved
without having to throw out the pointers themselves.
+0.02
--
Jolyon Smith
Say, do any of you guys know how to Madison?
Jolyon Smith
Smith says...
> In article <45ae...@newsgroups.borland.com>, TObject says...
> > One more advantage, using generics, at least in .NET, usually produces
> > code that executes faster than the equivalent code without generics.
I just realised, I imagine this is a reference to the fact that generics
in .NET avoids the need for boxing and unboxing, so of course generics
will be faster when compared to that particular alternative.
But if the alternative to a generic implementation also doesn't involve
boxing/unboxing, then any performance difference is going to be
negligible, and again, with specialised classes able to exploit their
knowledge of the specialised case, opportunities to optimise are vastly
increased, as compared to the necessarily general approach demanded by a
generic implementation (the clue is in the name).
:)
Loren Pechtel
wrote:
>"TObject" <noe...@nospam.invalid> wrote:
>
>>
>>"Michael C." <Mic...@Anonymous.net> wrote in message news:45ad...@newsgroups.borland.com...
>>
>>> > Semasiologically, I would recommend replacing "AnyType" with "AType" or "T"
>>>
>>> I actually like AnyType better because it emphasizes plurality.
>>>
>>
>>Your old trusty TList is a list of any type.
>>The beauty of generics is in type safety: your generic list is not a list of any type; it is a list of a type.
>>
>
>I like the idea of generics, but there is one challenge that I don't
>see how they intend to solve. Most lists that I use, are not just
>simple arrays or chains - but they typically would be sorted or
>filtered on some criteria.
>
>How do you make a sortable generic list? How do you decide on what to
>sort on?
You require the user to provide a comparison function.
Jan Nordén (CodeGear)
Even for class types, there will in general be a cost for casting down
the objects to their actual type. (Or in win32, a safety loss if you
use a hard cast).
And a specialised list can in most cases be created as a subclass of
List<T>.
--
Jan Nordén
Architect, ECO Team
Joanna Carter [TeamB]
news: MPG.20197cd43...@newsgroups.borland.com...
| And then when you discover that a list of TCustomers actually has very
| specific needs which aren't met and cannot sensibly be provided in TList
| <Any>, you curse the day you couldn't be bothered to implement a true
| TCustomerList because now you have to and you have a huge impact
| analysis to conduct and deal with on the code that uses the now
| inappropriate TCustomerList.
I think one of the problems that a lot of people have in designing classes
is, that they don't separate out the concerns correctly.
A Customer List is just that, a list of Customers. As to how you manage that
list, that is another concern. List<T> is a description of list
functionality - Add, Remove, Sort, etc. If you then want to impose other
business rules on how that list should be managed, then you need to
superimpose those rules on that list, not alter the basic list behaviour.
This can be done two ways: If you want to use *all* of the List
funcctionality *plus* other behaviour, you can derive from List<T>, binding
it to Customer to provide a ManagedCustomerList, or you can further enhance
the List<T> to a ManagedList<T>, where the rules can also supply to any
other class, not just Customer.
If you want to "supervise" the addition, removal, sorting of items in a
list, then you would use composition to encapsulate that list as a private
member; the encapsulating class providing wrapper methods that surface only
that list functionality required by client classes.
e.g.
public class Order
{
public class Line
{
...
}
private List<Line> lines;
public Line Add()
{
Line result = new Line();
lines.Add(result);
return result;
}
...
}
This way, although the Order is essentially a list of Lines, there is other
functionality that governs the management of the list of Lines and the basic
list functionality is hidden and managed via the Order class. In this
example, the rules of an Order dictate that Order.Lines cannot be created
unless they are part of an Order, therefore the Order.Add() method is the
only way to obtain a new Order.Line instance and the Order looks after
adding the newly created Line to the inner list.
| i.e. you don't have to choose between a TList<Customer> and a TList with
| lots of type casts, you also have the choice of a TCustomerList = class
| (TList) with a type safe implementation built in.
But, if you only want standard list functionality, then there really is no
need to choose, the List<T> class is the only sensible way to go.
| When you implement TList<Any> you cannot possibly anticipate (since you
| don't know) all the types that your implementation might be used for.
| Your TList<Any> may well be type safe from a compilation point of view,
| but not type safe from a runtime behaviour point of view.
Yes, you can and should anticipate that a generic class will have to cope
with *any* type.O course, you are also allowed to specify constraints on the
types used,which can limit the generic class to being specific to, for
example, one particular hierarchy, or only classes that support a particular
interface.
A generic class is designed to be generic! If there is type specific
behaviour, then you need to either derive or encapsulate the generic
behaviour.
| (This is also the reason it's so hard to come up with realistic uses for
| generics in anything other than "trivial" classes, like simple
| collections - complexity usually goes hand in hand with specialisation)
I have over 50 of my own generic classes in my VTF, OPF and MVP frameworks
and I can assure you that they are not trivial :-)
| If on the other hand, you take the time to decide what is needed from a
| TCustomerList, whether that is implemented as a complete list in it's
| own right, or as a type safe extension to a general list base class, you
| are more likely to identify any potential gotchas up front (and will be
| in a better position to deal with any unforeseen gotchas that arise in
| the future).
Once again, separation of concerns, aka responsibility driven design.
Wayne Niddery [TeamB]
>
> And then when you discover that a list of TCustomers actually has very
> specific needs which aren't met and cannot sensibly be provided in
> TList <Any>,
Inheritance still works with generics.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"The purpose of morality is to teach you, not to suffer and die, but to
enjoy yourself and live." - Ayn Rand
Jolyon Smith
says...
> Even for class types, there will in general be a cost for casting down
> the objects to their actual type. (Or in win32, a safety loss if you
> use a hard cast).
The potential safety loss here is surely in the list implementation, not
in the consumers of the list implementation?
It is easier to verify the type safety of a list _implementation_ than
it is to verify in code that _consumes_ the implementation (for one
thing, the former is a known quantity, the latter is an infinite set -
the set of all code that does or in the future may, consume the
implementation).
i.e. in the list implementation hard casts will be verifiably safe, so
you can use them. As long as the interface your implementation then
exposes to it's consumers is type safe, you have full type safety and
zero performance cost.
> And a specialised list can in most cases be created as a subclass of
> List<T>.
Not if the specialisation requires deviations from the generic
implementation that it inherits from.
Which I guess is what identifies the rest of those cases, other than the
"most" that you refer to.
Personally I remain unconvinced that generics is a desirable alternate
solution. The attraction seems to be confined merely to it being less
work.
ime developers cut more than enough corners already - encouraging the
practice is asking for trouble imho, especially since in this case the
intent seems to be to save effort in analysis and design (technical
analysis/design, not business analysis. i.e. "no need to consider the
needs of a specialised list class - we just use a generic and move on to
the more interesting stuff".
ime time saved in analysis design often results in immense costs in
subsequent maintenance.
+0.02
Jolyon Smith
says...
> Once again, separation of concerns, aka responsibility driven design.
A great post and response - very interesting and illuminating.
However, the biggest concern I have with generics is not in how they can
be used properly, but how they are likely to be used improperly.
It strikes me that their greatest attraction to the great majority of
developers is that it saves them the bother of having to think about
what they are doing.
Need a list of TCustomer? Use a List<TCustomer>. Job done. Move on to
the more interesting stuff.
They won't stop and think about _why_ they need a list of TCustomer,
whether it is a simple list or a managed list - it's a list, and
generics (not fully understood by everyone that will use them) provides
an easy answer.
And of course the same can be said of any number of other aspects of
modern programming languages, and in many cases those theoretical
concerns and fears are largely borne out in the day to day experiences
of developers responsible for maintenance of applications developed
using those techniques by people that saw them as a great way of getting
a job done easily, not as a tool to be used reponsibly.
In most cases though, the risk/benefit equation comes down in favour of
the technique - the cost of dealing with the bad instances being offset
by the benefits to be gained by appropraite use (and in many cases, the
relative ease with which bad work can be undone and replaced with good).
I just don't see that the equation balances in favour of the feature in
the case of generics and am not looking forward to them appearing in
Delphi.
(I also add that I'm a firm believer of form following function: The
syntax required to support generics to me looks and feels unattractive
and cumbersome)
Jolyon Smith
says...
> Jolyon Smith wrote:
> >
> > And then when you discover that a list of TCustomers actually has very
> > specific needs which aren't met and cannot sensibly be provided in
> > TList <Any>,
>
> Inheritance still works with generics.
I am well aware of that, in fact, that's part of the point: when
deriving from a generic base by definition you inherit the generic
implementation containing those parts which may not be appropriate in
the particular case.
Wayne Niddery [TeamB]
>
> I am well aware of that, in fact, that's part of the point: when
> deriving from a generic base by definition you inherit the generic
> implementation containing those parts which may not be appropriate in
> the particular case.
Then the mistake is inheriting from TList in the first place since a generic
version of it has exactly the same methods and properties available.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"A man is likely to mind his own business when it is worth minding,
when it is not, he takes his mind off his own meaningless affairs by
minding other people's business." - Eric Hoffer
Joanna Carter [TeamB]
| Personally I remain unconvinced that generics is a desirable alternate
| solution. The attraction seems to be confined merely to it being less
| work.
Certainly a major benefit is less work but included in that "less work" is
the assurance that, once you have designed and tested one generic class, you
can safely change and test code in the generic class.
| ime developers cut more than enough corners already - encouraging the
| practice is asking for trouble imho, especially since in this case the
| intent seems to be to save effort in analysis and design (technical
| analysis/design, not business analysis. i.e. "no need to consider the
| needs of a specialised list class - we just use a generic and move on to
| the more interesting stuff".
Far from encouraging the cutting of corners, when you get down to designing
generic classes, you should find the fun has only just begun :-) although,
of course the lack of thorough testing could delay the surprises <g>
IMO generics are no more likely to cause errors than any other programming
task. Poor developers will abuse anything you give them; good developers
will benefit.
| ime time saved in analysis design often results in immense costs in
| subsequent maintenance.
Which is one of the reasons why I get called in to fix things :-)
Joanna Carter [TeamB]
| However, the biggest concern I have with generics is not in how they can
| be used properly, but how they are likely to be used improperly.
As I said in my other reply, everything is open to abuse, generics are just
another opportunity for the poorer developers to "shine"
| It strikes me that their greatest attraction to the great majority of
| developers is that it saves them the bother of having to think about
| what they are doing.
|
| Need a list of TCustomer? Use a List<TCustomer>. Job done. Move on to
| the more interesting stuff.
|
| They won't stop and think about _why_ they need a list of TCustomer,
| whether it is a simple list or a managed list - it's a list, and
| generics (not fully understood by everyone that will use them) provides
| an easy answer.
But you have to consider that such developers will have a typesafe list
wrapper boilerplate that they will simply copy/paste and change the type
without thinking, so no difference there.
| I just don't see that the equation balances in favour of the feature in
| the case of generics and am not looking forward to them appearing in
| Delphi.
Jolyon, you obviously would not abuse a feature, otherwise you would not be
voicing your concerns. However, for those of us who do care about the
integrity of code design, generics are a very useful weapon to add to your
armoury. It took me some time to get into the intricacies and subtleties of
generics but, after getting used to those, the sophistication of design that
they allow is truly awesome.
| (I also add that I'm a firm believer of form following function: The
| syntax required to support generics to me looks and feels unattractive
| and cumbersome)
I personally am happy with the C# syntax but, as most Delphi syntax seems
awkward by comparison to me and the fact that the Delphi generics syntax is
yet to be decided, I will reserve judgement for now.
Joanna Carter [TeamB]
news: 45b02054$1...@newsgroups.borland.com...
| Then the mistake is inheriting from TList in the first place since a
generic
| version of it has exactly the same methods and properties available.
A very good point that is often overlooked as inexperienced programmers seem
only to use inheritance instead of considering composition as an
alternative.
Jan Nordén (CodeGear)
>
>
> Personally I remain unconvinced that generics is a desirable
> alternate solution. The attraction seems to be confined merely to it
> being less work.
>
Less work, and in particular less need when reading and understanding
code to find out if a piece of code is just deadweight to produce a
typed list, or actually something different.
> ime developers cut more than enough corners already - encouraging the
> practice is asking for trouble imho, especially since in this case
> the intent seems to be to save effort in analysis and design
> (technical analysis/design, not business analysis. i.e. "no need to
> consider the needs of a specialised list class - we just use a
> generic and move on to the more interesting stuff".
>
> ime time saved in analysis design often results in immense costs in
> subsequent maintenance.
>
> +0.02
Certainly there are things that are not a typed list, just as there are
things that are not just an untyped list.
If I understand you correctly you believe that developers are
selectively careless in that if they only have an untyped list they
will not be tempted to use it in such a case, but if they have a typed
list they will. Seems very specific to me.
Micha Nelissen
> "Micha Nelissen" <nob...@nowhere.invalid> a écrit dans le message de news:
> 45ae...@newsgroups.borland.com...
>
> | Why not use virtual methods or an interface ?
>
> To achieve what ?
To implement visitor and other patterns ?
Micha
Joanna Carter [TeamB]
| > | Why not use virtual methods or an interface ?
| >
| > To achieve what ?
|
| To implement visitor and other patterns ?
Just because I use generic methods doesn't mean that I don't use both
virtual methods and interfaces but I still don't get what you are trying to
say in relation to generic code.
Micha Nelissen
> Just because I use generic methods doesn't mean that I don't use both
> virtual methods and interfaces but I still don't get what you are trying to
> say in relation to generic code.
I am questioning the following statement:
'I often need to construct instances of bound generic types at runtime
and this requires more metadata than Delphi for Win32 can presently
provide.'
Using interfaces or virtual methods, then you don't need the above at
all anymore.
Micha
Loren Pechtel
And tList versions aren't a reason for it??
Joanna Carter [TeamB]
| I am questioning the following statement:
| 'I often need to construct instances of bound generic types at runtime
| and this requires more metadata than Delphi for Win32 can presently
| provide.'
|
| Using interfaces or virtual methods, then you don't need the above at
| all anymore.
Would you like to demonstrate your idea ?
Micha Nelissen
> | Using interfaces or virtual methods, then you don't need the above at
> | all anymore.
>
> Would you like to demonstrate your idea ?
No, sorry.
Micha
Joanna Carter [TeamB]
| > Would you like to demonstrate your idea ?
|
| No, sorry.
Then please do not submit answers to topics for which you are not qualified
so to do. We have a lot of learners on these groups who do not need posts
which will mislead them. Thank you.
Jolyon Smith
says...
> "Jolyon Smith" <jsm...@deltics.co.newzealand> a écrit dans le message de
> news: MPG.201acff44...@newsgroups.borland.com...
>
> | Personally I remain unconvinced that generics is a desirable alternate
> | solution. The attraction seems to be confined merely to it being less
> | work.
>
> Certainly a major benefit is less work but included in that "less work" is
> the assurance that, once you have designed and tested one generic class, you
> can safely change and test code in the generic class.
How is that different from a non-generics based type safe
implementation?
One key different that I see is that a generics based solution cannot be
thoroughly tested due to the infinite set issue that I touched on
before.
i.e. a TCustomerList can be demonstrably proven correct. A TList<Any>
can only be shown to be correct for a given subset of <any>, which
doesn't establish correctness for all <Any>
No?
> IMO generics are no more likely to cause errors than any other programming
> task.
lol - and of course, those tasks are routinely error free?
;)
> Poor developers will abuse anything you give them; good developers
> will benefit.
Very true, but by raising the bar of understanding (generics is after
all, something else that has to be understood) by definition you
increase the number of "poor developers" (if you include in that
definition some degree of totality of understanding).
;)
Jolyon Smith
says...
> "Wayne Niddery [TeamB]" <wnid...@chaffaci.on.ca> a écrit dans le message de
> news: 45b02054$1...@newsgroups.borland.com...
>
> | Then the mistake is inheriting from TList in the first place since a
> generic
> | version of it has exactly the same methods and properties available.
>
> A very good point that is often overlooked as inexperienced programmers seem
> only to use inheritance instead of considering composition as an
> alternative.
Exactly - "often".
I see the introduction of decision points as a way of avoiding such
mistakes.
Making a "bad" thing easier to do reduces the chance that the mistake
will be realised imho (and ime).
+0.02
Jolyon Smith
says...
> "Jolyon Smith" <jsm...@deltics.co.newzealand> a écrit dans le message de
> news: MPG.201ad2c2a...@newsgroups.borland.com...
>
> | However, the biggest concern I have with generics is not in how they can
> | be used properly, but how they are likely to be used improperly.
>
> As I said in my other reply, everything is open to abuse, generics are just
> another opportunity for the poorer developers to "shine"
Well I guess as someone that has to work with those developers, even if
I'm not one myself - (thanks btw <g>) - I'd prefer not to give them that
opportunity.
;)
> But you have to consider that such developers will have a typesafe list
> wrapper boilerplate that they will simply copy/paste and change the type
> without thinking, so no difference there.
Fair point.
> It took me some time to get into the intricacies and subtleties of
> generics but, after getting used to those, the sophistication of design that
> they allow is truly awesome.
Hmmm - I don't see it. Generics are surely just a way of expressing an
implementation, not a design.
I wouldn't "design" a system that specified TList<TCustomer> - I would
design a system that needed a TCustomerList - how that is implemented is
an implementation detail, not a design decision.
> I personally am happy with the C# syntax but, as most Delphi syntax seems
> awkward by comparison to me
lol - not at you, at the notion, since I find the exact opposite to be
true!
:D
> and the fact that the Delphi generics syntax is
> yet to be decided, I will reserve judgement for now.
Again, a fair point, and I suppose there may yet be a surprise in that
dept. My observations apply to the implementations of generics I've
seen so far, including C#.
Micha Nelissen
> Then please do not submit answers to topics for which you are not qualified
> so to do.
Excuse me? These design patterns are also usable in language without
generics, you know.
> We have a lot of learners on these groups who do not need posts
> which will mislead them. Thank you.
LOL. Readers should also think a bit; not get everything chewed out for
them.
Micha
Micha Nelissen
> One key different that I see is that a generics based solution cannot be
> thoroughly tested due to the infinite set issue that I touched on
> before.
I think this is already a problem with all software.
> i.e. a TCustomerList can be demonstrably proven correct. A TList<Any>
> can only be shown to be correct for a given subset of <any>, which
> doesn't establish correctness for all <Any>
No, you can make assumptions on the 'Any', so that you can finish your
proof.
Micha
Jolyon Smith
> Jolyon Smith wrote:
> > One key different that I see is that a generics based solution cannot be
> > thoroughly tested due to the infinite set issue that I touched on
> > before.
>
> I think this is already a problem with all software.
I guess the difference is that I don't see this as an excuse, let alone
a justification, for making things worse (by increasing the ways in
which bad developers can demonstrate their ineptitude) at least not in
this case.
aiui generics are pretty much a necessity to avoid performance problems
with the boxing/unboxing that can occur in non-generics equivalent
implementations in .net.
i.e. it is a language feature driven by an environmental imperative.
In much the same way that partial classes are/were driven by the need to
better separate runtime initialisation of design-time artefacts from the
rest of the runtime code.
Take these things away and there remains little else (imho) to justify
either generics or partial classes, and lots to be said against them
(especially w.r.t partial classes).
I can't otherwise think of any other reason why these two technologies
would have remained in the realm of language design, rather than
language implementations, for so long.
It seems to me that the clamour for them now is driven primarily by the
language equivalent of "Keeping Up With The Jones'".
If someone could point me at a real-world exploration of the tangible
benefits that generics brings to practical software development I would
be genuinely interested.
> > i.e. a TCustomerList can be demonstrably proven correct. A TList<Any>
> > can only be shown to be correct for a given subset of <any>, which
> > doesn't establish correctness for all <Any>
>
> No, you can make assumptions on the 'Any', so that you can finish your
> proof.
IIRC, a proof that contains an assumption by definition isn't a proof?
I am reminded of "2 + 2 = 5 (for sufficiently large values of 2)"
;D
Joanna Carter [TeamB]
| Excuse me? These design patterns are also usable in language without
| generics, you know.
This thread was all about the use of generics until you threw in a curve
ball post mentioning that something about using virtual methods or
interfaces to solve the construction of bound generic types at run time. You
then went on to indicate that using virtual methods or interfaces would
eliminate the need for generics but refused to explain how. I surmise that
you are blowing smoke on this one and really don't know enough about how
generics work to submit a sensible answer.
| LOL. Readers should also think a bit; not get everything chewed out for
| them.
Ah yes, I forgot this is non-tech, enough said.
Micha Nelissen
>> No, you can make assumptions on the 'Any', so that you can finish your
>> proof.
>
> IIRC, a proof that contains an assumption by definition isn't a proof?
No, it changes the 'statement' you prove. It becomes a weaker statement.
Micha
Florian Klaempfl
> "Micha Nelissen" <nob...@nowhere.invalid> a écrit dans le message de news:
> generics work to submit a sensible answer.
LOOOOOOL. This was the funniest post for years in this group. I guess
you don't know who is writting the generics based container library for
FPC ...
Joanna Carter [TeamB]
45b5...@newsgroups.borland.com...
| LOOOOOOL. This was the funniest post for years in this group. I guess
| you don't know who is writting the generics based container library for
| FPC ...
As I have been immersed in learning C# and .NET 2.0 for the last 18 months
or so in order to port a major application, I am not ashamed to say that I
don't even know what FPC is, let alone who Micha is. If Micha is that
knowledgeable, then the least s/he could have done would have been to
explain his/her assertions. Or does knowledge preclude courtesy ?
Jolyon Smith
So you can't "finish your proof". You have to abandon it and prove
something different.
No?
Robert Giesecke
> Or does knowledge preclude courtesy ?
>
Come on, Joanna.
You didn't have to bite him *that* hard and blame it on him not being a gentleman. *g*
Dave Nottage [TeamB]
> ..assumptions are inherently dangerous
Which is why the word starts with what one could feel like after making
one <g>
--
Dave Nottage [TeamB]
Jolyon Smith
says...
> If Micha is that
> knowledgeable, then the least s/he could have done would have been to
> explain his/her assertions. Or does knowledge preclude courtesy ?
It could also indicate respect.
i.e. if Micha knows that a certain level of understanding of generics
would also normally imply a level of understanding about how alternative
techniques can be applied to comparable if not identical effect, then
Micha might reasonably assume that someone expounding on the virtue of
generics also has the knowledge of the alternatives.
The fact that this is assumed could be seen as a measure of respect.
Otherwise Micha would have to assume that the person prosthelytising
generics does _not_ fully understand the alternatives available, which
might be seen as a more disrespectful assumption and at the very least
more patronising or condescending.
Just a thought.
Of course, either assumption could be a mistake and could be
misinterpreted either as lack of knowledge or condescension on the part
of the assumer, which just goes to show that assumptions are inherently
dangerous.
:)
Jolyon Smith
says...
> Jolyon Smith wrote:
>
> > ..assumptions are inherently dangerous
>
> Which is why the word starts with what one could feel like after making
> one <g>
Yep, "Assume makes an 'ass' of 'u' and 'me'"
:D
David S
Robert Giesecke <Sp...@Spam.Spam> wrote:
>Chris Burrows wrote:
>>
>> I'd be interested to know if Win32 D2007 is going to include all of the
>> Generics features detailed in this chapter or just a subset? There may well
>> be some aspects that are not applicable to Win32 - I don't know.
>>
>
>Hmm... I think _native_ Delphi can go even further with generics than what is possible in .Net.
>In .Net, you can have a constraint, that a type parameter must have a public constructor w/o parameters.
>Since Delphi is not only an IDE or a language, it has also its own RTL. Basically it could be possible to enforce T
>to have a specific constructor signature, or more than one.
>Maybe even constraints that require the type to have certain operators, combined with some sort of slots in the
>precompiled generic to be filled with the actual operators.
C++ is the "guiding light" for this stuff. It has what's called
a "default constructor". If you don't declare one explicitly,
it will create one for you automatically, although it may not
do exactly what you want. So it's always a good idea to declare
a default ctor in C++ just for this reason.
(A default ctor is one that takes no arguments, and is distinct
from a ctor that has an argument list that can also accept
defaults on each argument.)
One place where the default ctor is very important is when it's
called to initialize members of dynamic object arrays. If you
don't define one, the compiler will do it for you, and you may
well end up with quite a mess on your hands!
Delphi doesn't have this degree of "richness" as C++.
It sounds like .NET takes a similar approach to C++.
-David
David S
"GrandmasterB" <Fiz...@shizzle.com> wrote:
>Generics look interesting... but could someone provide a more real-world,
>practical use of them than the usual 'collection' example? I can see what
>they're for, but other than saving me the time of coding to create my own
>typed TList, are there any concrete advantages of them when applied to less
>trivial code?
>
>
>
>
I'm working on a rather large application that has literally
DOZENS of projects containing units that are virtually IDENTICAL
except for the fact that they all implement their own unique
sub-class and manipulate data that's defined in common
ancestor types.
This is a PERFECT example where the presence of generics would
save us THOUSANDS of lines of code.
Now, the other side of this coin isn't so nice. The reason
all of these classes exist is because the original designers
took a wrong turn and decided to implement a bunch of stuff that
looks like what you'd expect to see if you build a database
app without data-aware components.
If the use of data-aware components and implicit mechanisms is
like an endoskeletal design, then this is more like an
exoskeletal design. It's VERY ugly! And while it employs
a lot of very powerful visual controls, we have very little
access to them at design time other than through the code.
<sigh>
-David
Jan Nordén (CodeGear)
> In article <45ae...@newsgroups.borland.com>, TObject says...
> >
> > "GrandmasterB" <Fiz...@shizzle.com> wrote in message
> > news:45ae8e63$1...@newsgroups.borland.com...
> > > Generics look interesting... but could someone provide a more
> > > real-world, practical use of them than the usual 'collection'
> > > example? I can see what they're for, but other than saving me
> > > the time of coding to create my own typed TList, are there any
> > > concrete advantages of them when applied to less trivial code?
> >
> > That's the biggest advantage, right there. Instead of spending time
> > creating a tangled web of boilerplate list classes, like
> > TMyCustomerList, you can just use TList<TMyCustomer>.
>
> And then when you discover that a list of TCustomers actually has
> very specific needs which aren't met and cannot sensibly be provided
> in TList <Any>, you curse the day you couldn't be bothered to
> implement a true TCustomerList because now you have to and you have a
> huge impact analysis to conduct and deal with on the code that uses
> the now inappropriate TCustomerList.
>
> Maybe.
>
> :)
>
IMHO that case argues the opposite.
If you have a TList<Customer> then you know that this is just a list of
customers, it does not assign a salesman to each customer added (or
whatever the special list did). And it can be used that way.
If it is then discovered that the list has special needs, it is correct
and appropriate to do the "huge impact analysis" to ensure that all
code using the type assumes the special behaviour rather than just
assuming that it was a plain list.
If you have an originally plain list was called TCustomerList, and you
then just add behaviour to it, such things run a greater risk of going
undetected.
none
> I don't even know what FPC is,
Free Pascal Compiler.
Micha is their generics expert.
> then the least s/he could have done would have been to
> explain his/her assertions. Or does knowledge preclude courtesy ?
He wasn't rude.
He simply refused to spoonfeed you.
Joanna Carter [TeamB]
45b5...@newsgroups.borland.com...
| He wasn't rude.
| He simply refused to spoonfeed you.
Ok. As someone who gives of her time and knowledge to help all levels of
knowledge-seekers, I suppose I assumed that other people, who have expertise
in an area that I am obviously lacking, wouldn't have minded returning the
favour. Obviously a wrong assumption; I keep forgetting this is not
b.p.d.oodesign where people mutually feed off each others' ideas and
knowledge.
I made a polite request to Micha to explain how/where virtual methods and
interfaces made generics unnecessary and, next thing I know, I am embroiled
in a typical nontech argument about whether I should have even asked the
question.
Joanna Carter [TeamB]
news: MPG.2020123b4...@newsgroups.borland.com...
| i.e. if Micha knows that a certain level of understanding of generics
| would also normally imply a level of understanding about how alternative
| techniques can be applied to comparable if not identical effect, then
| Micha might reasonably assume that someone expounding on the virtue of
| generics also has the knowledge of the alternatives.
My starting point of knowledge, for the purposes of this discussion, is that
I have used, and taught others how to use, virtual methods and interfaces
for many years. In alll that time, I have always known about the principles
of generic code. In Delphi, I used the trick of type substitution and
include files, as written about by Rossen Assenov and, even then, would not
have found either virtual methods or interfaces to be a substitute for the
technique of writing one class that can deal with any data type in a
typesafe manner.
I genuinely wanted to know how Micha came to his assertions, I asked and, lo
and behold, I get embroiled in an argument about whether I had the right to
ask.
| The fact that this is assumed could be seen as a measure of respect.
|
| Otherwise Micha would have to assume that the person prosthelytising
| generics does _not_ fully understand the alternatives available, which
| might be seen as a more disrespectful assumption and at the very least
| more patronising or condescending.
It is less disrespectful to ask whether a person has already got knowledge
than to simply refuse to answer their questions.
| Of course, either assumption could be a mistake and could be
| misinterpreted either as lack of knowledge or condescension on the part
| of the assumer, which just goes to show that assumptions are inherently
| dangerous.
I am quite happy to state, publicly, that I don't know everything. I am also
quite happy to share what, little or great, that I do know. I have often
gone to the time and trouoble to explain somethign to someone in these
groups that, it turns out, they already knew. However, I am constantly aware
that the intended recipient of my reply is not the only person likely to
read it; others may well want to follow a question and answer thread in a
search for more knowledge on a particular topic. My dangerous assumption was
obviously that others would be like-minded.
Micha, my request was from a point of ignorance of what you are suggesting;
I don't know everything, is there any chance you would enlighten, not only
me but others, as to how virtual methods or interfaces can replace generic
types?
Chris Burrows
news:45b5f493$1...@newsgroups.borland.com...
>
> However, I am constantly aware
> that the intended recipient of my reply is not the only person likely to
> read it; others may well want to follow a question and answer thread in a
> search for more knowledge on a particular topic. My dangerous assumption
> was
> obviously that others would be like-minded.
>
Don't worry Joanna, your assumption was quite valid - I am one of those
others that you refer to.
> Micha, my request was from a point of ignorance of what you are
> suggesting;
> I don't know everything, is there any chance you would enlighten, not only
> me but others, as to how virtual methods or interfaces can replace generic
> types?
>
I would also be interested to know. Maybe Micha is genuinely too busy to
take the time to share his knowledge with us - if so maybe somebody else has
some idea of what he is referring to?
--
Chris Burrows
CFB Software
http://www.cfbsoftware.com/gpcp