Why no language improvements?
Mike Margerum
while my bread and butter is C++, I have done quite a bit of delphi
through the years as well. I would be doing a lot more delphi
programming if they had bothered to improve the language at all in the
last 10 years. It's remarkable. The language is almost identical to
what it was in Delphi 1. Every time I step away from TDataset, I face
that crushing realization. Not everything fits into the relational
mold. In fact, I would say most projects dont even need it. It's just
what people have become comfortable with. Delphi is such a productive
environment. Its a shame to see it wither on the vine.
Instead of chasing the now stalling .Net, why don't you make some basic
improvements to the Object Pascal language to support language
constructs that have been available to all of the other major languages
for 7+ years now? I have a new project that I would love to use delphi
for but the lack of real data structures and generics make Delphi's
prospects bleak. Screw .Net. If you would have kept improving the
Win32 and Kylix releases, you could have eclipsed (excuse pun) .net by
now and you would have probrably picked up a lot of VB6 folks looking
for a good win32 alternative. The Win32 and Win64 api's will continue
to be supported for the next 10 years. They aren't going anywhere.
I get the same feeling every time I fire Visual Studio.net 2003. Wow
this is really neat but what is it buying me that Delphi and C++ builder
didnt:
Unpredicatble memory usage/collection
A huge (seperate) VM for every app that needs to run.
A massive runtime that needs to be installed and even more massive
downloads everytime the "patch" the runtime
Even worse DLL hell (spare me the versioing schpeel built into .net)
IIS being jammed into the mix where it doesn't belong to do simple
things like web services, and remoting of datasets
Winforms? (dont need to go there) arent they already deprecating this?
Now you are completely at the mercy of m$. You have to *wait* until
"They" provide you with the designers for the Compact framework? You
could have ported the Win32 compiler to produce ARM code for all the
time you've wasted with m$ and their "open" IDE tools.
You could have put Templates, An STL equivalent, stack based objects,
copyable objects, into your win32 product instead of having to "wait"
for m$ to finish there 2.0 spec.
Thankfully, you are going to continue to release BCB or I would be
leaving the Borland camp altogether.
Max
> for but the lack of real data structures and generics make Delphi's
Please vote below to change it:
Want Parameterized Types (aka Generics) also for Win32/64 (not only .Net
2.0) ? Vote here--
http://qc.borland.com/wc/qcmain.aspx?d=11168
"Mike Margerum" <mi...@garbage.com> schrieb im Newsbeitrag
news:422cb278$1...@newsgroups.borland.com...
Mike Margerum
>
> Want Parameterized Types (aka Generics) also for Win32/64 (not only .Net
> 2.0) ? Vote here--
> http://qc.borland.com/wc/qcmain.aspx?d=11168
>
>
I voted for it. Thanks
I don't want to give people the wrong idea. I love Borland's tools and
have been using them for years. I'm just frustrated by their lack of
focus on fundamental language improvements in Object pascal in favor of
.net and the architect stuff. I'd be willing to bet not even 1% of the
delphi community is using either of these things right now.
Thomas Miller
I am sure it is much more the 1%, but not even close to a majority. My
beef isn't with language enhancements as much as a stagnant VCL. Even
little things like DisabledColor would be welcome, a numeric edit,
improvements to TGrid and TDBGrid, etc.
I love the fact that my code breaks very little from update to update,
but I think Borland errs to much on the side of caution.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus
Mike Margerum
the most basic things. I really like that they bundled 3rd party
components like Rave into delphi 7 and they should continue doing that.
That was one of the reasons I bought 7.
> I love the fact that my code breaks very little from update to update,
> but I think Borland errs to much on the side of caution.
Yeh this is a big plus for delphi. I can tell you pulling 3rd party
projects into C++ can be a nightmare because of the differences in
compilers. The strength of Delphi is that it comes from one vendor and
code from 1995 will compile for the most part. But as you said, thats
hardly a reason to not improve the language and VCL.
Charles McAllister
> improvements to the Object Pascal language to support language
> constructs that have been available to all of the other major languages
> for 7+ years now? I have a new project that I would love to use delphi
> for but the lack of real data structures and generics make Delphi's
> prospects bleak. Screw .Net. If you would have kept improving the
> Win32 and Kylix releases, you could have eclipsed (excuse pun) .net by
> now and you would have probrably picked up a lot of VB6 folks looking
> for a good win32 alternative. The Win32 and Win64 api's will continue
> to be supported for the next 10 years. They aren't going anywhere.
So what do you want besides generics?
![Nick Hodges [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWsTjWTtYgQa_lIkPPY_9f1apuJLHGnOXqRfdvL-25iS-D7ruXW=s40-c)
Nick Hodges [TeamB]
> You havent agreed with me on anything.
I haven't? I agree that generics would be a terrific addition to the
Delphi language.
I /don't/ agree that much of what you are asking for doesn't exist. It
does. You asked for a number of things that you say don't exist, but
that people have pointed out to you. Are you wanting to know more
about what Delphi and the Delphi libraries out there have to offer, or
are you determined to think that Delphi doesn't have what you want,
despite the facts?
Again, if you need to use C++, then I suggest you use it. But for those
of us that don't need to use C++ and get on wonderfully without all the
things you are talking about, your comments about Delphi being "caught
in 1995" are just so much ranting. I'm using /tons/ of new Delphi
language features every day, including operator overloading, inlining,
for...in, nested classes, records with methods, multi-cast events,
class methods, etc., etc.
So yeah, if you are talking about Delphi not having new language
features, I guess I /don't/ know what you are talking about.
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Andreas Hausladen
> because delphi doesnt support stack based and copyable objects :D
Delphi supports them but only in the language because they were superseded
by the "class" keyword.
--
Regards,
Andreas Hausladen
Mike Margerum
> in Delphi? For the record, I do.
>
k lets look at your previous posts:
"Of course, these issues aren't /language/ issues but RTL issues.
Okay, that's fine. If you need to use C++, then use it."
"Again, I'll refer you to the numerous libraries that are available for
doing almost everything that you want. If you choose to ignore the
fact that the code you are complaining about not existing does in fact
exist, I am at a loss what else to tell you."
These would lead me to believe you dont want generics or simply dont
fully comprehend them and why borland doesnt currently support them out
of the box.
Mike Margerum
it's a clever hack but it isn't a generic solution. you still have to
subclass and even worse you have to subclass twice. once for the
collection and once for the collection item.
and you still have to use it with TObject pointers (ahem references)
Nick Hodges [TeamB]
> These would lead me to believe you dont want generics or simply dont
> fully comprehend them and why borland doesnt currently support them
> out of the box.
Well, I don't possibly see how. I do fully comprehend them, and I do
want Borland to implement them.
Most of what you were asking for /were/ RTL issues.
Note "almost everything you want" in the quotes of mine.
You leapt to many conclusions about what I said. Don't feel bad,
you've joined an illustrious group. ;-)
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> > which is in Delphi 2005, I am glad they chose to pass.
> >
>
> Generics are just syntactic sugar right?
No, they are not. They can hardly be emulated.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Quote me as saying I was mis-quoted."
-- Groucho Marx
JED
> > Why do I have to mess around painting the sort arrow on the column
> > header?
>
> Because you don't want to use any of the third party controls that do
> this? Many of which are free?
I shouldn't have to. Cost is not the issue.
--
Screenshots of Version 2 of DCM now available from
http://www.alphalink.com.au/~jed/dcm.htm
Rudy Velthuis [TeamB]
> It's not what I want. I want delphi to support generic programming.
So do I. Since ages.
Then I guess it will be similar to the generics in C#, and not like
templates. I'd guess the Delphi for .NET 2.0 will have to have it. And
it might just as well be implemented in Win32 then, although that might
require some extra changes (perhaps an extension of class helpers?) to
be able to use value types as well as reference types in the same
container or algorithm.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"I would have made a good Pope." -- Richard Nixon.
John Jacobson
news:422cdcca$1...@newsgroups.borland.com...
> Last time. I never said anything about whether it was possible to do all
> these things writing enough of your own code. Last time, its about having
> thre compiler do some heavy lifting for you. You can't even grasp what im
> talking about until you've actually used the concepts.
Yeah, talking down to others really boosts your credibility.
Rudy Velthuis [TeamB]
> You dismiss generic as half-baked, but
> they actually solve a lot of problems with the template syntax
> (partly by removing the metaprogramming abuses!)
I fully agree. I would not want templates in Delphi, but would love to
have generics.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Computers can figure out all kinds of problems, except the things in
the world that just don't add up." -- James Magary.
John Jacobson
> parsers
>
> My final point on this portion of the thread is that without templates at
> the COMPILER level, none of these things are possible.
What? How can anyone say that with a straight face? Of course you can write
a parser in Delphi. There are several parsers written in Delphi.
Dude, do some research before striding forth unprotected like that. You are
making some of us laugh.
Rudy Velthuis [TeamB]
> > Well everyone at Borland should give themselves a well deserved pat
> > on the back and a year off for thinking of every language feature
> > that anyone would ever be needing in 1995. Oh execpt for inlining
> > and "for each" which complete the masterpeice.
>
> If you think inlining and "for each" are the only language
> innovations done in Delphi since 1995 then you have no idea
> whatsoever what you are talking about.
Really.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Ever stop to think, and forget to start again?" -- bumper sticker
Jim Cooper
> Not just generics....
My understanding was that they want to make the syntax the same for .NET
and Win32, which means waiting for generics in .NET 2 to be finalised.
> OPTIMIZED containers like hash maps, vectors, lists, queues, multimaps,
> graphs
Not language features.
> iterators, for_each (etc)
Got this already
> multiple inheritance
No way!! Work of the devil. There's a good reason it doesn't make it
into modern languages (C++ not being a modern language, BTW).
Not sure why you think .NET is stalled either
Cheers,
Jim Cooper
__________________________________________
Jim Cooper jco...@tabdee.ltd.uk
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
Rudy Velthuis [TeamB]
> > Sounds like you just want C++. The next version of Delphi will have
> > C++ integrated into the IDE as well, so just wait till then. You
> > shouldn't think all these language features, and many more, hadn't
> > been thought about by the Delphi team. They just decided not to
> > implement them. Other than for_each which is in Delphi 2005, I am
> > glad they chose to pass.
> >
>
> I knew that was coming. See post above.
>
> It's not what I want. I want delphi to support generic programming.
No problem.
But template metaprogramming is a risky art. Unlike the rest of C++,
which is much more readable than Delphites might say, template
metaprogramming is write-only. The stuff is extremely hard to debug,
since only the end code reaches the debugger, and can take ages to get
right.
So it lets the compiler do some work for you. But the time it takes to
make it do that is usually much worse than the benefit from it.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Outside of the killings, Washington has one of the lowest crime rates
in the country." -- Mayor Marion Barry, Washington, DC
John Jacobson
>> And I'll say once again, okay, cool, use C++.
>
> Well everyone at Borland should give themselves a well deserved pat on the
> back and a year off for thinking of every language feature that anyone
> would ever be needing in 1995. Oh execpt for inlining and "for each"
> which complete the masterpeice.
If you think inlining and "for each" are the only language innovations done
in Delphi since 1995 then you have no idea whatsoever what you are talking
about. You might as well drop this argument. You just lost any credibility
you might have had with anybody that knows the true history of Delphi.
Alisdair Meredith
> You dont know what i'm talking about here. metaprogramming isnt
> reflection.
No, and neither are templates. On the other hand, you can write
metaprograms using either.
In C++ template world you write metaprograms to compute types or select
behaviour at compile time. In Java/.NET/Delphi/Python runtime
metaprogramming, you query types to take actions, and pass types around
as runtime variables.
For example, in C++ it I am not sure of a way to enumerate a classes
member functions at run time, and call the most interesting sounding
one. In Delphi/Win32 I can do this for the published interface, Java
and .NET go further. I am sure you can see significant metaprogramming
possibilities here?
> what you call abuse, i call convinience. god i dont want to get into
> this operator overloading argument again.
Sorry, I missed the last few rounds of this and am jumping in afresh.
Operator overloading is clearly useful in its place - I would hate to
implement complex numbers or rational fractions without it.
I cannot describe Spirit-like parsers as anything but abuse. This is
*not* what the feature was put into the language for, and it is very
disconcerting for someone not aware they are reading a different
language (Spirit) than the rest of the source (C++)
I personally think it is quite neat and expressive, but by the same
token do you want to overload user defined operators? I gather it
actually works very well in Haskell.
> Some of it yet. like bind. but not all of it. I'm not defending
> C++ here? If C++ was perfect would i be using delphi right now?
But you are asking for the specific single feature that makes C++ such
a beast to implement/get right? I love templates to bits, but
recognise that generally template heavy code is write-only and too
clever for its own good. Many competent C++ developers do not know how
to read template code. You dismiss generic as half-baked, but they
actually solve a lot of problems with the template syntax (partly by
removing the metaprogramming abuses!)
AlisdairM<TeamB>
Mike Margerum
John Jacobson
> Because i'm building an OBJECT ORIENTED system with tons of in memory
> containers.
Cool, we have something in common. We are doing the same thing, except that
I'm using Delphi (and mine are threadsafe).
> My choices were the STL or TList/TCollection. guess which one won?
Those weren't your only choices.
John Jacobson
> You can go to 3rd parties but they will never make these containers type
> safe and you will have to do lots of casting. You will need to subclass
> them if you dont want to do casting which is the whole point of generic
> containers in the first place. You will also not be able to use generic
> algorithms (ie sort, fine, for_each, etc) on these containers.
I use a CodeExplorer template for my typesafe containers in Delphi. Not as
good as genuine generics maybe, but just as fast and castless.
Mike Margerum
> "Mike Margerum" <mi...@garbage.com> wrote in message
> news:422cd352$1...@newsgroups.borland.com...
>
>>parsers
>>
>>My final point on this portion of the thread is that without templates at
>>the COMPILER level, none of these things are possible.
>
>
> What? How can anyone say that with a straight face? Of course you can write
> a parser in Delphi. There are several parsers written in Delphi.
>
Please see about 10 posts in this thread where I said you can write
anything without generics. generics *help* write less code and type
safe code. Maybe if i say it about 10 more times you'll read it.
> Dude, do some research before striding forth unprotected like that. You are
> making some of us laugh.
>
>
Ok Dude!
Rudy Velthuis [TeamB]
> Charles McAllister wrote:
>
> > why not recommended? going to be deprecated?
>
> The compiler does not give you are warning or hint if you use
> "object". I used them for importing gcc compiled C++ classes as they
> map to gcc C++ classes almost identically (except the first VMT
> entry).
>
> Delphi.NET does no more support "object". But you can use "record"
> exactly the same with.
Records in D/.NET don't have virtual or dynamic methods, and they don't
have reference types (virtuals are only useful for referenced objects).
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Science is like sex: sometimes something useful comes out, but that is
not the reason we are doing it" -- Richard Feynman
John Jacobson
news:422c...@newsgroups.borland.com...
>> multiple inheritance
>>
> Some will argue its a dangerous feature. BUT could really use multiple
> interface inheritance.
If you mean the ability for a class to inherit from (implement) more than
one interface (as in ISomething), Delphi has had that ability since D3.
Mike Margerum
about 3 times by then.
John Jacobson
> What if a TCollection descendant isnt what you need to iterate over? What
> if you need to operate on a map, vector, or string?
A map is jst a special type of list. A vector is just an array, as is a
string. You can easily iterate over all of these, myriad Delphi programmers
do it every day.
Mike Margerum
>
>
> No, they are not. They can hardly be emulated.
sure they can. Look at what sun did in java 1.5 :)
Jim Cooper
> Oh execpt for inlining and "for
> each" which complete the masterpeice.
And interfaces
Mike Margerum
> one interface (as in ISomething), Delphi has had that ability since D3.
>
>
Mike Margerum
> string. You can easily iterate over all of these, myriad Delphi programmers
> do it every day.
>
>
a vector is an array but a list is not. its a "list"
They all have very different performance characteristics based on where
you need performance ie inserting, searching, random indexing.
I can easily iterate over a void pointer doesnt mean typesafe iterators
arent a good thing.
Alisdair Meredith
> I will be using C++ long after delphi goes tits up because the
> language continues to evolve and find an ever widening audience.
Out of curiosity, which C++ language feature added since 1995 has been
most useful to you?
OK, I'll play fair, let's say since 1997 when the Holy ISO Standard was
finished?
Which of the new langauge features for the proposed C++0x has you most
excited, and would you like to see in Delphi to steal the thunder! <g>
AlisdairM(TeamB)
Mike Margerum
> Mike Margerum wrote:
>
>
>>I will be using C++ long after delphi goes tits up because the
>>language continues to evolve and find an ever widening audience.
>
>
> Out of curiosity, which C++ language feature added since 1995 has been
> most useful to you?
>
> OK, I'll play fair, let's say since 1997 when the Holy ISO Standard was
> finished?
>
Templates :D
I answering your question based on when it was really available for
general consumption.
Besdies when did i ever say C++ had every language feature i want? C++
is missing lots of things I would like to have.
Why do you people keep going back to the C++ well to deflect the
argument that delphi is missing the features i mentioned? What has C++
got to do with it?
> Which of the new langauge features for the proposed C++0x has you most
> excited, and would you like to see in Delphi to steal the thunder! <g>
>
havent read it.
> AlisdairM(TeamB)
Alisdair Meredith
> Cool, we have something in common. We are doing the same thing,
> except that I'm using Delphi (and mine are threadsafe).
I know I'm going to regret asking this, but what does 'threadsafe' mean?
I ask not because I have no idea, but because the term means so many
different things to different people, I would like to hear your
definition before commenting.
AlisdairM(TeamB)
Charles McAllister
> Again, if you need to use C++, then I suggest you use it. But for those
> of us that don't need to use C++ and get on wonderfully without all the
> things you are talking about, your comments about Delphi being "caught
> in 1995" are just so much ranting. I'm using /tons/ of new Delphi
> language features every day, including operator overloading, inlining,
> for...in, nested classes, records with methods, multi-cast events,
> class methods, etc., etc.
>
It'd be cool to see a timeline of what language features have been added since TP.
--
---------------------------------
got tags?
http://del.icio.us/charlesmcallister
Alisdair Meredith
> sure they can. Look at what sun did in java 1.5 :)
Urgh! Type erasue is a horrible thing :¬(
At least ECMA CTS generics will not suffer from that <g>
AlisdairM(TeamB)
Mike Margerum
Maybe im too much of an old C++ salt because I see glaring holes in
Delphi. Oh well.
Oliver Townshend
>> this? Many of which are free?
>
> I shouldn't have to. Cost is not the issue.
You don't have to. Especially if cost is not the issue. Why complain about
something that you can fix?
Oliver Townshend
Alisdair Meredith
> An interface is just an abstract class. Not the same thing as MI
An interface is more than just an abstract class in Delphi. For a
start, it can have RAII semantics ;¬)
Besides which, viewing interfaces merely as abstract classes pretty
much misses the point. They are a simplification of an abstract class
- devoid of innate functionality but strong on meaning. It is a one of
the classic examples of 'less is more' and one of the few things the
Java langauge got right ;¬)
AlisdairM(TeamB)
Alisdair Meredith
> Templates.
Were around before 1995 - I have the Borland C++ compiler to prove it!
> [since 1997]
> Templates :D
> I answering your question based on when it was really available for
> general consumption.
But template were a fully specified part of the language from 1997 -
nothing has been added since then apart from a few errata to work out
the bugs!
> Besdies when did i ever say C++ had every language feature i want?
> C++ is missing lots of things I would like to have.
> Why do you people keep going back to the C++ well to deflect the
> argument that delphi is missing the features i mentioned? What has
> C++ got to do with it?
Because of this quote:
"I will be using C++ long after delphi goes tits up because the
language continues to evolve..."
THe implication is that C++ is evolving as a language faster than
Delphi, and I feel the opposite is true (on the basis of evidence to
date) I have seen more evolution of Delphi over the last decade than
C++.
OTOH, I have seen C++ vendors struggle to implement the standard, and a
greater appreciation and discovery of what the standard delivers. We
certainly do not write C++ code today the same way we did 10 years ago!
But it is our understanding that has changed, not the language.
>>> [Which new C++ feature would you like in Delphi?]
> havent read it.
So you are not aware of any new features coming into C++ but still feel
it is evolving faster than Delphi?
AlisdairM(TeamB)
Captain Jake
in message <422cf65d$1...@newsgroups.borland.com>
> I know I'm going to regret asking this, but what does 'threadsafe' mean?
>
> I ask not because I have no idea, but because the term means so many
> different things to different people, I would like to hear your
> definition before commenting.
It means the container uses a critical section to protect reads and writes
to/from the container and offers locking and unlocking to prevent concurrency
problems. For example, one of the first things I wrote for my newsreader was
a threadsafe string list. I use it to pass messages and data back and forth
between different threads (I refuse to use TThread.Sychronize).
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.442
Will DeWitt Jr.
> If you think inlining and "for each" are the only language
> innovations done in Delphi since 1995 then you have no idea
> whatsoever what you are talking about. You might as well drop this
> argument. You just lost any credibility you might have had with
> anybody that knows the true history of Delphi.
Funny, I know the "true history" and I feel the same way he does-- not
enough has been done in the decade since Delphi was first released. And
now that things are getting done, it seems preference is being given to
.NET over Win32 (when, in fact, there should be as much in common as
possible between them).
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
Lauchlan M
> doing almost everything that you want.
I don't want to interrupt a good heated argument, but would like to suggest
that if you're going to refer, then refer! Which libraries exactly, offering
which features?
It might be handy for people just watching the thread as well as for Mike.
Lauchlan M
Captain Jake
> > If you mean the ability for a class to inherit from (implement) more than
> > one interface (as in ISomething), Delphi has had that ability since D3.
> >
> >
> An interface is just an abstract class. Not the same thing as MI
Well, the question was about multiple inheritance in interfaces. Hence my
question as to what was meant.
Lauchlan M
The fact that there are third party components that make up for the VCL's
shortcomings is no reason for Borland to be lazy and never improve the VCL.
They should be improving these components but basically don't - if anything
they add some new components but rarely if ever improve the old ones.
Similarly, they should have improved the D4-D7 IDE instead of being lazy
about it because there were third party add-ins such as code rush et al.
And the point is not that I or JED are too lazy to find them, or too stingy
to pay for them (neither point being true). The point is that a lot of this
stuff should be provided out of the Delphi box. _Should_ I have to look
around for and evaluate Castalia, Code Rush, etc if I want to have line
numbers shown in my IDE in D7, a 10 year old product? I don't think so.
The only time Borland has improved these things adding things like line
numbers, cold folding etc is when jumping to a whole new IDE - Galileo -
because then they suddenly considered it was worth rethinking these things
for the .net environment, presumably because they got the infrastructure for
most of these changes with the .net framework and didn't have to think too
hard about what was required (copy VS.NET) or how to do it (use the .net
framework). Up till then, there was incredible IDE and VCL inertia.
It strikes me as a slapdash and half-hearted commitment to Delphi 4-7 from
Borland.
Lauchlan M
Oliver Townshend
> Borland.
Well my attitude has been that I find the third party components that do
what I want, and only upgrade Delphi if those components require it. I
would still be on Delphi 5 if it wasn't for RemObjects.
But the good thing about Delphi is it allows, creates and sustains this
market. To me Delphi is a toolbox, and I put in it the tools I want to use.
Better tools from Borland would give them greater sales in Delphi. So I
suppose I come at the same problem, just from a different direction. I
don't complain about features missing from Delphi, I just don't purchase all
releases.
Oliver Townshend
Captain Jake
> I am getting a little facetious but they havent done nearly enough.
> Maybe im too much of an old C++ salt because I see glaring holes in
> Delphi. Oh well.
I was doing C++ when Delphi came out, and one of the first things I noticed
was that there was nothing like the STL in Delphi. I thought this was a real
handicap at first, but over time I realized I could use arrays, TList and
TStringlist for most of the things I was going to use the STL for anyway. And
linked lists are trivial to write. Over the years that has been true for
nearly every program I've had to write. But when I started writing my
multi-threaded newsreader I started writing some of my own data structures,
because I wanted/needed thread safety in the containers themselves (and I
needed optimal speed). Basically I've been cloning/adapting the containers in
Julian Bucknall's book "The Tomes of Delphi: Algorithms and Data Structures"
and Rod Stephen's book "Delphi 3.0 Algorithms". I should probably point out
that I would have to do something similar in C++ as well, since the STL does
not by default give you threadsafe containers.
JED
> For example, one of the first things I
> wrote for my newsreader was a threadsafe string list.
Why not TThreadList?
--
Screenshots of Version 2 of DCM now available from
http://www.alphalink.com.au/~jed/dcm.htm
Want to be notified of DCM 2.0 release? Send me an email...
Captain Jake
> >
> >>parsers
> >>
> >>My final point on this portion of the thread is that without templates at
> >>the COMPILER level, none of these things are possible.
> >
> >
> > What? How can anyone say that with a straight face? Of course you can write
> > a parser in Delphi. There are several parsers written in Delphi.
> >
>
> Please see about 10 posts in this thread where I said you can write
> anything without generics. generics *help* write less code and type
> safe code. Maybe if i say it about 10 more times you'll read it.
So then the stuff I quoted above is to be ignored as admittedly erroneous?
Lauchlan M
> market.
I totally agree. This is a great thing about Delphi.
> To me Delphi is a toolbox, and I put in it the tools I want to use.
> Better tools from Borland would give them greater sales in Delphi. So I
> suppose I come at the same problem, just from a different direction. I
> don't complain about features missing from Delphi, I just don't purchase
all
> releases.
Well, to give an example, prior to EWF and IW, Borland's web offerings were
in my opinion lousy. I found WebBroker etc clunky and unappealing. I think
there was a period of around at least 4 or 5 years where this was a big gap
in Borland's offering, plugged eventually not by internal development but by
licencing IW and ASP.NET.
So, the situation is sure, the third party tool market moved in to fill the
gap. Great and well done and I hope they've been and continue to be well
rewarded. But does this change the fact that Borland should have done
something about this themselves? In my opinion no. In my opinion, I think if
Borland were willing to throw around money acquiring Together and Bold and
other companies they could have and should have forked out to acquire a web
development component vendor or to do the development themselves internally.
It was a serious gap in a core area of their product offering. And
incidently they should do similarly now for automated testing, since they
are focusing on the product life cycle angle.
Similarly with other areas. Castalia and Code Rush fill great gaps in
Borlands product offerings. But does that justify Borland never doing
anything themselves to improve their product in these areas? In my opinion,
no.
But, like you say, the third party market makes it possible to proceed even
when Borland do drag their toes and fail to implement what can or should be
done. Thanks third party vendors!
Lauchlan M
Oliver Townshend
> complaints.
They are certainly milder than my wife's complaints about my cooking :)
Oliver Townshend
JED
> I
> don't complain about features missing from Delphi, I just don't
> purchase all releases.
You don't know what complaining is if you think my posts were
complaints.
--
Alisdair Meredith
> It means the container uses a critical section to protect reads and
> writes to/from the container and offers locking and unlocking to
> prevent concurrency problems. For example, one of the first things I
> wrote for my newsreader was a threadsafe string list. I use it to
> pass messages and data back and forth between different threads (I
> refuse to use TThread.Sychronize).
So every method that touches the member data locks/unlocks the same
critical section?
All properties explicitly use getter/setter in order to go through the
critical section?
The container locking/unlocking uses the same critical section?
And that critical section support recursive locks?
I guess that all public methods could delegate to private
implementations, where all thread synch is performed in the public API.
That would allow the private API to be used efficiently without
additional locking overheads.
Not sure how to protect base class members/methods though, unless that
is a similarly protected class.
I think this is what I head referred to as 'hot' thread safety. I have
learned to run shy of these systems myself - the fact you have a
containler-level lock/unlock in addition to the member level sych shows
you are aware there may be problems.
I have found 'cold' systems, where the container exposes the locking
primitives for the clients to use, to generally work better (for
appropriate definition of better) but they also require more attention
up front to use them correctly.
AlisdairM(TeamB)
Lauchlan M
> fully comprehend them and why borland doesnt currently support them out
> of the box.
I don't "fully comprehend" them. I'm not a C++ programmer. I would be
interested though if you could explain in more detail what you consider
Delphi (I take it you don't mean Borland's C++ Builder product) to be
lacking.
ie, what is it you can do in C++ you can't do in Delphi, what are the
language features you would like, and why would they make sucha difference
to you?
Also, could you explain why object persistence frameworks don't work for
you, or systems like Borland's ECO modelling? It seems to me there are more
data persistence options in Delphi than TDataSet, although I tend to use the
TDataset. But these obect-oriented ones presumably would be closer to
meeting your needs.
Thanks,
Lauchlan M
Mike Margerum
> nothing has been added since then apart from a few errata to work out
> the bugs!
>
compiler then its not doing me any good.
> THe implication is that C++ is evolving as a language faster than
> Delphi, and I feel the opposite is true (on the basis of evidence to
> date) I have seen more evolution of Delphi over the last decade than
> C++.
>
That's just a bunch of baloney. C++ doesn't move fast either but it has
improved more than delphi has and it has 30 years of baggage to support.
C++ hasnt needed to change that much because it already had a lot of
the constructs I have spoken of here. It could certainly use many more
but C++ has a pretty wide range of areas to support and adding anything
can cause problems. What they need to do is to depercate some things.
> OTOH, I have seen C++ vendors struggle to implement the standard, and a
> greater appreciation and discovery of what the standard delivers. We
> certainly do not write C++ code today the same way we did 10 years ago!
> But it is our understanding that has changed, not the language.
>
>
I write C++ code the same way i did 10 years ago on a palm :)-
templates weren't available 10 years ago.
> So you are not aware of any new features coming into C++ but still feel
> it is evolving faster than Delphi?
>
Yes because delphi isnt evolving at all unless you plan on using .net
Aside from a few very minor changes what great leap has delphi made
language wise?
> AlisdairM(TeamB)
Nick Hodges [TeamB]
> I don't want to interrupt a good heated argument, but would like
to
> suggest that if you're going to refer, then refer! Which
> libraries exactly, offering which features?
The libraries that I would point you to include:
http://sourceforge.net/projects/jcl/
http://sourceforge.net/projects/tpsystools/
http://www.boyet.com/FixedArticles/EZDSL.html
and that's just a start.
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Charles McAllister
>>> OPTIMIZED containers like hash maps, vectors, lists, queues,
>>> multimaps, graphs
>>>
>> I go to 3rd parties for these.
>>
>
> You can go to 3rd parties but they will never make these containers type
> safe and you will have to do lots of casting. You will need to subclass
> them if you dont want to do casting which is the whole point of generic
> containers in the first place. You will also not be able to use generic
> algorithms (ie sort, fine, for_each, etc) on these containers.
>
I don't do casting or subclassing -- at least not the way you're thinking (i believe).
What I do is /encapsulate/. Which, even if Delphi offered templates, I'd still encapsulate as my
first instinct.
Nick Hodges [TeamB]
> So you are not aware of any new features coming into C++ but still
> feel it is evolving faster than Delphi?
LOL.
Mike Margerum
>
> I don't "fully comprehend" them. I'm not a C++ programmer. I would be
> interested though if you could explain in more detail what you consider
> Delphi (I take it you don't mean Borland's C++ Builder product) to be
> lacking.
>
them adeqautely. The best thing to do would be to download one of the
VC++ express betas and a good C++ book. Then you would see what i'm
talking about.
> Also, could you explain why object persistence frameworks don't work for
> you, or systems like Borland's ECO modelling? It seems to me there are more
> data persistence options in Delphi than TDataSet, although I tend to use the
> TDataset. But these obect-oriented ones presumably would be closer to
> meeting your needs.
>
ECO/Bold does sound very promising but it would have to be really good
for 3k. I also question its usefulness for a lot of the things I build
(middleware and such).
> Thanks,
>
> Lauchlan M
>
>
Nick Hodges [TeamB]
> >
> It'd be cool to see a timeline of what language features have been
> added since TP.
It would be a long timeline.
Mike Margerum
> Mike Margerum wrote:
>
>
>>An interface is just an abstract class. Not the same thing as MI
>
>
> An interface is more than just an abstract class in Delphi. For a
> start, it can have RAII semantics ;¬)
>
interfaces=MI?
> Besides which, viewing interfaces merely as abstract classes pretty
> much misses the point. They are a simplification of an abstract class
> - devoid of innate functionality but strong on meaning. It is a one of
> the classic examples of 'less is more' and one of the few things the
> Java langauge got right ;¬)
>
I'm not down on interfaces. im just saying its not the same thing as
MI. They can be very useful. especially for things like remoting but
sometimes you really need MI.
> AlisdairM(TeamB)
Nick Hodges [TeamB]
> An interface is just an abstract class.
No, it's not. It's much less than that, and thus much more powerful.
Lauchlan M
> to
> > suggest that if you're going to refer, then refer! Which
> > libraries exactly, offering which features?
>
> The libraries that I would point you to include:
>
> http://sourceforge.net/projects/jcl/
> http://sourceforge.net/projects/tpsystools/
> http://www.boyet.com/FixedArticles/EZDSL.html
Alright, but for which features and functionality?
The JCL for example is quite large, what features or functionality in
particular would you be pointing me towards in it? Similarly for the other
two.
Thanks
Lauchlan M
Erwien Saputra
>
> I broke down and actually create 2 new button components the other
> day. TOKBtn and TCancelBtn. Just so I don't have to mess with the
> ModalResult and Default/Cancel properties of the button. I also
> anchored them bottom/right as well.
I assume that you are using D2005? I am having trouble with buttons
with Anchor property set to akBottom on a form that has TMainMenu on it.
Every time I load the form, or view the form to text and back to form,
the button position is moved up.
Check out QC #10024. There is a workaround.
If you don't have TMainMenu on the form, then do not set Scaled
property to false. Same thing happen.
Wien.
--
http://blogs.slcdug.org/esaputra
Delphi Setting Manager - http://www.codeline.net
Lauchlan M
> > interested though if you could explain in more detail what you consider
> > Delphi (I take it you don't mean Borland's C++ Builder product) to be
> > lacking.
> >
> Templates are such a complicated subject that I couldn't hope to explain
> them adeqautely. The best thing to do would be to download one of the
> VC++ express betas and a good C++ book. Then you would see what i'm
> talking about.
Well, that does nothing to help me gain a picture of what you're looking
for.
Being under time pressure, I'm not going to be able to learn C++ at any time
soon to see your point.
> > Also, could you explain why object persistence frameworks don't work for
> > you, or systems like Borland's ECO modelling? It seems to me there are
more
> > data persistence options in Delphi than TDataSet, although I tend to use
the
> > TDataset. But these obect-oriented ones presumably would be closer to
> > meeting your needs.
> >
> ECO/Bold does sound very promising but it would have to be really good
> for 3k. I also question its usefulness for a lot of the things I build
> (middleware and such).
Have you looked at remoting frameworks such as RemObjects
(www.remobjects.com). While their n-tier solution, Data Abstract, is dataset
based, it is built on their webservice/remoting framework, RemObjects SDK,
which you could extend in a custom fashion to transport your data as
objects. It will shortly be available for .net also.
I believe this is a problem situation many Delphi developers have been faced
with: they develop in an OO fashion, they then need an object persistence
framework, and they then need to extend that to an n-tier context.
I can't point you towards the best solutions for OO persistence / n-tier
development in Delphi, but that should not put you from noting that they
would be out there if you look for them.
Lauchlan Mackinnon [Team RO]
Captain Jake
<422d...@newsgroups.borland.com>
> John Jacobson wrote:
>
> > If you think inlining and "for each" are the only language
> > innovations done in Delphi since 1995 then you have no idea
> > whatsoever what you are talking about. You might as well drop this
> > argument. You just lost any credibility you might have had with
> > anybody that knows the true history of Delphi.
>
> Funny, I know the "true history" and I feel the same way he does-- not
> enough has been done in the decade since Delphi was first released.
I also feel that more could have been done than was, but that is not the same
as thinking that inlining and "foreach" are the only language innovations
since 1995. Sympathy is no reason to excuse inaccuracy.
Captain Jake
> > Out of curiosity, which C++ language feature added since 1995 has been
> > most useful to you?
> >
> Templates.
Not quite. Templates were in Borland C++ 3.0 (and Turbo C++) a couple of
years before 1995. I remember that fact VERY distinctly, because they were in
Turbo C++ 3.0, which is what I used to start teaching myself C++ the year
before I landed by first programming position in 1993.
Captain Jake
in message <422d...@newsgroups.borland.com>
> So every method that touches the member data locks/unlocks the same
> critical section?
Yes, though the syntax could handle a TMultiReadExclusiveWriteSynchronizer if
wanted. I don't know if that class works now or if it is still broken, so I
haven't switched over to it yet. All I'd have to do is create one instead of
a TjmjCriticalSection, which is just a wrapper around the TCriticalSection
right now.
>
> All properties explicitly use getter/setter in order to go through the
> critical section?
Yep.
>
> The container locking/unlocking uses the same critical section?
Yep.
>
> And that critical section support recursive locks?
Yep, though I never use it that way.
>
> I guess that all public methods could delegate to private
> implementations, where all thread synch is performed in the public API.
> That would allow the private API to be used efficiently without
> additional locking overheads.
Yep, but I never needed to do that yet. This class is used mostly for status
messages that get sent from one thread to the main thread, and a descendent
is used to send the list of newsgroup messages from a worker thread to the
main GUI thread for display.
Captain Jake
<xn0dzicf...@newsgroups.borland.com>
> Captain Jake wrote:
>
>
> > For example, one of the first things I
> > wrote for my newsreader was a threadsafe string list.
>
> Why not TThreadList?
I can't use it like a map or dictionary, IIRC. Also, it is too coarsely
grained for my preferences. I don't want to have to lock and unlock the list
myself everytime I want to add something or read something or so on. I'd
prefer that the class itself do that.
At least I think those are OK reasons. I honestly don't remember what my
reason was at the time.
David Clegg
> Rod Stephen's book "Delphi 3.0 Algorithms"
PMFJI...
Do you find that to be a good book? I inherited it with a bunch of
other Delphi books, but have never got around to reading it. Is it well
worth making time to do so?
--
Cheers,
David Clegg
dcl...@gmail.com
Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 :-)
Now supports Google Groups searching with Dyna-extend(tm) technology!
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"Ahhh... sweet pity. Where would my love life be without it?" - Homer
Simpson
Captain Jake
> Templates are such a complicated subject that I couldn't hope to explain
> them adeqautely. The best thing to do would be to download one of the
> VC++ express betas and a good C++ book. Then you would see what i'm
> talking about.
Balderdash. Templates are very easy to explain. A template is like a compiler
macro that specifies type. So for example you can write a single list class
that uses <T> for the type throughout it's declaration and definition, and
then when you want to use that class with a particular type, say an TObject,
you declare an instance of the class with TObject in the place of the T in
the class type, and the compiler is smart enough then to create an instance
of that class that is typesafe and that uses TObject where <T> was specified
in the class. Furthermore it is smart enough then to be able to do type
checking on your code that uses this instance.
For example, you could declare a list class like this:
class list<T> {
<T> next;
etc...
}
and then later on you can create a list of TObjects like this:
list<TObject> aList;
or a list of TWidgets like this:
list<TWidgets> bList;
and the compiler would know enough to complain about this line:
aList.next = bList.next;
No rocket science here.
Captain Jake
> > But template were a fully specified part of the language from 1997 -
> > nothing has been added since then apart from a few errata to work out
> > the bugs!
> >
> So? they werent available in 1997. If its not supported in the
> compiler then its not doing me any good.
I am having a hard time keeping a straight face when I read that kind of
historical revisionism. By 1997 templates were available in ALL the major C++
compilers, even Visual C++. I was using templates in Borland/Turbo C++ in
1993. The fact of the matter is that the standard lagged the implementations
back then. By the time the committee blessed templates as a language feature
it was already very anti-climactic.
> I write C++ code the same way i did 10 years ago on a palm :)-
> templates weren't available 10 years ago.
It is funny how often you repeat that silly claim. I can tell you
unequivocally, undoubtedly, certainly and definitely that templates were
available in C++ ten years ago.
>
> > So you are not aware of any new features coming into C++ but still feel
> > it is evolving faster than Delphi?
> >
> Yes because delphi isnt evolving at all unless you plan on using .net
> Aside from a few very minor changes what great leap has delphi made
> language wise?
Interfaces and Dynamic Arrays spring to mind right off the bat.
Captain Jake
<xn0dzihy0...@newsgroups.borland.com>
> Captain Jake wrote:
>
> > Rod Stephen's book "Delphi 3.0 Algorithms"
>
> PMFJI...
>
> Do you find that to be a good book? I inherited it with a bunch of
> other Delphi books, but have never got around to reading it. Is it well
> worth making time to do so?
Yes, I think so.
John Kaster (Borland)
> I'd like to see Grouping and Sorting added to the grid, that'd satisfy
> me.
TClientDataSetGrid?
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
If it's not here, it's not happening: http://ec.borland.com
David Clegg
> Yes, I think so.
Cool. I'll put it on my TODO list somewhere between mastering ECO and
learning C++ :-)
--
Cheers,
David Clegg
dcl...@gmail.com
Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 :-)
Now supports Google Groups searching with Dyna-extend(tm) technology!
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"Facts are meaningless. You could use facts to prove anything that's
even remotely true." - Homer Simpson
Mike Margerum
I bacially explained the same thing you just did about 10 posts ago. it
seemed like he wanted a deeeper explanation.
Mike Margerum
> Alisdair Meredith wrote:
>
>
>>So you are not aware of any new features coming into C++ but still
>>feel it is evolving faster than Delphi?
>
>
> LOL.
>
C++ has evolved more than delphi has in the last 10 years. as for the
future. who knows. I hope delphi does evolves faster. That was the
point of the thread. Look at what m$ has done with C++ for net 2.0. I
hope some of those changes make it into the standard.
Mike Margerum
> years before 1995. I remember that fact VERY distinctly, because they were in
> Turbo C++ 3.0, which is what I used to start teaching myself C++ the year
> before I landed by first programming position in 1993.
>
the STL was in C++ builder 1. That doesnt mean that I was going to use
it. A lot of things didnt work right in it.
Mike Margerum
killFile you. You have got to be the most abrasive and useless usenet
poster i have ever run into.
Mike Margerum
kbmmmw. I had problems with kbmmw but I would like to look at
remObjects again at some point.
Lauchlan M wrote:
> Have you looked at remoting frameworks such as RemObjects
> (www.remobjects.com). While their n-tier solution, Data Abstract, is dataset
> based, it is built on their webservice/remoting framework, RemObjects SDK,
> which you could extend in a custom fashion to transport your data as
> objects. It will shortly be available for .net also.
>
> I believe this is a problem situation many Delphi developers have been faced
> with: they develop in an OO fashion, they then need an object persistence
> framework, and they then need to extend that to an n-tier context.
>
yep. That would be a requirement for me.
> I can't point you towards the best solutions for OO persistence / n-tier
> development in Delphi, but that should not put you from noting that they
> would be out there if you look for them.
>
I dont doubt there are good OPF solutions for delphi. Everything is
there to provide for it. Maybe I need to look at remObjects again.
Mike Margerum
> "I will be using C++ long after delphi goes tits up because the
> language continues to evolve..."
>
> THe implication is that C++ is evolving as a language faster than
> Delphi, and I feel the opposite is true (on the basis of evidence to
> date) I have seen more evolution of Delphi over the last decade than
> C++.
>
I don't see how you got that from that statement. C++ didnt have as much
evolving to do as delphi. Most of the things I talked about in the
original post have been in C++ like you said since 1994.
> So you are not aware of any new features coming into C++ but still feel
> it is evolving faster than Delphi?
>
Again i never said evolving faster. It didnt need to.
Mike Margerum
> Mike Margerum wrote:
>
>
>>An interface is just an abstract class.
>
>
> No, it's not. It's much less than that, and thus much more powerful.
>
How is an interface less than an abstract class? All an anstract class
is is a bunch of pure virtual functions.
Mike Margerum
> LOL.
>
You quoted all that to reply with a LOL? Out of points i see.
Nick Hodges [TeamB]
> C++ has evolved more than delphi has in the last 10 years. as for
> the future. who knows.
I'm not really sure how you can say that, given the extensive changes
made in the language over the last ten years, particularly when you
can't even describe advances in C++.
Nick Hodges [TeamB]
> How is an interface less than an abstract class?
Well, for starters, it's not a class.
Nick Hodges [TeamB]
> The JCL for example is quite large, what features or
functionality in
> particular would you be pointing me towards in it? Similarly for
the
> other two.
I'm not sure what you are looking for.
Nick Hodges [TeamB]
> You quoted all that to reply with a LOL? Out of points i see.
Not out of points. I just thought Alisdair's comment was funny, and
quite well made.
John Kaster (Borland)
> transport your data as objects. It will shortly be available for .net
> also.
FWIW, Delphi 2005 already supports RAD development of remoting.
Lauchlan M
> > also.
>
> FWIW, Delphi 2005 already supports RAD development of remoting.
Sure.
I think RO still has advantages though. It's certainly easy to use, and
judging from Lino Tadros's presentation of .net remoting, remoting is less
so. But maybe your components make it easier. RO also lets you use binary
rather than XML transports when connecting between Delphi apps and XML when
talking to other services.
But the main interest in RemObjects when comparing it to Delphi out of the
box would be for the n-tier functionality with DataAbstract. I'm not aware
of you yet producing anything to replace DataSnap/Midas for n-tier
development in the .net world.
But perhaps I just don't know, the last Enteprise version I used was D6.
Lauchlan M
Nick Hodges [TeamB]
Yes, Jake can be like that if you aren't interested in facts.
Michael Anonymous
> Mike Margerum wrote:
>
>
>>I give up Nick. We are on two totally different planets here. This
>>has nothing at all to do with c++
>
>
> It has nothing to do with C++? They why do you keep mentioning C++?
>
I think he's talking about C++ language features not C++.
C++ languages features can be useful for other languages such as Delphi.
For example, I think Delphi templates would be extremely useful.
Also, I think DTL would be useful as well.
Nick Hodges [TeamB]
> Yes because delphi isnt evolving at all unless you plan on using .net
Ahh, so you admit Delphi is evolving. Just not in a way you like.
That's an entirely different point.
Lauchlan M
> functionality in
> > particular would you be pointing me towards in it? Similarly for
> the
> > other two.
>
> I'm not sure what you are looking for.
I'm not sure what you're trying to tell me! <g>
He said something like . . . 'I want to use templates and other C++ things,
and also do object oriented devleopment n-tier development . . . and I can't
do it in Delphi and I'm going to rant about it.'
You said something like 'well there are third party libraries I can refer
you to to meet these needs.'
I don't see any connection between the links you posted as references and
his stated needs that he was ranting about. That connection is what I was
looking for.
Lauchlan M
Lauchlan M
> seemed like he wanted a deeeper explanation.
No, that was the kind of explanation I was looking for.
Along with ehy you want it so much, and why you consider Delphi deficient in
not offering it and there are no alternatives that work for you.
Lauchlan M
El_Lobo
>>
> I give up Nick. We are on two totally different planets here. This has
> nothing at all to do with c++
>
I actually agree with you here. This is one of the case whem "my car is
better than yours because it's mine". Don't worry, if , in a futureDelphi
gets generics and other cool things, everyone will start "Wow, now AT LAST
we have some cool things in Delphi. You know this is actually cool", and so
on :-)
I have been watching this in every possible community out there (not only
Delphi community). I remember back at D3 times when some people were crying
for some function overload in D3 and the answer from a lot of people (even
some Team B!!!) was: you can always do the same in a more elegant way. You
don't need function overload. Then, we got it in D4 (?) and everybody went
nuts about it. :-)
In psychology this is called "The poor man's syndrome" and it's a normal
human behavior.
Regards
John Kaster (Borland)
> and judging from Lino Tadros's presentation of .net remoting,
> remoting is less so.
Unless Lino's presentation used our remoting components, his demo
wasn't relevant.
> But maybe your components make it easier.
No, they absolutely do.
> RO also lets you use binary rather than XML transports
As does our remoting.
> I'm not aware of you yet producing anything to replace DataSnap/Midas
> for n-tier development in the .net world.
If BDN were up right now (:(!) You could watch the data remoting BDNtv
episodes.
Lauchlan M
> > remoting is less so.
>
> Unless Lino's presentation used our remoting components, his demo
> wasn't relevant.
>
> > But maybe your components make it easier.
>
> No, they absolutely do.
>
> > RO also lets you use binary rather than XML transports
>
> As does our remoting.
ok, all good.
> > I'm not aware of you yet producing anything to replace DataSnap/Midas
> > for n-tier development in the .net world.
>
> If BDN were up right now (:(!) You could watch the data remoting BDNtv
> episodes.
Not really. I'm on dial-up at the moment.
But I saw the one you had before with the data hub etc.
Lauchlan M