Re: What I'd Like to See in Delphi

John Jacobson wrote:
I've mentioned this before, but I think this bears repeating, given that Delphi probably has been given new legs by the buyout. Here is what I'd love to see in Delphi, but have never seen it:

1) Backward compatibility between brand new IDEs and old versions of the
VCL. I've often had to work on projects that are in D7 or D5, and could not
be upgraded to a newer version of the VCL, but wanted to use the latest IDE
so I could get things like refactoring, etc.

I agree (in a limited manner). If this is easy for them (especially to not play 'ping-pong' with the units), it should, keep an eye on it.

2) Built-in profiler, that shows line by line timings right in the IDE
editor (like TurboPower's SleuthQA 3 used to).


+1! QC #9939 - vote for it! (mind you, now we have 10 votes/report)

3) Cross-platform compiles, for Win32, Linux, the Mac, Solaris, etc.


Linux, MacOSX: +1. QC #8802 - vote for it. But with the mention that at least today, Linux really counts only on server side. See desktop market at:

http://marketshare.hitslink.com/report.aspx?qprid=8

vs (internet) servers market share at:

http://news.netcraft.com/archives/2008/04/14/april_2008_web_server_survey.html

....also I want to mention that I pleased with the current roadmap. We need first a Delphi (on Windows) and after this, a cross-compiling one.

Solaris? - don't know. I'm quite reserved on this one. Very small market share. There are also CPU issues. Rather something for PDA/mobile (ARM). Also we must conserve their R&D resources for some more faster and sure ROI.

4) VCL updated to include:
a) Regular Expressions functions

My (very) personal opinion: 3 out of 5.
QC #1121 - this is in a very odd status. It seems that it was tried and now is inactive. Perhaps someone can (re)open it?

b) XML parsing/serialization

Personally not interested very much. But I *do* understand your request.

c) threadsafe properties for GUI components (see the signals and slots
mechanism in Qt for an example of how to do this right)

I'd rather vote for a state-of-the-art human-mimic message passing mechanism like the one to be found in Erlang (see Actor model on Wikipedia) or in Ada (Google for Ada Rendezvous). This would help us also to do grid/cloud computing. Also, the additional properties of the same problem I pointed out in a discussion with Barry Kelly in one of the sub-threads above:

<quote from my previous message>

Well, for parallel programming I, for one, certainly feel the need of a VM (in the way in which you defined it) simply because the actual CPU architecture is far (imho) from the way in which humans deal with the reality which is parallel. Look at the game theory. The vast majority of the games you have to deal with /different/ characters doing /different/ actions (tasks) in parallel, responding each one to the stimuli which comes from the environment. Imho, that's why the Actor model (http://en.wikipedia.org/wiki/Actor_model) fits so well in parallel programming. Also, it seems that as a reaction to thread programming, we go now to parallel libraries, thing which is beneficial imho, but we tend to forget two properties from thread programming model which maps to the human way of thinking. Priority and worker(s) (read: CPU affinity). Imho, we should be able to say 'Do this faster, do this slower/when you have time' or 'Leave a worker (ie. core) for UI, 25% from "workers" for burst, small actions which need to be executed real-time, and the other ones use for the daily work. But perhaps I'm wrong. But now I remember your blog post about games... :-) (Yes, we *do* read your blogs, keep them coming)

</quote>

Also the above open the possibilities not only for cross-platform, distributed computing but also for cross-language computing. QC #56795

Here a visual way to manage the tasks/threads (intercommunication, debugging /especially/ etc.) would make a big difference. For ex. see for a start the researches in the area. (Google for 'parallel debugger' and 'Intel parallel debugger') For example, see the theory at http://www.gup.jku.at/~dk/thesis/fm2html/ and some implementations at

http://www.allinea.com/?page=48
http://www-cse.ucsd.edu/users/berman/panorama.html

and of course

http://www.intel.com/cd/software/products/asmo-na/eng/threading/219785.htm

d) automatic hotkeys in captions

Don't understand what you mean. Something like '&Print' enables the Alt+P kotkey?

e) PAR, PAR2, RAR, ZIP attachment decoding/recombining

Hummm... I feel a newsreader aroma around here... :-) Personally I would implement a general (de)compression engine and on top of it I would add such things (perhaps using mixins - the things would be more easier, imho?. Only a decompression/decoding engine?... too specific. However, for ZIP there is zlib, RAR is proprietary (they must pay license fees for compressor, *if* Eugene is willing to allow them). PAR, PAR2 - dunno.

f) HTML browser (like pBear's stuff)

Hummmmm... (again). And they must maintain and update it, isn't? And this, if we look at the complexity of today's 'standards' must be a very daunting thing. If is something simple, like for ex. an /editor/ in a RIEA application (see Mike Rozlog's blog) then this is a terrific opportunity since Dave Baldwin (aka pBear) put them in public domain. For a HTML rendering engine, we have already TWebBrowser, and if we go x-platform then the Mozilla's stack (or Safari's WebKid) are way more indicated, imho.

g) skinning

....eh... perhaps a wider coverage would be QC#56025 - OpenGL support. Also useful for cross-platform matter. Vote for it.

h) Flash player

Personally I find it too specific. And not in Delphi's main focus. But if is easy...

i) inter-process TAction descendent (you should be able to set an
TAction's property in one program and have it updated in another)


If you'll have the message passing mechanism described at c). (the parallel programming point) then you can do it.

5) Ability to mix (fully compliant) C++ and Delphi files promiscuously in
the same project, with the compiler doing any housekeeping needed to let C++
see Delphi classes transparently and vice versa.


Cannot say here. Perhaps Barry jumps in to enlighten us. But I fear that C++ means VC, GnuCpp, BCB, Watcom, Digital Mars...

6) Method-parameter-aware run-time error logging. In other words, something
like EurekaLog, but able to do a dump of the actual parameter values passed
into a method when it crashed.



JEDI has something close. Also, because there are in this market segment only few big players (ie. the market is very mature), embedding one of them right in the IDE is a very 'tricky' thing (except JEDI's offering which anyway is free and in D2007 they use it already).

Also, can I dare to put my wishes? :-)

1. Synchronization engine between DB schema and its representation in the language.

A very important phenomenon here is that today we have two worlds:
the compiler with it's compile time checks eg. 'Unknown identifier',
'Expected <A> found <B>' etc. and OTOH the database engines with their
checks ie. 'You cannot drop Field1 because is referenced in View1',
'Cannot change the definition of StoredProc1. Referenced in View2' etc.
Now, by joining CodeGear and DatabaseGear/Embarcadero imho would be a
huge opportunity to have a tool to unite this two worlds. Ie. a 'button'
which would check the sync between the metadata representation in the
language and the actual db schema.

Also, here a very neat feature would be a button which would open/prepare all/selected datasets thus throwing any error caused by the desynchronized schema representations in db and language.

2. New composition ways. For ex. mixins (seen as a combination between mixins and traits). QC #53402

3. Metaprogramming/runtime compiler QC #62319

4. Delegates - Code unit (ie. functions/procedures) pointer unification. Ability to pass/convert a 'of object' code unit as a regular one. Same stands for local code units. For example having a procedure 'DoMyJob(aJob: TMyProcedure)' to have the ability to pass it either a method, either a local proc, given that it has the same calling syntax. QC #56363

5. Multicast events QC #56364

6. ECO (or another OPF) for Win32 and (in the future) for x-platform.
QC #46720

7. Multiple cursors per dataset. QC #56796

....just my 0.07 cents, :-)

--

m. th.
.

Quantcast