Re: .NET features you'd like to see in Win32
- From: "m. Th." <a@xxxxx>
- Date: Fri, 15 Jun 2007 11:42:34 +0300
David Clegg wrote:
With the roadmap, and Nicks Delphi Hour chat today, it is becoming
increasingly clear to me that CodeGear are intending to focus a lot of
effort on native development support going forward.
I think that this is probably a pretty wise move, ... <snip>
Agreed with all of above.
To that end, I'd be interested to hear from other .NET developers here
why they choose to develop in .NET. IOW, what .NET features would you
like/need to see in a Delphi Win32 to consider it as a worthy
replacement? Also please note that I will not consider ASP.NET in
itself as an acceptable answer, but would rather hear what it is that
ASP.NET offers that native Delphi web solutions don't.
To get this party started, here is a (non-exhaustive) list of why I
love coding in.NET :-
- Much more powerful RTTI system
Of course. And also add a notification system when a property/event is updated. (QC #46799). It will allow you to (from top of my head - FTOMH):
- implement design by contract way of programming - more productive and safer code (QC #46801, QC #2444) - see also other resources on Web (Wikipedia, Google etc.)
- QC #46723 (ability to update the properties/events to a group of controls when the corresponding property/event in a master control is changed) - in fact is the Observer pattern applied over the entire VCL
- ...also see the (entire) Brian Moelk's very good message on this.
Very important here, imho, is the extensibility of the RTTI, by allowing new metadata to be added/manipulated at run-time IOW annotations like system. See http://en.wikipedia.org/wiki/Java_annotation
Benefits (FTOMH):
- In dynamic UI programming / ECO - other OPFs, object inspectors, grids, self-state inspection at runtime aso.
Eg we have (syntax subject to change of course):
TCustomer = class(TPerson)
....
published
property FirstName: string
annotation
Caption:'First Name',
Description:'The customer''s first name';
//ie. annotation <annotation tag>:<annotation value> [,<tag>:<value>,...];
end;
Another important thing related to RTTI is, imho, the compile-time checked reflection (see Sing# language - the C#'s son - do a google for Microsoft Singularity Transform)
- Richer class library in many respects, with less need to call Win32
apis directly
Yes, of course. As an aside node, one feels here the need of
1. Different non-visual classes, especially data structures (here the generics stuff should be very useful). To be sincere, there were improvements in last Delphi versions, but imho it needs more.
- (Search) Trees
- Maps.
...well, here we can start a religious war about how it can be internally indexed but, imho, all the maps can be reduced to integer (the ordinal type keys), hash (strings), double/extended (floating point types including TDateTime). A very special case is when one wants to do a map with map [<TObject descendant>]. In this, case, imho is appropriate to have as index an integer (ie. the pointer to that object). If the object is freed, the programmer is responsible to remove the map reference.
Why? In order to be productive one must concentrate on what to do it, not on how to do it. The *How* is the most brain intensive and the less effective. It will be a big advantage to have a verified, standard code for *how*.
2. Different patterns implemented using generics.
Why?
<quote>
The gap between the best software engineering practice
and the average practice is very wide—perhaps wider than in
any other engineering discipline. A tool that disseminates
good practice would be important.
—Fred Brooks
</quote>
This would be a huge gain in productivity, imho. IIRC, Joanna posted something related in the 'Generics in Delphi' thread. Also, consider the possibility of implementing (the most known/used) patterns as language elements. We have already one (as a simple visitor pattern, thus enhancing sensible the quality of code): for .. in ... do
3. LINQ/OCL-like frameworks/ways of writing code. Obvious, imho.
- Enterprise Core Objects
Definitely.
Today, imho, it's a _must_ the centralized approach to large amounts of _informations_ (information := data with human meaning) not only as quantity (ie. no. of rows for ex.) but also as diversity (no. of relations in a (SQL) db for ex.). So, a central point to manage and evolve unitary the trinity between presentation layer - <binded to> - business objects - <binded to> - (often 3rd party vendor) data source.
A tool which will manage (theoretically) all the end points (ie. screen, printer, web data points in various forms - relational, XML, txt etc.), points which can be both destination and source points, would be important. Also, imho, this tool must be two-way, more like a framework rather than a very distinct entity a la Together. IOW, one must have the possibility to use parts of it (via 'uses' clause for ex.) if he needs in his code. Today, AFAIK, we are in the epoch in which is crucial for developer to master his data flow and properly filter it from/to his data points.
- Ability to seamlessly interop with other languages
On native Win32/64? What do you mean? Please elaborate. (Ok, while on .NET this is easy, on native how do you want to accomplish it?) Especially regarding the "seamlessly". Perhaps something a la PostgreSQL ie. something like:
Unit Main.pas
Uses Windows;
begin
for i:=1 to 10 do
cpp
sscanf(..);
printf(...);
end;
end;
I my (personal) POV the seamlessly interop with asm is all what I need.
- Ability to treat everything as an object
Not so excited about this...
- Ability to easily take advantage of articles and code snippets
primarily intended and written for the much larger Microsoft
development community (granted, another problem not easily solved)
Yes, of course. But how can CG solve this?
- Ability to target other devices such as PocketPC
7 points out 10.
- Ability to databind UI components to pretty much anything
10 points out 10. See the RTTI discussion above.
- The use of interfaces to allow objects to implement functionality and behaviours used by other FCL classes (e.g IComparable, IEnumerable)
9 points out 10.
- To a lesser extent, Garbage Collection
If CodeGear has (almost) nothing else to do then will be a good addition. But I rather prefer to concentrate on other things which are much more important, imho.
Perhaps some keywords like 'auto', 'autocreate', 'autodestroy' to do Garbage Collection only on specified objects will be something 'nice-to-have' (but not 'must-have', imho).
Other things from .NET "we'd like to see in Win32":
- Multi-core issue. See the 'Top 3 VCL requests' thread. The discussion there was mainly about 'thread-safe' VCL (which is a very difficult thing, imho) which turned, in fact, to finding a better way to communicate between threads (which is a much more 'doable' thing). Ie. a language feature to command other threads (post messages) _with(out)_ passing the data in the ways in which developer chooses to (ie. sync, async aso.). While a compiler fully multi-core aware is a big matter imho (as correctly Nick pointed out), the language enhancements proposed in that thread (at least some of them) it seems that are rather easy to implement, (even if I don't know, of course, the dcc internals).
- Lambda calculus stuff. In fact, Delphi supports this in a large degree. But imho it needs improvement, especially to make more transparent to developer the difference between a function which is 'of object' and a simple (regular) function.
- Improved debugging. Stack trace outside of IDE, logging aso. Already implemented in some products (JCL, CodeSite, SmartInspect etc.). Better support from Delphi's side. From the developer's side, imho, integrating the JCL's engine is more than sufficient.
If a large subset of these could be brought to the native Delphi world,
I think it would certainly make Delphi a unique and very compelling
solution for developers targeting Windows platforms. Imagine having
all/most of the benefits that .NET gives the developer, but without the
added overhead that the CLR brings? Bring it on, I say!
Yes, of course. But why steer on .NET only? There are more very well designed languages. For example one of the programming languages which competes now Delphi in business area is D (according to Tiobe). And if someone goes to http://www.digitalmars.com/d/index.html perhaps will understand why...
my 2c,
m. Th.
----------
PS: There are more other things what 'we'd like to see in Win32' but the thread is about .NET only ;-)
.
- Follow-Ups:
- Re: .NET features you'd like to see in Win32
- From: David Clegg
- Re: .NET features you'd like to see in Win32
- References:
- .NET features you'd like to see in Win32
- From: David Clegg
- .NET features you'd like to see in Win32
- Prev by Date: Re: What is the value of a cancellation?
- Next by Date: Re: .NET features you'd like to see in Win32
- Previous by thread: Re: .NET features you'd like to see in Win32
- Next by thread: Re: .NET features you'd like to see in Win32
- Index(es):
Relevant Pages
|
