I'm starting to code using TStringHelper. What do i have to do to be able to evaluate the expressions in the debugger?
I'm starting to code using TStringHelper. What do i have to do to be able to evaluate the expressions in the debugger?
Doing "Debug|Evaluate/Modify" on
lString.IndexOf('/') gives
E2018 Record, object or class type required
whilst on Pos('/', lString) gives
1
i would like to be able to inspect the first case (would show 0).
Thanks!
Doing "Debug|Evaluate/Modify" on
lString.IndexOf('/') gives
E2018 Record, object or class type required
whilst on Pos('/', lString) gives
1
i would like to be able to inspect the first case (would show 0).
Thanks!
Report it and cross your fingers. :) Seems the debugger does not support it.
ReplyDeleteBummer Stefan Glienke, i'm starting to get WITH vibes :(
ReplyDeleteOK, i entered an item in the QC.
ReplyDeleteDany Marmur QC is deprecated. Use QualityPortal instead.
ReplyDeleteThanks David Heffernan. Wilco.
ReplyDeleteSounds like if eventually I've something in common with the Delphi debugger.
ReplyDeleteI'm afraid I feel "syntax diabetic" - since I start becoming intolerant to "syntax sugar"...
Either you make consistent choices, like with Oxygene, and you define a true object oriented pascal-flavored language, or you should just leave the compiler alone. String or record helpers, as currently implemented, are half-backed workarounds. Even the Delphi RTL is not using them. So I'm not surprised the Delphi debugger is not supporting those.
Thanks to all those helpers inflation, next major "feature" of the compiler would probably be to deprecate plain functions calls. Then replace the begin..end with braces, and we would start having a sub-version of C# or Java (close to what they did offer 10 years ago), and some may be happy with it. I for sure won't, and would always prefer C# or Java in this respect.
+Arnaud New code in the RTL is using string helper. Extension methods are a useful and valuable feature. That the IDE is too lame to understand them fully is an issue with the IDE. Same for anon methods. The way forward is to fix the IDE.
ReplyDeleteA. Bouchez If you buy an electric screwdriver and it does not work you can either say "bah, electric screwdrivers are crap, I assemble my new IKEA shelf unit without one" or you go back to the store, complain and exchange it for a working one. Unfortunately many Delphi developers including you are doing the first.
ReplyDeleteA. Bouchez i tend to agree with that in an unscientific way. Since somewhere at XE2 i have begun to feel more confused than ever regarding when to use (, [ and <. It's generally much simpler choosing ), ] or >.
ReplyDeleteStefan Glienke You missed my point.
ReplyDeleteWhat I said is that if I need an electric screwdriver, I will use Java or C#.
If I follow your comparison, some of the Delphi modifications would be to suppress half of the handle (RawByteString suppression), add a double handle (string helpers), change the shaft into a Torx (ARC), make your screwdriver break if you want to use it on some kind of screws (e.g. the XE8 TList<..> regression), force me to change the hand I'm using (0-based strings).
IMHO datastructures, patterns (e.g. SOLID) and algorithms have much more importance than code expressiveness, or familiarity with mainstream "standards". Using aString.IndexOf(aChar) or pos(aChar,aString) don't change my mind.
BTW, I find your comment offensive. I use C# as a Senior Dev and Architect, including all its latest features. I'm perhaps less sensitive to hype than other people.
When I saw Barbara's Liskov presentation at https://www.youtube.com/watch?v=GDVAHA0oyJU - I just felt at home.Her POV about Java or C# is refreshing. Her students code in C or C++, even when they do experimentation about new languages - just because they know what they do.
Or when I learned to code in Clojure, it opened new perspectives to me, and made my Delphi code somewhat better.
Far away from syntax sugar.
A. Bouchez Stefan Glienke with Delphi what you get is more like: electric screwdrivers are all you will ever need, so we will remove regular screwdrivers, and give you seriously broken electric one. And if you have to do some fine work that cannot be done with electric screwdriver you are just screwed.
ReplyDeleteExisting features should be left alone, and new features should work, if not they need to be repaired, period.
Actually, no new feature should be released before it is fully functional and polished.
Helpers in Delphi could use allowing multiple ones on a type, otherwise they're mostly a kludge where you get either the built-in ones or have to redo everything or use tricks.
ReplyDeleteDatastructures and algorithms are very important, but IMHO they do not fall in the lap of the language and compiler, they're a different concern. They are part of libraries, frameworks, and such.
On a side note, I'm getting a bit allergic to frameworks: there are just too many of them that try to be all things to everyone, and each of them consider themselves as holistic holy speak.
Eric Grange Please tell us what frameworks you are referring to
ReplyDeleteStefan Glienke not referring to Delphi in particular, but to dev in general. Once upon a time people made libraries or components, now they make frameworks. And they go for fancy things like "convention over configuration" for instance, but each and every one of them goes for different conventions. Take this as a rant, I'm on a KISS trend these days and the delete key is my primary refactoring utility :-)
ReplyDeleteEric Grange Oh in that case I completely agree with you. Most of my refactorings in the past months had more deleted lines than new ones.
ReplyDeleteI share your opinion on frameworks - many of them dictate how you do things. And not in a way that is because of well known principles and patterns but more so because the framework says so.
As for CoC - I very much like it - but only to a point where you are losing control and finding bugs gets harder because a simply typo could make your entire system fail.
I wish every software developer would think about KISS before writing code - it is just horrible how easy it is to write the most complicated code for easy things and then claim "well, its a complex system!"... No, it is not! (in many cases)
Eric Grange Stefan Glienke
ReplyDeleteI do agree with you: if a framework is adding complexity, or force you to do thinks in a single way, then you should not use it.
Point of frameworks, like any other mean of abstraction, is to hide complexity and propose an easier way of solving problems.
This is the whole point of software: relying on abstractions so that we would not have to know how it works.
Binary op-codes are an abstraction over the highly complex execution logic of today's CPUs. Assembly language, and its macros, is another way of abstraction over 0s and 1s. A computer language is another abstraction over assembly language (and you can use the plural on both members of this sentence). Even the RTL could be seen as a framework: a language is not enough - IMHO the greatest interest of PHP or Python was not the language, but their RTL; the node.js library is IMHO of greater interest that JavaScript itself. Last but not least, a framework should hide complexity, and at the same time would leverage your business logic.
You could write the SQL to create a RDBMS table. Plain simple if you know the DB flavor. But an ORM would allow to do it for you, in all supported SQL flavors. And an ODM would allow to use a NoSQL engine, without even knowing what you are working on it.
You could write a REST service by hand, doing the routing and the (JSON/XML) marshaling for each command. Or you can define an interface as contract, write an implementation class, and all the plumbing is done for you by the framework.
A. Bouchez Problem here is not with "a framework" it's with "frameworks" (the final "s" is important).
ReplyDeleteTaken in isolation, each framework attempts to abstract away complexity, taken as a whole, they add a new layer of complexity, which derives from different ways of doing things, different high-level approaches, and usually, pages upon pages of documentation, upon heaps of samples.
You cite SQL and RDMS, well, it can be a good illustration of the problem: frameworks are like RDBMS APIs and RDBMS-specific tools, you have dozens of them, many good in isolation, but forming a vast mess when looked at from a mile high.
On the other hand SQL was a rather successful attempt at normalization, while there are differences, you can do a lot of things using standard SQL that will work across all those RDBMS.
You learn SQL, then the specifics. With frameworks, well, it usually starts with the specifics and you find standards at the edges and in plugins...
Of course when you start small, at the prototype level, or at well-contained short-lived small-team scopes (choose any two), you have one framework, one ORM, and it's all nice and fluffy. But after a while, the real world is more like a collection of frameworks, a collections of ORMs (sometimes the same framework/ORM, but at different versions, which is not much better).
The problem is not having each ORM that can interchange RDMS or NoSQL back-end, it's just that you end up with so many frameworks and ORMs nobody even knows what's there, what is safe to interchange or no longer is. The documentation usually fell behind as well and is not real help.
And you've got convention-over-configuration frameworks, where the code is usually not really self-descriptive because it was written under the assumption that everyone knew the conventions. Except nobody does anymore because the framework has been superseded and the conventions changed, so you're just left with arcane reflection-based code, with no obvious entry or debug point, and where someone confused conventions and assumptions at some point.
KISS, standalone or focused libraries on the other hand, those keep going and going :-) Hehe, rant over.