Anders Melander

You're not nesting records. TList<T> doesn't contain a list of T. It contains a pointer to a list of T.

Why do we need google when we have @David Heffernan? David, the range and depth of your knowledge never cease to amaze me.

That's my experience too. Yup. I'm very satisfied too. There are some layouts that are hard to get right (layout in columns comes to mind), but generally it has saved me a ton of work.

Thanks for the explanation. It seems much more reasonable now. With regard to validation rules some purists will insist that they belong with the business logic on that tier, and I've seen many examples that implement n-tier that way (post data to the server - get an error message back), but in my experience that result in poor user experience. Much better to validate data as early as possible, on the client, and validate it on the server. If the server can supply the meta data required for the client to build the UI and do validation I see no problem with that. Just out of curiosity: Have you tried using the DevExpress layout control to handle different font sizes and resolutions? Since I started using it to layout dialogs I've pretty much stopped worrying about what resolution/font/sizes the users are using; The layout control takes care of it.

Yes. I'm sure we all experienced that a simple, innocent change ends up leading to much more work later one because we introduced a bug or side effects that we didn't think of.

Of course. If the customer can cover the development expenses directly, then that will increase the priority. If the change will benefit other customers, make the product easier to sell or benefit the product in some other way that can also increase the priority and lower the price of the change. There's still the matter of finite resources to take into account though. Even if the customer pays the expenses up front it still means something else is not getting done. I used to think I could solve the finite resources problem by implementing stuff in my spare time. Unfortunately that just created another problem as the QA, documentation and marketing departments was completely unable to keep up with the amount of features I could produce that way. I don't understand. So in the scenario you describe you're not the customer but the developer? If so, why do you have a request at all?

I don't like this part; It sounds like you're polluting your business logic tier with presentation stuff. Even if you're just using the database and BO tiers for storage of the UI definitions, my guess is that you have created a strong binding between the UI definitions and the presentation tier, so the definitions can only be used by the one presentation tier(s). I've seen this done several times and it always ends up with half the UI being created the way you describe and the other done the traditional way because of special UI needs that the generic framework can't handle. And then eventually the need arises for a new type of client (e.g. web or mobile) that cannot use the existing UI definitions and slowly the definition framework decays because it turns out that it's faster to just create the whole UI on the client than trying to make the definition framework handle everything for everybody. It's a bit like the write once, run everywhere promise. Sometimes it just faster to write three separate applications than to have one application support three separate platforms.

Sure. Professional relationships, personal preferences and even mood, are just some of the many factors that affect priority. We're humans. As long as you know why you are making a choice I don't see anything wrong with making it based on "feelings" or intuition. Just don't make all your choices that way 🙂 I regularly make technical decisions based on intuition. I may not be able to rationally explain why I choose one solution over another, except that one "feels" right or the other doesn't "feel" right.

Even trivial changes consume project resources and resources are finite. Implementing a low priority change takes resources away from higher priority changes and unless there's something wrong with way changes are prioritized I can't really see how one can justify that. The really hard part is weighing all the different factors when calculating the priority. Giving a ticket priority just because it's old doesn't make much sense. But if the age will cause enough customer dissatisfaction that it ends up having economical consequences then it might make sense. Apart from that I don't think age should be a factor. Each time we go through our ticket list we look at it fresh: At this point in time, what is the most important change for us to focus on. In my projects it's common for trivial but very low priority changes to be rejected. I think it's better to let the requester know that there's minimal chance their request will ever be granted, given that there will always be more important changes to work on, than to give them false hope.

I can't really tell from your statement if you're saying that he doesn't do that but should or if you're just stating a general principle. From the code posted it's not possible to see if the implementation uses aggregation and/or delegation. No. It's another way. Which is better depends on many factors and we can only guess since we don't know anything about the architecture or size of Clément's application, and it's not really relevant to the question asked. In my experience an application has to reach a certain size and complexity before it's worth even considering the overhead and added complexity of SRP. And even then I would only apply it if it solved an actual (present or near future) problem.

I don't see any problems with it; It's a very common (and very sensible) pattern. Just make sure, if your base class is reference counted, that all references to the object is through interfaces. If it's not reference counted then that doesn't matter.

Code style to tentacles in three posts. I didn't see that coming.

Very interesting. Thanks for the pointer. One of the other answers explains it even better IMO and points to this gem: https://kjellkod.wordpress.com/2012/08/08/java-galore-linkedlist-vs-arraylist-vs-dynamicintarray/ I guess I'll have to revisit some of my old code and redo the benchmarks.

That's quite a unnuanced (is that a word?) statement. Wouldn't you say it depends on the access and allocation pattern?

That's a strange question. It's based on the experience that unnecessary nesting makes the code harder to read. Sure it's a personal preference, some like it, some don't (just google Early Return - I'm sure you will find one or two that doesn't advocate it), but at least one of your "if" blocks are complete superfluous and would be removed by the optimizer if it was worth anything. What's the relevance? Are you saying that because some simple rule based validator doesn't flag your code then it can't be improved? - Because I can spot several goofs in it.

Huh? You have heard of premature optimization haven't you?

It's a refactoring; It improves the readability of the code without changing the functionality.

Nice. But: Early Return ... if ParamCount < 2 then Exit; if not FileExists(ParamStr(1)) then Exit; if not System.SysUtils.TryStrToInt(ParamStr(2), ThisLine) then Exit; ...

Congratulations! I love it when that happens. I do think the phrase "Attempting restore on [...]" sounds a bit pessimistic though. Why not just "Restoring [...]"

Yes, but you can't. I don't know the history behind it but I can see arguments both for and against having actions disabled if there's no handler and maybe that's why they decided to make it optional. Maybe not making it published was to avoid having the noobs shoot themselves in the foot with it. I don't know (and I don't care which is why I tried to delete my question after I asked it 🙂). It's a very minor annoyance that can easily be worked around with an empty OnExecute handler so I don't really care about it anymore. Submit a change request if it's important to you.

Why do you ask?

I'm way past caring about disk space. For example we use DevExpress in almost all desktop projects and in addition to the regular install, which we need for design time support, help, examples, etc., each project has a complete copy of the DevExpress source files to make sure the projects are autonomous, under full revision control and are always built with the correct version. That's 120 Mb in 3000 files - per project, per branch, etc. Yes, a global package cache could reduce that to a single copy, but it would be pointless. The problem we have isn't disk space. It's creating a reliable, robust and foolproof development environment. Yes, but I would prefer to have complete control over where that exact location is. I'm not saying that it's unreasonable to require at least some adaptation of a project for use with DPM but for me at least it will be a showstopper if use of DPM becomes a requirement once the project has been adapted and having the package cache in the project search path, and the search path controlled by DPM, is such a requirement as far as I can tell. I guess right now I'm focusing on how DPM could fit in with my existing projects where I already have all dependencies sorted out and folders and search paths assigned. I understand the use cases of dependency resolution, the package cache and updating the search path, but I'm not sure the convenience they offer is worth sacrificing the autonomy I already have in place for the projects I manage. Now if only DPM had been a standard part of Delphi then it would have been an entirely different matter.

My guess is that you have two monitors; Primary with 125% zoom and secondary with 100% zoom. This setup appears to freak the IDE out.

Yes.