Attention Inprise!!...Things STILL missing in Delphi 4...
A Ranter
that should be in Delphi 4 but are STILL missing...Maybe you can help
with some of your ideas.
1. A 32 bit Browse Folder dialog wrapper of WinAPI SHBrowseForFolder.
2. A Printer Page Setup Dialog wrapper of WinAPI equivalent.
3. A Print Preview dialog
4. Inplace Checkboxes capabilities for DBGrid bi-state fields
5. A TEdit control whose background goes grey when disabled like it
should by default.
6. An easy to use BDE Idapi configuration wrapper class for adding
Idapi aliases/drivers and their default settings.
7. VXD virtual device driver writing capabilites
8. UndoBufferCount property for TRichEdit
9. Default JPeg, Gif support in TPicture
10. Form Header Colour fade capabilities like MS apps
11. Automatic Code formatting like Kinetic Software's brilliant
CrackerJax
12. Recurse sub-directories option on Project Paths
13. Cut Copy & Paste options on Unit editor Popup menu
14. Browse Directories button for Project Paths
15. Path Aliases option for Project Paths
{$PROJ1} = C:\mylongpath\myprojects\project1\
16. File handling wrapper class to wrap WinAPI SHFileOperation
17. A TrayIcon component
18. A TCP/IP address edit component
19. A simple help file creator
20. Internationalization tool
21. Reparentage option on selected components - so you can move
selected components into a Groupbox / Panel easily etc
22. Minimize / Maximize / Restore animation and sound workaround for
main form operations. (Delphi has hidden App form which prevents this
doh!)
23. A file visual difference tool
I could go on for ever.
OK, so some of these options you can buy in / get free from Third
parties, but they SHOULD be part of the Delphi parcel. Inprise sort
your shit out, listen to the masses for once, stop raking in massive
profits, invest and get basic missing functionality put into your star
product... things that should have been in there years ago.
A Ranter
Paul
asps...@tcp.co.uk
^^ remove 'as' anti spam prefix to reply
Mab
I think a few of these are ill-founded...
>I HAVE A DREAM......That is, to bring to Inprise's attention things
>that should be in Delphi 4 but are STILL missing...Maybe you can help
>with some of your ideas.
>
>1. A 32 bit Browse Folder dialog wrapper of WinAPI SHBrowseForFolder.
SelectDirectory uses the SHBrowseForFolder dialog in D4 (provided you
use the correct parameters - see the help)
>6. An easy to use BDE Idapi configuration wrapper class for adding
>Idapi aliases/drivers and their default settings.
Doesn't "Session" give you this sort of power? I've been doing it
since Delphi 1.
>10. Form Header Colour fade capabilities like MS apps
This happens automatically in Win98 when you're running high-colour.
Seems a bit redundant to build it in.
>16. File handling wrapper class to wrap WinAPI SHFileOperation
I'm intrigued as to what this class would look like. If it's just a
collection of methods, then why bother?
>18. A TCP/IP address edit component
I agree that if Inprise support any custom controls, then they should
support all of them. However, you can easily do this one with a
maskedit. It was a dumb idea to make it a custom control in the first
place, IMHO.
>21. Reparentage option on selected components - so you can move
>selected components into a Groupbox / Panel easily etc
That's what the clipboard is for.
>OK, so some of these options you can buy in / get free from Third
>parties, but they SHOULD be part of the Delphi parcel. Inprise sort
>your shit out, listen to the masses for once, stop raking in massive
>profits, invest and get basic missing functionality put into your star
>product... things that should have been in there years ago.
Quite a lot of the options which I didn't bother quoting can be found
free on the DSP. There were one or two which I agree with, but in
general I think Inprise are doing just fine with Delphi.
Perhaps we should complain louder about releasing products with bugs
(as D4 seemed to have) rather than missing "features"...
Just my 2c.
Mab
A Ranter
>In article <36a70d25...@news.tcp.co.uk>, someone calling themselves ARa...@rant.com (A Ranter) wrote:
>
>I think a few of these are ill-founded...
>
>>I HAVE A DREAM......That is, to bring to Inprise's attention things
>>that should be in Delphi 4 but are STILL missing...Maybe you can help
>>with some of your ideas.
>>
>>1. A 32 bit Browse Folder dialog wrapper of WinAPI SHBrowseForFolder.
>SelectDirectory uses the SHBrowseForFolder dialog in D4 (provided you
>use the correct parameters - see the help)
Does not give events, full properties, or full options on what roots
the dialog shows.
>
>>6. An easy to use BDE Idapi configuration wrapper class for adding
>>Idapi aliases/drivers and their default settings.
>Doesn't "Session" give you this sort of power? I've been doing it
>since Delphi 1.
No, that is basic settings, not advanced options. Ever done any Idapi
configuration for a Server alias, say e.g. Oracle...I presume not.
>
>>10. Form Header Colour fade capabilities like MS apps
>This happens automatically in Win98 when you're running high-colour.
>Seems a bit redundant to build it in.
Then why do so many people ask how to do it so often?
>
>>16. File handling wrapper class to wrap WinAPI SHFileOperation
>I'm intrigued as to what this class would look like. If it's just a
>collection of methods, then why bother?
For events, callbacks, progression bar capabilities etc.
>
>>18. A TCP/IP address edit component
>I agree that if Inprise support any custom controls, then they should
>support all of them. However, you can easily do this one with a
>maskedit. It was a dumb idea to make it a custom control in the first
>place, IMHO.
I mean the MS style, not a masked edit (Delphi 4 MaskEdit doesn't even
work properly according to D4 bugs list at Inprise.)
>
>>21. Reparentage option on selected components - so you can move
>>selected components into a Groupbox / Panel easily etc
>That's what the clipboard is for.
What, so when you paste you sometimes lose positions, and captions get
reset to match component name....yeah that's good.
>
>>OK, so some of these options you can buy in / get free from Third
>>parties, but they SHOULD be part of the Delphi parcel. Inprise sort
>>your shit out, listen to the masses for once, stop raking in massive
>>profits, invest and get basic missing functionality put into your star
>>product... things that should have been in there years ago.
>
>Quite a lot of the options which I didn't bother quoting can be found
>free on the DSP. There were one or two which I agree with, but in
>general I think Inprise are doing just fine with Delphi.
DSP is great, but there is no standardisation, many different
solutions to same requirements, some components etc are written very
hacky, and also some don't come with source - source is a necessity.
>Perhaps we should complain louder about releasing products with bugs
>(as D4 seemed to have) rather than missing "features"...
Agreed, bugs are annoying but so is basic missing functionality.
>Just my 2c.
Some fair comments, but I still have a dream! ;o)
ARanter
Quoc Thang Nguyen
ARa...@rant.com (A Ranter) wrote:
>I HAVE A DREAM......That is, to bring to Inprise's
attention things
>that should be in Delphi 4 but are STILL missing...Maybe
you can help
>with some of your ideas.
>
>7. VXD virtual device driver writing capabilites
This newsgroup has adressed this question before. First, it
is not technically possible (linker, run-time libraries,
compatibility with the DDK macros etc...), second, VxDs are
dead. As a matter of fact, I have been advised to rewrite my
VxD (which took months of writing/debugging/finetuning...)
into a WDM driver (which will run, in theory, both under
Win98 and WinNT). You can imagine my joy...
The reason is that Win98 is the end of the road for all the
Windows versions based on the original Windows/386
(remember?), which include Windows 3.x and 9.X. MS is
pushing everybody into Windows 2000 (formely known as
Windows NT 5.0).
I don't know if it is possible to write Windows NT drivers
with Delphi, but you can have a look at the Windows 2000
DDK, which can be downloaded from free at www.microsoft.com
(I think somewhere in the hardware section).
Just my opinion.
REMOVE nospam. in my address
Please note our recent change of area code from
714 to 949
Quoc Thang NGUYEN
Laboratory of Cellular and
Molecular Neurobiology
Dept. of Psychobiology
University of California, Irvine
Irvine, CA92717 USA
Ph: (949) 824-4730
Fx: (949) 824-3522
Martin Harvey
>
> I HAVE A DREAM......That is, to bring to Inprise's attention things
> that should be in Delphi 4 but are STILL missing...Maybe you can help
> with some of your ideas.
I too have a dream... that they fix the existing stuff before working on
anything too new and fancy.
MH.
--
Martin Harvey.
Totally rewritten web pages at:
http://www.harvey27.demon.co.uk/mch24/
"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors". C.A.R. Hoare
--------------BEGIN GEEK CODE BLOCK--------------
Version: 3.12
GCS/CC d(+) s-:- a-- C+++$ UL@ P L@>++ E- W++
N+++ o-- K++ w+++$ O--- M-- V-- PS@ Y-- PGP-
t--- 5-- X-- R-- !tv b+ DI+ D+ G e++ h- r z++>---
---------------END GEEK CODE BLOCK---------------
You think my sig is long? Just you wait until I attach a
uuencoded wav of Mahler II to it...
Steve Koterski
>I HAVE A DREAM......That is, to bring to Inprise's attention things
>that should be in Delphi 4 but are STILL missing...Maybe you can help
>with some of your ideas.
I will forward your suggestions to Delphi development. However, in the
future, you might want to submit suggestions like these yourself through
the official venue we provide for that purpose. This will ensure that you
are heard. As it was, you were not heard and so had 0% chance of seeing
your suggestions implemented.
Submit suggestions like these through the Delphi bug-reporting Web page at
the URL below. This page is not just for bug, but also for product
improvement suggestions.
http://www.inprise.com/devsupport/bugs/bug_reports.html
[...]
>I could go on for ever.
>
>OK, so some of these options you can buy in / get free from Third
>parties, but they SHOULD be part of the Delphi parcel. Inprise sort
>your shit out, listen to the masses for once, stop raking in massive
>profits, invest and get basic missing functionality put into your star
>product... things that should have been in there years ago.
Your writing and ... um ... vernacular certainly are colorful. Is s**t
really a technical term? Seriously though, "raking in massive profits"?!
That one had me rolling on the floor laughing. Cool!
Still, we do listen to the masses ... if they make themselves heard. Use
the bug-reporting page (or the Inprise-spnsored newsgroups) and you will
indeed be heard. Nothing can guarantee that any or all of your suggestions
would actually be implemented, but they will at least be seen and
considered.
//////////////////////////////////////////////////////////////////////////
Steve Koterski "Writers have two main problems. One is
Technical Publications writer's block, when the words won't come
INPRISE Corporation at all, and the other is logorrhea, when
http://www.inprise.com/delphi the words come so fast that they can
hardly get to the wastebasket in time."
-- Cecelia Bartholomew
Paul S
Koterski) wrote:
>On Wed, 20 Jan 1999 00:02:08 GMT, ARa...@rant.com (A Ranter) wrote:
>
>>I HAVE A DREAM......That is, to bring to Inprise's attention things
>>that should be in Delphi 4 but are STILL missing...Maybe you can help
>>with some of your ideas.
>
>I will forward your suggestions to Delphi development. However, in the
>future, you might want to submit suggestions like these yourself through
>the official venue we provide for that purpose.
> This will ensure that you
>are heard. As it was, you were not heard and so had 0% chance of seeing
>your suggestions implemented.
But you heard, and you responded, so it seems you care; and as you
work for Inprise maybe hearing people who kick up a little fuss on
public forums - via people like you - get the cogs of the great
Inprise machine rolling. I hope.
I, and many other developer friends, have submitted bugs/suggestions
to http://www.inprise.com/devsupport/bugs/bug_reports.html
Not once have we received a reply or indication of what Inprise are
doing about them. So why bother filling out Inprise's tediously long
request form, especially when you get nowhere? When people send bugs
/ suggestions they want it to be quick efficient, and they want to
know what is happening about them. Just like the Delphi Bugs List Web
Site submission / response is, maybe Inprise should absorb DBLWS's
effective principle a little.
>Your writing and ... um ... vernacular certainly are colorful. Is s**t
>really a technical term?
No, it's frustration, in reflection I apologise for the vulgarity.
But I still think they do have a mess with Delphi 4 that needs
addressing - bugs, instability, lack of customer confidence, lack of
open forum for suggestions. Get me a managerial job there in the
Delphi Dev/Support Department, I'll focus it and sort the "s**t" out
<grin>.
>Seriously though, "raking in massive profits"?!
>That one had me rolling on the floor laughing. Cool!
Any profit margins over 7 figures seems considerable to little old me
;o), Inprise have raised the Borland ship from deep dank depths and is
doing quite well from what I can gather. Growth in the Inprise
enterprise seems spritely.
>
>Still, we do listen to the masses ... if they make themselves heard.
I am making myself heard.
>Use
>the bug-reporting page (or the Inprise-spnsored newsgroups) and you will
>indeed be heard. Nothing can guarantee that any or all of your suggestions
>would actually be implemented,
Exactly, are suggestions ever implemented by Inprise? One example
Cut/Copy/Paste on Unit edit popup menu. Myself and others have asked
for that since Delphi 1. An easy task, about 10 minutes work for
Inprise. Is it there in the 4th Major release? No. QED Inprise.
Compare this to Oracle, they can't do enough for you, quick replies,
easy suggestion forums, reliable releases, an expanse of tools and
functionality, which is why people have faith in them. Their users
get excellent customer support and results, they breed confidence and
Oracle gets massive growth and $$$$ Kerching.
>but they will at least be seen and
>considered.
I am a natural cynic toward Inprise, I think otherwise.
>Steve Koterski
>Technical Publications
>INPRISE Corporation
Regards
A Ranter
An apt verse for Inprise....
"Deaf are those whom hide a glowing fortune, from poverty who begs a
shining relief." - Gail Cameron.
George R Smith
documentation that they once had. I suggest they not only look at the
language documentation of Pascal but look at the book that came with the
Game Toolbox programs.
HOWEVER, to set up ORACLE as an example of good support shows perhaps a
morbid sense of humor.
By the way, I bought BORLAND at 58.00 and am still holding on. I hope they
not only survive but prosper.
Stefan Hoffmeister
>Exactly, are suggestions ever implemented by Inprise?
Have you ever looked at http://www.gexperts.com/gexperts/ ?
--
Stefan Hoffmeister (http://www.econos.de/)
No private email, please, unless expressly invited.
pe...@bigfoot.com
ARa...@rant.com (A Ranter) wrote:
> I HAVE A DREAM......That is, to bring to Inprise's attention things
> that should be in Delphi 4 but are STILL missing...Maybe you can help
> with some of your ideas.
>
You left out the most important thing. Garbage collection. GC is essential,
especially for event driven systems where very often it is difficult, or
impossible, to tell when an object should be freed. I cannot believe that
after four major releases Object Pascal is still without this. Every OO
language I know of has garbage collection except C++ (perhaps the worst
language ever) and Object Pascal.
--
Peter E. Williams pe...@bigfoot.com
Software Developer
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Jonathan W Hendry
> In article <36a70d25...@news.tcp.co.uk>,
> ARa...@rant.com (A Ranter) wrote:
> > I HAVE A DREAM......That is, to bring to Inprise's attention things
> > that should be in Delphi 4 but are STILL missing...Maybe you can help
> > with some of your ideas.
> >
> > 1. < a lot of stuff removed >
> You left out the most important thing. Garbage collection. GC is essential,
> especially for event driven systems where very often it is difficult, or
> impossible, to tell when an object should be freed. I cannot believe that
> after four major releases Object Pascal is still without this. Every OO
> language I know of has garbage collection except C++ (perhaps the worst
> language ever) and Object Pascal.
GC isn't necessarily essential. NeXT/Apple's system, called
'retain/release', works quite well even though it's not
completely automatic. It also works reasonably well in distributed
applications (which can be a difficulty in GC, IIRC) and in
apps with enormous numbers of objects in memory. (For example,
database apps where each record fetched is an object, and
strings and numbers contained in each record are also objects)
The language in this case is NeXT's Objective-C.
There's a very good description of the system in the following PDF file:
This would also, I think, mesh reasonably well with the reference
counting used for Interfaces.
Steve Koterski
[...]
>But you heard, and you responded, so it seems you care; and as you
>work for Inprise maybe hearing people who kick up a little fuss on
>public forums - via people like you - get the cogs of the great
>Inprise machine rolling. I hope.
I heard *once*, this is true. But my Internet connection to these external
newsgroups is not entirely on the up-and-up and is sometimes interrupted by
downtime. So I may not hear every time.
>I, and many other developer friends, have submitted bugs/suggestions
>to http://www.inprise.com/devsupport/bugs/bug_reports.html
>Not once have we received a reply or indication of what Inprise are
>doing about them. So why bother filling out Inprise's tediously long
>request form, especially when you get nowhere? When people send bugs
>/ suggestions they want it to be quick efficient, and they want to
>know what is happening about them. Just like the Delphi Bugs List Web
>Site submission / response is, maybe Inprise should absorb DBLWS's
>effective principle a little.
For perspective, I work in Technical Publications. I am not in, part of,
nor affiliated with Developer Support, the group that administers. I do not
make excuses for any short-comings of that system and I do not take any
credit where it does well.
I can pass on one fact, though. As I understand that system, responses to
bug-reports through that Web page are limited to those people reporting who
also have a PIN number. For whatever reason (not known to me), only US and
Canadian users are able to get/have PINs. Without a PIN, no association to
the record in the customer table with the e-mail address, and hence to
automated response confirming receipt.
>>Your writing and ... um ... vernacular certainly are colorful. Is s**t
>>really a technical term?
>No, it's frustration, in reflection I apologise for the vulgarity.
>But I still think they do have a mess with Delphi 4 that needs
>addressing - bugs, instability, lack of customer confidence, lack of
>open forum for suggestions. Get me a managerial job there in the
>Delphi Dev/Support Department, I'll focus it and sort the "s**t" out
><grin>.
While others here (and elsewhere) debate the attributes you cite to no end,
there is one I would like to comment on: an open forum for suggestions (and
discussion). We do provide such and in a couple different forms.
The first (for bugs and suggestions, not for discussion) I have already
mentioned, the bug-reporting Web page. Items entered there are seen by
Inprise and acted upon. I can say this from personal experience, having
fixed a number of problems reported through this means.
The second is the set of Inprise-sponsored newsgroups. Go to the URL below
this paragraph for more information, including how to get to these
newsgroups and the names of specific newsgroups. There is _considerably_
more traffic in those newsgroups than in these public newsgroups, a
presence of Inprise employees (from developers to managers to support
engineers) and representatives, and a higher ratio of answers to questions.
In additions to outright questions, there is a lot of discussion and
advocacy going on in these newsgroups, especially in the Non-Technical
newsgroups.
http://www.inprise.com/newsgroups/
[...]
>Any profit margins over 7 figures seems considerable to little old me
>;o), Inprise have raised the Borland ship from deep dank depths and is
>doing quite well from what I can gather. Growth in the Inprise
>enterprise seems spritely.
We are surviving. That is as far as I would comment there. "Massive
profits" is a very gross inaccuracy. Profits, yes. Massive, not by a long
shot -- at least not yet...
[...]
>Exactly, are suggestions ever implemented by Inprise? ... I am a
>natural cynic toward Inprise, I think otherwise.
Yes, customer suggestions are implemented. Is every suggestion made
implemented? Highly doubtful. Go to the Inprise-sponsored newsgroups (not
gonna cost you anything) and pose this question there. Who knows? You might
just get a response indicating why that one particular suggestion
(Cut/Copy/Paste on Unit edit popup menu) never made it in the product.
Ray Lischner
Koterski) wrote:
>I can pass on one fact, though. As I understand that system, responses to
>bug-reports through that Web page are limited to those people reporting who
>also have a PIN number. For whatever reason (not known to me), only US and
>Canadian users are able to get/have PINs. Without a PIN, no association to
>the record in the customer table with the e-mail address, and hence to
>automated response confirming receipt.
That may be the theory, but I have a PIN, but I have never received a
response. (Well, I received one: asking for more information. After I
provided the requested info, I never heard again.)
--
Ray Lischner (http://www.tempest-sw.com/)
Author of "Hidden Paths of Delphi 3: Experts, Wizards, and the Open Tools API"
Ray Lischner
>You left out the most important thing. Garbage collection. GC is essential,
>especially for event driven systems where very often it is difficult, or
>impossible, to tell when an object should be freed. I cannot believe that
>after four major releases Object Pascal is still without this. Every OO
>language I know of has garbage collection except C++ (perhaps the worst
>language ever) and Object Pascal.
Objective C does not have GC.
Many non-OO languages have GC.
Most ideas in computer science were invented in the 1960s, such as
graphical user interfaces, object-oriented programming, and more.
Garbage collection, however, was invented in the 1950s. I find it
outrageous that programming language designers still don't get it, over
four decades later. Some people believe, for example, that GC is "slow."
The original mark-sweep collectors of the 50s and 60s are slow, but so
what? The compilers from the 50s and 60s were slow, too. Modern GC is
usually faster than manual memory management.
Maeve Kennedy
21. Reparentage option on selected components - so you can move
: selected components into a Groupbox / Panel easily etc
I'm new to Delphi. I just tried to copy a button on the form,
on top of a groupbox - then selected "move forward",or "send to back",
to be able to view the buttons. I guess you're saying that these
kinds of buttons won't have the group box as a parent?
In article <36a70d25...@news.tcp.co.uk>, ARa...@rant.com says...
: I HAVE A DREAM......That is, to bring to Inprise's attention things
: that should be in Delphi 4 but are STILL missing...Maybe you can help
: with some of your ideas.
:
: 1. A 32 bit Browse Folder dialog wrapper of WinAPI SHBrowseForFolder.
: 2. A Printer Page Setup Dialog wrapper of WinAPI equivalent.
: 3. A Print Preview dialog
: 4. Inplace Checkboxes capabilities for DBGrid bi-state fields
: 5. A TEdit control whose background goes grey when disabled like it
: should by default.
: 6. An easy to use BDE Idapi configuration wrapper class for adding
: Idapi aliases/drivers and their default settings.
: 7. VXD virtual device driver writing capabilites
: 8. UndoBufferCount property for TRichEdit
: 9. Default JPeg, Gif support in TPicture
: 10. Form Header Colour fade capabilities like MS apps
: 11. Automatic Code formatting like Kinetic Software's brilliant
: CrackerJax
: 12. Recurse sub-directories option on Project Paths
: 13. Cut Copy & Paste options on Unit editor Popup menu
: 14. Browse Directories button for Project Paths
: 15. Path Aliases option for Project Paths
: {$PROJ1} = C:\mylongpath\myprojects\project1\
: 16. File handling wrapper class to wrap WinAPI SHFileOperation
: 17. A TrayIcon component
: 18. A TCP/IP address edit component
: 19. A simple help file creator
: 20. Internationalization tool
: 21. Reparentage option on selected components - so you can move
: selected components into a Groupbox / Panel easily etc
: 22. Minimize / Maximize / Restore animation and sound workaround for
: main form operations. (Delphi has hidden App form which prevents this
: doh!)
: 23. A file visual difference tool
:
: I could go on for ever.
:
: OK, so some of these options you can buy in / get free from Third
: parties, but they SHOULD be part of the Delphi parcel. Inprise sort
: your shit out, listen to the masses for once, stop raking in massive
: profits, invest and get basic missing functionality put into your star
: product... things that should have been in there years ago.
:
: A Ranter
:
Paul S
Kennedy) wrote:
>About #21--
>
> 21. Reparentage option on selected components - so you can move
> : selected components into a Groupbox / Panel easily etc
> I'm new to Delphi. I just tried to copy a button on the form,
>on top of a groupbox - then selected "move forward",or "send to back",
>to be able to view the buttons. I guess you're saying that these
>kinds of buttons won't have the group box as a parent?
If you put a button on a Groupbox/panel then they will be the buttons
parent. If you drop a button on a form, then a Panel on the form, you
cannot re-parent the button from the form to the panel without using
cut and paste. If you forget you have copied a component to the
clipboard and cut something else, you lose it. "Reparent" would be a
lovely little feature, and wouldn't suffer from clipboard overwrites.
Paul
Laurent Martelli
> GC isn't necessarily essential. NeXT/Apple's system, called
> 'retain/release', works quite well even though it's not
> completely automatic. It also works reasonably well in distributed
> applications (which can be a difficulty in GC, IIRC) and in
> apps with enormous numbers of objects in memory. (For example,
> database apps where each record fetched is an object, and
> strings and numbers contained in each record are also objects)
GC can be done efficiently in a ditributed environment. See
http://www-sor.inria.fr/projects/sspc/
--
Laurent Martelli
Lasse Vågsæther Karlsen
<l.mar...@itecor.com> wrote:
>Jonathan W Hendry <jhe...@shrike.depaul.edu> writes:
>
>> GC isn't necessarily essential. NeXT/Apple's system, called
>> 'retain/release', works quite well even though it's not
Isn't GC indeterministic? Meaning (in my understanding of the word in
this case) that you can never be sure how long a memory allocation
will take. Wouldn't GC take exponentially longer the more memory the
computer has?
Mind you, I have only basic understanding of how GC works, but that's
the two main things I think would be a downside to it.
Also, how does GC handle circular references? If I have a doubly
linked list, how does it determine that it's no longer in use if I
just sever the connection the program has to it? Now that almost all
memory allocated in, say, Delphi, is dynamic, how can it distinguish
between active and non-active parts?
--
Lasse Vågsæther Karlsen
Cintra Software Engineering AS
la...@cintra.no
Laurent Martelli
>
> On 25 Jan 1999 11:26:13 +0100, Laurent Martelli
> <l.mar...@itecor.com> wrote:
>
> >Jonathan W Hendry <jhe...@shrike.depaul.edu> writes:
> >
> >> GC isn't necessarily essential. NeXT/Apple's system, called
> >> 'retain/release', works quite well even though it's not
>
> Isn't GC indeterministic? Meaning (in my understanding of the word in
> this case) that you can never be sure how long a memory allocation
> will take. Wouldn't GC take exponentially longer the more memory the
> computer has?
On the other hand, when you destroy an object in language with no GC,
it usually leads to a cascade of objects destructions, and is no less
deterministic.
> Also, how does GC handle circular references? If I have a doubly
> linked list, how does it determine that it's no longer in use if I
> just sever the connection the program has to it? Now that almost all
> memory allocated in, say, Delphi, is dynamic, how can it distinguish
> between active and non-active parts?
Here's a good reading about GC :
ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
It will answer most -- if not all -- of your questions.
--
Laurent Martelli
Ray Lischner
Karlsen) wrote:
>Isn't GC indeterministic? Meaning (in my understanding of the word in
>this case) that you can never be sure how long a memory allocation
>will take. Wouldn't GC take exponentially longer the more memory the
>computer has?
No and no. GC allocations are usually faster than non-GC allocations
because GC doesn't need to do all the bookkeeping that non-GC needs to
support subsequent freeing of the allocated memory.
>Also, how does GC handle circular references? If I have a doubly
>linked list, how does it determine that it's no longer in use if I
>just sever the connection the program has to it? Now that almost all
>memory allocated in, say, Delphi, is dynamic, how can it distinguish
>between active and non-active parts?
No problem. The typical GC algorithm starts from known "roots," which
are the active memory references and follows them to identify
still-in-use memory. Any cycle that is no longer in use will be
collected. For Delphi, the roots would be unit-level global variables,
dynamically allocated memory, registers, and local variables in the call
stack.
Michael Farmer
throw my 3 cents in.
1. Alter the class heirarchy and make most of those 'private' class members
'protected'. Everytime I turn around I'm wanting to alter the behaviour
of some existing component only to find out that the members are private.
Do I alter the Delphi source? I like to to avoid that alternative. So, I
usually end up copying the component, changing all the class names,
and creating my own component, swelling the exe. I can appreciate
why Borland wants to leave it private (so they can be free to change
it later). It's really a judgement call as to where to draw the line between
private and protected, but I think Borland has gone too far to the private
end of the spectrum. For example, why is data-awareness private?
Should be 'protected' IMHO.
2. I personally don't care much for the event-handling system that
Delphi uses. Event handler code must exist in the form that contains
the component, kind of like Java 1.0. I think what Java did in 1.1 offers
more flexibility and requires less coding by the developer. Particularly,
one delegates an object to be the reciever the event, and thus house
the event handling code. Without knowing more about Delphi's IDE
internals, my question would be is it possible to allow both, i.e. do it
like they do know, but have the option to map events to other objects
besides the form?
3. Let me create class objects on the runtime stack. That, in combination
with the existing exception handling, would be the best alternative
to garbage collection, which would be a big change I think.
IMHO, Delphi is still the best RAD, data-aware component driven
development environment out there, but these few things have
probably doubled the time it takes me to develop apps.
BTW: Thanks for the CrackerJax comment. Look for several big
new features to be there within the next few weeks.
--michael
michae...@mindspring.com
www.kineticsoftware.com
A Ranter wrote in message <36a70d25...@news.tcp.co.uk>...
>21. Reparentage option on selected components - so you can move
>selected components into a Groupbox / Panel easily etc
Michael Farmer
again where it will make more 'thread-sense')...
VBDis
Im Artikel <78o97n$sn$1...@camel15.mindspring.com>, "Michael Farmer"
<michae...@mindspring.com> schreibt:
>For example, why is data-awareness private?
>Should be 'protected' IMHO.
I agree, since it's up to the creator of a derived class, that it works as
expected, in contrast to the "dumb" user, that has no deeper insight into the
base class, and only should not be able to modify properties in a way, that is
not handled by the base class. As with D4 Standard, I'm in the position of such
a dumb user :-(
OTOH, scopes like "private" are ignored inside the same unit. According to my
argumentation above, that the creator of a subclass should have full access to
the code of the base class, you can create special subclasses in the same unit,
without any need to touch the base classes at all. Therefore the modified unit
will behave *exactly* as before, as long as none of your added classes is used.
Or, more dirty, you might change the scope of the fields from "private" to
"protected", what makes the fields reachable in code, but not in the
documentation or the object browser? (big Q ;-)
Similarly the scope handling could be extended to package level, so that units
in the same package have unrestricted access to all members of the classes in
other units, of the same package.
I only don't know yet, what overall consequences will arise from modified
standard units.
DoDi
VBDis
Im Artikel <78o97n$sn$1...@camel15.mindspring.com>, "Michael Farmer"
<michae...@mindspring.com> schreibt:
>Without knowing more about Delphi's IDE
The same to me, for now. I only want to add a remark, that applies to VB event
handling, possibly also to Java 1.???
In VB, an event is raised in the originating class, and passed to *all*
clients, that use (reference) that particular object. This mechanism differs
from the Delphi model, where the "server" will call the event handler of *one*
dedicated "client", the latest one who modified the OnXYZ property of that
object.
But also Java had to add new functionality, AFAIR with EventListener's, that
might be implemented by a chain of event sinks, instead of the single user
OnXYZ property.
Another implementation might use something like the Broadcast method, used to
notify *all* subordinary components of a container control. But in this case
the actual subordinate components can be enumerated, using the
ContainedControls, whereas the references to an object are only "counted" in
the object itself, but no backward references to these references exist, and no
places exist, where the handlers could be registered, for every *usage* of an
object.
>3. Let me create class objects on the runtime stack.
Do you mean something like in C++, where local objects are destroyed, as soon
as they get out of scope? I would appreciate a similar functionality, together
with nested local blocks. But I cannot anticipate the impact of such changes,
with regards to the compiler and runtime behaviour of the according code.
Performance will not be better, as when you keep track of the local objects
yourself, and destroy these after their use, regardless of their residence in
local (stack) or global memory.
DoDi
Michael Farmer
>Or, more dirty, you might change the scope of the fields from "private" to
>"protected", what makes the fields reachable in code, but not in the
>documentation or the object browser? (big Q ;-)
I think I tried this once. I was going to just go through the whole delphi
heirarchy and change everything from 'private' to 'protected' and see if
I could do it, if third-party components would blow up, etc.
It was some time ago, but it seems like I ran into some problems. I think
there are several units that are used, that are not included in the source
sent from Borland. So I gave up on the task. If you did this successfully,
(or know someone who did), please let me know. A third-party component
would have to be pretty sloppy to cause problems with doing all this, so
that
should not be a problem. The fact that Borland doesn't give me everything
I need to rebuild the heirarchy is a pain, but I suppose I could see their
reasoning, (although I don't like it).
--michael
VBDis wrote in message <19990128225037...@ngol06.aol.com>...
>
>Im Artikel <78o97n$sn$1...@camel15.mindspring.com>, "Michael Farmer"
><michae...@mindspring.com> schreibt:
>
Michael Farmer
I think they give us something more
flexible as follows: You know how you can have a data module
and use that unit in a form, then have dataaware components that
are driven by that table on the data module? Why not do the same
thing with events. Call it an Event Handler Module instead of a data
module. Let me use that module in a form, then direct my events
to that 'event handler' module instead of to the form. The same issues
regarding the instantiation of the module would exist as with the
data module case.
This would avoid any kind of EventListener, and would avoid the
VB approach as well. It would also not have to go down the MSVC's
route of the document-view thing; (which would be a big paradigm
change from the way Delphi is now).
Regarding objects on the run-time stack: -------------------------
>>3. Let me create class objects on the runtime stack.
>
>Do you mean something like in C++, where local objects are destroyed, as
soon
>as they get out of scope?
that is EXCACTLY what I mean. To get the same effect now, (creating the
objects
on the heap), one would technically have to do the following:
procedure foo: Integer;
var
x: TMyClass;
begin
x := TMyClass.Create;
try
... the code in the function...
finally
if( x <> nil) then x.Free;
end;
end;
Why should we have to have all this code? IF x could be instantiated on the
runtime stack,
then it would just GO AWAY when the procedure is done, giving us cleaner
looking code
like this (assuming the language extension RTS caused x be created on the
runtime stack):
procedure foo: Integer;
var
x: TMyClass RTS;
begin
...
end;
and the compiler would essentially do what was done with the try..finally
above. They could
add this and it would would not cause any of the existing Delphi code in the
world to break.
--michael
VBDis wrote in message <19990128225038...@ngol06.aol.com>...
>
>Im Artikel <78o97n$sn$1...@camel15.mindspring.com>, "Michael Farmer"
><michae...@mindspring.com> schreibt:
>
AlanGLLoyd
In article <19990128225038...@ngol06.aol.com>, vb...@aol.com
(VBDis) writes:
> This mechanism differs
> from the Delphi model, where the "server" will call the event handler of
>*one* dedicated "client", the latest one who modified the OnXYZ property
> of that object.
Surely the event handler pointer is a property, and hence each instance
can/will be appropriate to that instance's specification of the event handler
for itself (or its Self).
The event handlers must be a method of some object, or can MakeInstance be used
so that a procedure can emulate an object's method.
Alan Lloyd
alang...@aol.com
VBDis
Im Artikel <78t0is$tt3$1...@camel25.mindspring.com>, "Michael Farmer"
<michae...@mindspring.com> schreibt:
>and the compiler would essentially do what was done with the try..finally
>above.
With some exceptions. What if you want to pass the object elsewhere, either to
a procedure that you call in the subroutine, or return as the function result?
What's about the possible local objects, allocated inside that heap object?
Automatic deletion of local objects will always require a call to the
destructor of the object, and this may be difficult, for both normal and
abnormal termination (by some exception).
Perhaps one solution were a new "auto" keyword, that would result in the C++
behaviour, for local objects. All other objects, created by the current syntax,
*must* persist, or be destroyed explicitly.
BTW, all TInterfacedObject's are automatically destroyed if no more used. You
only must derive your classes from that base class.
DoDi
VBDis
Im Artikel <19990129144257...@ngol05.aol.com>, alang...@aol.com
(AlanGLLoyd) schreibt:
>Surely the event handler pointer is a property, and hence each instance
>can/will be appropriate to that instance's specification of the event handler
You could also think of a list of event handlers, with one entry for every
client, that want's to receive the same event.
But implementation will be very difficult and time consuming, since then not
only the event handlers must be registered, but also unregistered when the
client is destroyed! Otherwise the next event may call a handler, that runs in
the environment of the destroyed object (form...).
BTW, I think that I'm missing something. Usually a event handler is bound to
some object, i.e. it's a method of a class. How then does that handler get the
appropriate Self pointer? Is it furthermore (im)possible to create "static"
event handlers, that are not part of a specific object?
DoDi