>It is a hack because it assumes that a base class can be safely cast
into a descendent. This
>is OK due to the nature of Delphi's code generation, but code like this
will not work on say
>the .NET framework.
It can be safely cast into your type, as long as you first test that it
is a Tcontrol, the issue arises when the property you are accessing is
overriden with a new property declaration in a different sub-class.
>No you don't - because you know the type of the objects at the time
when you add the objects to >the list, you simply choose the appropriate
implementation, i.e., instead of writing
It is a very broad assumption to assume anything.
Assumption A/ That the list was generated by the person who wrote each
piece of code.
Assumption B/ That the coder working on the list of objects has the
authority to modify the other piece of code.
Perhaps the list of objects was generated using metaclasses. Such as
TComponentClass, or Tclass etc. perhaps the list is owned by a 3rd party
package of which you don't own the source code.
Perhaps the list is generated via something like this
for I := 0 to componentcount -1 do
Begin
List.Add(Component[i]);
End;
Which adapter would then be used?
If you are going to use good oo practises and frameworks such as
adapters and controllers and observers etc, then it seems unlogical to
throw a bit of static code at a dynamic world.
As I said before, Adapters are good in the correct circumstance, but it
doesn't answer the question posed. All it does is introduce dozens of
new architectural issues over which a single programmer may not have
choice or control.
Kyley.
Ps - I can see this going on for a while :)
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
