RE: [DUG]: Delete a variable from a Dynamic Array

[Kyley Harris]

Title: Message

You make a good point in your argument. but in this case my comment was directly related to the issue. ie 20 items in a list. Everything you say is quite correct. every problem must be accessed for the correct answer. And in the case of this type of forum no one really has time to sit down and weigh up all the different points about a topic and write them down in an email (hence patronizing, or inaccurate etc etc) You would have to be permanently unemployed to have the time to write such lengthy comments and point out all the options of an argument to try and not look stupid or too biased, which would remove the answers value to some degree. And lets face it, all of this can be found in a website or book if you look around.     >When you're dealing with databases in the gigabytes or entities in the hundreds of thousands, bypassing unnecessary abstraction layers >can make a big difference.   I hope you aren't loading all of them into memory at the same time :)   >>All forms of abstraction have a performance cost. The job of a good software engineer is to know when to break them.   without trying to sound bad again :) breaking rules to gain performace cost is only going to hurt in the long run maintenance. computers double power every year continuously removing performance issues from the hardware. this only leaves performance and maintenance issues with the code (which probably has a far longer life) My own opinion is to go for code which will last and maintain longer and be simple to modify at need. (however you achieve this) the speed and management of objects against records just gets smaller everyday and you can't beat encapsulation if nothing else in an object.   I'm sure this will stir a few comments so fire away :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul Heinz Sent: Sunday, 9 February 2003 5:05 p.m. To: Multiple recipients of list delphi Subject: RE: [DUG]: Delete a variable from a Dynamic Array Kyley wrote: if your're worried about freeing objects, then use interfaced objects. If you're worried about speed (don't be) object creation is hardly slow by any measure. if you are worried about easy to maintain code, re-use and scalability of design. don't use arrays and records. Every record type you create is just an object lacking encapsulation of business rules.   I guess it really comes down to being an OO developer or not.  You probably don't mean it this way (email is bad for that) but the above comes off as rather patronising.   All forms of abstraction have a performance cost. The job of a good software engineer is to know when to break them. The fact that _you're_ not worried about speed (or abstraction costs) implies you have the luxury of operating with much smaller problem domains or databases than others here (including myself) do.   When you're dealing with databases in the gigabytes or entities in the hundreds of thousands, bypassing unnecessary abstraction layers can make a big difference.   Just like a 3NF (or BCNF for the truly hard core) database may need denormalised cached totals for acceptable performance, large collections of simple types may need to bypass object (or interface) abstraction over-head to meet performance targets.   And along with that, many simple types don't really have any business rules to encapsulate - an Amount, a Point, a Rectangle, etc. Nothing is really gained by wrapping them as an object. OO languages like C++ and Delphi go to some pain to efficiently support simple record types without object overhead for exactly this reason.   And C# likewise has value types to avoid reference type overhead for many simple types. These language features wouldn't persist if there weren't significant software domains that needed them.   OO development techniques are just _one_ tool in a software engineers toolkit to be used when appropriate.   Remember the old saying - 'If all you have is a hammer, everything looks like a nail' :-)   TTFN,   Paul.