native-code languages (slashdot) and Borland rant
Hans-Peter Suter
*I particularly like the following
http://ask.slashdot.org/comments.pl?sid=188271&cid=15522064 which begins
with " The problem isn't native-code vs interpretive code. It's that our
native code languages are terribly flawed."
*Another aspect is platform.
IMHO Borland/DevCo could fly ultrahigh if they somehow managed the platform
problem.
Why not sponsor comunity projects to go after this? Why not invest 1 - 3
millions in projects like
- freepascal
- crossFPC
- eLiquid (crossplatform layer for Pixel Image Editor, info is sparse)
- MSEide & MSEgui
- ... (there are certainly much more)
How the Delphi ecosystem could flourish in future... (.Net, WPF, Win64,
Linux, Mac, choices, choices... (and all in PASCAL) )
but *no* Borland does nothing, and - unfortunately - platformwise also DevCo
doesn't give much hope.
Please more risk!
Regards,
Hans-Peter
Hans-Peter Suter
> Linux, Mac, choices, choices... (and all in PASCAL) )
> but *no* Borland does nothing,
sorry, that was too fast. Of course they do work in .Net/WPF and Win64 and
this very well imho.
Uffe Kousgaard
news:448e...@newsgroups.borland.com...
>
> Why not sponsor comunity projects to go after this? Why not invest 1 - 3
> millions in projects like
>
> - freepascal
> - crossFPC
> - eLiquid (crossplatform layer for Pixel Image Editor, info is sparse)
> - MSEide & MSEgui
> - ... (there are certainly much more)
Just what we need. Borlands far too few resources split between even more
platforms. No, thank you.
Regards
Uffe
Fritz Huber
> platforms. No, thank you.
>
Ditch .NET, it's just not worth it ...
I think a mixture of compiled and dynamic languages is the way to go.
For example just yesterday I've played around with wxPython and I have to
say that I'm totally blown away by its performance, ease of use and
functionality. Definitely worth exploring.
I think I haven't had so much fun playing around with a technology for a
long time.
Getting instant results is just awesome.
This also really changes my opinion about scripting languages.
I don't care what benchmarks say. Python+Wx feels a lot quicker than any
(thick client) .NET stuff I've seen so far. I love it.
somebody
> *Another aspect is platform.
>
> IMHO Borland/DevCo could fly ultrahigh if they somehow managed the
platform
> problem.
Linux won't be worth the effort on desktop in the foreseeable future (didn't
we learn from Kylix?) and Macs run XP now, so nobody cares about MacOS. For
cross platform, there's Java. DevCo should just go back to its strength
rather than spreading too thin.
Arthur Hoornweg
and Macs run XP now, so nobody cares about MacOS.
OTOH, the fact that Macs run on Intel now could be seen as an
opportunity to Borland.
MAC users are used to paying for software (as opposed to Linux users).
MacOS is just a Unix flavour (like Linux) so porting Kylix to IntelMac
should be doable...
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Hans-Peter Suter
(didn't
> we learn from Kylix?) and Macs run XP now, so nobody cares about MacOS.
I don't know about mac, but Kylix was not done proberly imho and it's some
year later now.
>For cross platform, there's Java.
well or Trolltech! But I'd much prefer a pascal based language.
The Pixel editor (http://www.kanzelsberger.com/pixel/?page_id=12) shows that
it *is* possible to write decent desktop based application with Pascal. (And
if (afaic) one person is able to do something like that, what about a whole
corporation, or if they would invest in such things. (I have no idea if he
would even appreciate this, it's just for technical sake).
>DevCo should just go back to its strength
> rather than spreading too thin.
Perfectly true.
I proposed to support fitting open source projects *because* with thin
ressources this may be the only way to broaden the platform support.
Regards,
Hans-Peter
Dave Nottage [TeamB]
> Why not invest 1 - 3 millions in projects like..
If they had that money over and above what they're already investing
into Delphi, I'd rather they invest it in Delphi.
--
Dave Nottage [TeamB]
Uffe Kousgaard
news:448e...@newsgroups.borland.com...
>
> I don't care what benchmarks say. Python+Wx feels a lot quicker than any
> (thick client) .NET stuff I've seen so far. I love it.
This just doesn't necessarily mean it is something Borland should spend
resources on.
Stick to:
1) Native win32
2) Native win64
3) .NET
4) Kylix without visual components.
That's my wishlist. If there are still resources left, we can look at other
platforms.
Regards
Uffe
Peter Morris [Droopy eyes software]
> year later now.
I just don't think there is money to be made in a market where everybody
expects software to be free.
Hans-Peter Suter
> 1) Native win32
> 2) Native win64
> 3) .NET
> 4) Kylix without visual components.
That's my wishlist too ;-)
But as you know it is .Net first, then native and AFAIK no words about
Kylix.
I proposed to support existing projects because it's much cheaper than to do
it all for yourself. And in the short term probably the only realistic path.
With still so many "pascal-based-language-lovers" around I think more would
be possible than is right now. If I look at the RoR community, or Django it
looks so super professional and I wonder why such things cannot happen here.
If I see such incredible things like MSEide and eLiquid, I just feel sad,
that this cannot be integrated in a more mainstream way.
It also can be small things. Just as an example: why not commission an out
of the box integration of crossFPC. I certainly had liked to compile my
non-visual code in a simple way from within BDS.
Regards,
Hans-Peter
Hans-Peter Suter
> expects software to be free.
Do you think this is sustainable?. I simply need to have options for servers
and for science/engineering/numeric related applications.
If DevCo could interact closer with opensource projects like e.g. freepascal
they could support other platform with much less money than until know.
Maybe it would not be perfect, but at least there would be something.
Regards,
Hans-Peter
Uffe Kousgaard
news:448e...@newsgroups.borland.com...
> But as you know it is .Net first, then native and AFAIK no words about
> Kylix.
Allen Bauer admits he still has a linux machine at his office:
http://www.bitwisemag.com/copy/programming/borland/allen_bauer_interview.html
I hope this means there is still a chance to revive Kylix.
Regards
Uffe
SiegfriedN
Most expect software, hardware and standards to be 'Open' rather is the
better answer imo.
Unless you mean 'free' as in freedom as many expect, but that does not
matter they are not your target customers anyways if you plan to
sell/support a business tool. There are many different business models
to explore. 'Linux' is a very 'cosmopolitan' concept !
The Developer Tools Group should not ignore Linux. Please revive Kylix !
Siegs
Marco van de Voort
> I don't care what benchmarks say. Python+Wx feels a lot quicker than any
> (thick client) .NET stuff I've seen so far. I love it.
Measured on apps of which size?
Gary Williams
"Peter Morris [Droopy eyes software]" wrote:
> expects software to be free.
Someday, many mainstream applications will be available at no cost, but some
projects will be funded by ads, donations, training, certification,
technical support, "pro"/"enterprise" versions, vendor-hosting fees, etc.
However, there will always be a market for:
* custom/specialized/proprietary applications
* proprietary extensions to open-source software
* scripts and one-time-use code
* components and libraries
-Gary
mramirez
>I just don't think there is money to be made in a market
>where everybody expects software to be free.
I'm afraid you're right on this one.
What about *BSD ?
The OS is open like *Linux, but you don't have to release the source code of your programs for free, like *Linux...
James K Smith
> expects software to be free.
1) Software that you can't sell has the same profit potential as software
that is free.
2)We still think that we represent the important software users, and we
expect non Windows software to be free, and our Windows software to be
cheap or as close to free as possible. You produce software with unique
value that a company needs for its operation or to turn a profit with, and
that company will pay for that software, windows based or not.
James
Mike Margerum
you can use boo and ironpython on .net
Brad White
news:448f1921$1...@newsgroups.borland.com...
> you can use boo and ironpython on .net
boo?
Is this one-upmanship on C++ (cpp)?
--
Thanks,
Brad.
Fritz Huber
On apps of small size. Things like selecting some Oracle data and displaying
it in a grid, small data entry forms, configuration dialogs, networking
stuff, etc...
The guy who wrote this stuff threw those things together in a couple of
days, although he only used Python before and didn't know anything about Wx
when he started. Pretty impressive. And the users seem to like those
programs. They are responsive, they are cheap (in terms of development
time), they are crossplatform, and changes can be implemented rapidly.
I've also checked some bigger wx programs (DialogBlocks, HelpBlocks,
Audacity), and I love the UI responsiveness (those are written in C++, but
show the capability of Wx).
The thing is, Winforms even renders slowly when only one dialog is involved.
There are probably ways around this, but the point is you never had to worry
about things like UI-performance until now - at least if you didn't use
Swing :)
SiegfriedN
>
> What about *BSD ?
>
> The OS is open like *Linux, but you don't have to release the source code of your programs for free, like *Linux...
>
not deploy closed source applications on Linux! You have to release your
source ONLY IF you statically link in GPL licensed source code. There
are no restrictions to dynamically link in GPL libraties. Of course you
must realise that if you release a closed source application you will
need to release a new binary if your released binary is no longer
compatible - the same rule applies to any other os. Also always read the
license.
Siegs
Barry Kelly
> mramirez wrote:
> >
> > What about *BSD ?
> >
> > The OS is open like *Linux, but you don't have to release the source code of your programs for free, like *Linux...
> >
> Nothing against BSD, but there is absolutely no rule that says you can
> not deploy closed source applications on Linux! You have to release your
> source ONLY IF you statically link in GPL licensed source code. There
> are no restrictions to dynamically link in GPL libraties.
This isn't quite right. For LGPL libraries, what you say is true. Also,
for running code on a GPL kernel or for compiling with a GPL compiler,
these don't infect your code.
However, statically *or* dynamically linking to a GPL library *does*
infect your code. It's the reason behind the distinction between GPL and
LGPL.
-- Barry
Hans-Peter Suter
"Barry Kelly" <barry....@gmail.com> wrote in message
news:s5kv829f7n4o2ffpf...@4ax.com...
> However, statically *or* dynamically linking to a GPL library *does*
> infect your code. It's the reason behind the distinction between GPL and
> LGPL.
The dynamically linking is quite controversial. It depends if the "thing" is
a mere aggregation or a combination, which again is controversial...
Regards,
Hans-Peter
Relaxin
"Peter Morris [Droopy eyes software]" <pete@NO_droopyeyes_SPAM.com> wrote in
message >
> I just don't think there is money to be made in a market where everybody
> expects software to be free.
Relaxin
>
> If they had that money over and above what they're already investing
> into Delphi, I'd rather they invest it in Delphi.
>
Relaxin
> 1) Software that you can't sell has the same profit potential as software
> that is free.
>
I'll have more loyalty to a company that "throws-me-a-free-bone" every now
and then, than a company that can't sell their product because they try to
nickel-and-dime you to death.
I'm willing to bet that Microsoft has more developers using their
development platform than they ever have, simple because they offered a free
version of it. (I personally don't like .NET)
With more customers comes the possibility of more profits.
jeffc
I mean isn't that part of the reason most of us choose Delphi years ago
over slow products like VB and others. It gave our apps a competitive
advantage because ours always ran faster and had none of these issues with
DLLs.
Now with Borland jumping on this MS bandwagon and .NET, it just does not
make sense to me from the perspective of giving their user base what they
have always expected from Borland products. Yes, support .NET but I would
also offer the option to compile code to a standalone EXE. This way while
other .NET Winforms based apps User Interfaces crawl, the Delphi native
compiled ones can run circles around them in terms of speed. Thus again
giving DevCo a very tangible advantage over MS products. Otherwise, I
don't see very strong arguments of using Delphi over C# if everything is
.NET based.
I suggest if you feel the same way as me that you vocalize that opinion
over to:
devco.su...@borland.com
>> the fact that Macs run on Intel now could be seen as an opportunity to
Borland
I agree as well. Having a development environment that could from one
source code base generate native code for Windows, Mac, and Linux would
give DevCo a huge advantage over MS and .NET and the press coverage would
be significant as well. However, this is a big undertaking and whether
the new DevCo has the financial backing for the resources to pull this off
is key.
I think the main problem was that a company that used to be know as
innovators has been changed over time because of lack of resources due to
Borland and their vision of ALM. So I think the strategic choice the
Delphi team had to make based on resources was to piggy back on .NET.
Since without the resources, funding, and backing of the board the Delphi
product was unable to innovate and expand the VCL so that it could compete
with .NET but still be native and fast code.
Who knows what Delphi would be today had DevCo been spun off 4 years ago,
but I feel that it would be a much different product than today and a very
strong competitor to .NET and other MS technologies.
--- posted by geoForum on http://delphi.newswhat.com
Craig Stuntz [TeamB]
> Now with Borland jumping on this MS bandwagon and .NET, it just does
> not make sense to me from the perspective of giving their user base
> what they have always expected from Borland products. Yes, support
> .NET but I would also offer the option to compile code to a
> standalone EXE.
This is, of course, exactly what they are doing.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their
server: http://support.borland.com/entry.jspa?externalID=293
Rick Carter
>also offer the option to compile code to a standalone EXE.
Why would you think DevCo is thinking of abandoning native code?
Look at the roadmap; they will be coming out with native 64-bit compilers
for both Delphi and C++. News flash: Delphi has always supported
compiling to a stand-alone EXE, starting with Delphi 1.
Rick Carter
cart...@despammed.com
Chair, Delphi/Paradox SIG, Cincinnati PC Users Group
Craig Stuntz [TeamB]
> > I don't understand why DevCo should even think of abandoning native
> > code. Yes, support .NET but I would
> > also offer the option to compile code to a standalone EXE.
>
> Why would you think DevCo is thinking of abandoning native code?
Well, he doesn't say they are. Which is good, since they aren't. :)
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
jeffc
>
thought Win32 was end of the line for native Delphi code.
What about things like LINQ and other .NET technologies like XAML. Unless
you are going to fully use .NET then you will not get these features in
native Delphi/VCL code.
However, had Borland been able to resource and fund Delphi like MS funded
the .NET movement, then alot of these technologies that you see in .NET
could be part of the native Delphi compiler and VCL framework.
About the same time Borland started taking away resources/funding from
Delphi team for its ALM vision (after Delphi 4 release), you saw key
architects leaving to go to MS to work on innovating. But thats all in
the past. What I look forward to is DevCo thinking outside of the box
again and really impressing us with new innovative technologies and
hopefully not just piggybacking off .NET technologies forever.
If Borland stuck to core development and not some ALM vision, I would not
have been surprised to have seen a new language come out of Borland that
might have blown away the latest C# even before it was released. This is
the type of radical and surprising things we expected from the original
Borland. Okay maybe thats a bit far fetched...or is it?
Rick Carter
>thought Win32 was end of the line for native Delphi code.
Absolutely; not at all. Read The Fine Roadmap.
http://bdn.borland.com/article/33519
Rick Carter
cart...@despammed.com
Chair, Delphi/Paradox SIG, Cincinnati PC Users Group
--- posted by geoForum on http://delphi.newswhat.com
Craig Stuntz [TeamB]
> > Is a native Win64 planned? I
> > thought Win32 was end of the line for native Delphi code.
>
> Absolutely; not at all. Read The Fine Roadmap.
> http://bdn.borland.com/article/33519
Rick is correct. Also, Jeff, Borland's commitment to native code
products does not mean they have committed to re-implementing .NET in
native code. Hence I would not necessarily expect to see XAML or WPF,
for example, implemented in native code. If you want .NET, you should
use .NET.
On the other hand, Borland has repeatedly and publicly committed to
delivering updates to Win32 and support for Win64 in native code, as
well as a *two-way* migration path between native code and .NET for VCL
users. If you want single source .NET and native code for GUI apps,
then Delphi and the VCL is really your only choice.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
jeffc
has supported native EXE apps from day one.
However, my main point is that Borland will eventually be forcing Delphi
developers to move to .NET and abandon native code simply by the fact that
every new feature added to Delphi will only be available on .NET and thus
Delphi developers will be forced to give up our fast native running EXE
that set Delphi Apps apart from Java, VB, and the newer MS .NET apps.
Example text from Roadmap doc:
"There will be ongoing work for Win32 Delphi and Win32 C++ (such as unit
testing and additional refactorings) but the most of the new work in
Highlander will be focused on .NET 2.0. Highlander will add Delphi.NET
support for generic types, partial classes, and nullable types, and all
WinForms, Web Services, and ADO.NET support will be converted to support
.NET 2.0. VCL, BDP, and ECO will all support .NET 2.0"
Thus Win32 is really only getting minor updates. But we have not heard
about getting new native Win32 language features like Generics, etc. And
the fact that ECO is only a .NET technology clearly illustrates the
Borland movement to .NET only. There is going to be alot of Win32
machines out there for quite some time. I for one would like to be able
to take advantage of an XML driven UI (XAML like) in Win32/Win64 native
apps. I would also like to see Vista support in a native compiler
including Vista UI features. But I don't think this is going to happen.
Which is unfortunate because alot of developers using Delphi that I speak
with are committed to Win32 in their current apps. However, many want to
move to BDS 2006 to take advantage of the great IDE features and FastCode
optimizations, but this motivation is no way related to .NET
However, I do believe we will finally be seeing Full Unicode support in
Win32 Delphi. But what about full object serialization like both .NET and
Java offer.
MS developers are using .NET because thats the only choice they have.
Borland had a chance to offer something different to their developers, but
instead we all will be toeing the line with MS technology. Alot of
current Borland customers who are heavily Win32 based are not happy with
this strategy. And I am sure alot of their customers/clients were
initially impressed by the speed of their apps/products. Do they really
want to migrate to .NET and lose that perception.
Eventually the .NET VM and WinForms will be optimized and future hardware
will run them as fast as our native apps. But this is not in the
immediate future. And who knows when Vista is really going to be released :)
I don't really want to start a ".NET vs" war here. I do think the .NET
technologies look very promising. However, I don't think .NET has yet yet
matured and especially on the WinForms side. But I believe that Borland
could have done it one better (had there been resources and without the
ALM drain). But just maybe, the new DevCo still could.
Craig Stuntz [TeamB]
> Thus Win32 is really only getting minor updates. But we have not
> heard about getting new native Win32 language features like Generics,
> etc.
Well, let's see. New Win32 features in the last couple versions. Mind
you, these are features already delivered, not just spoken about
hypothetically:
o Method inlining
o Class fields
o Operator overloading
o Records with methods
o for .. in
o New memory manager
o Strict private, strict protected
o Class helpers
o Unicode source supported.
Doesn't look neglected to me. And generics for Win32? Everything I've
heard says they're coming, but I don't have a date.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it's good: http://tinyurl.com/7hgfr
jeffc
excited that we might see generics in Win32.
I guess by saying Win32, I also meant the native VCL in addition to the
native language features. But that feature list for Win32 does illustrate
that Win32 is still a big concern for DevCo. A big issue is that ECO
which is a major technology that could have been included with native VCL
is only .NET. I have not heard any plans from DevCo that ECO will be made
available in Win32 (however, I think I did read something about it
becoming available for C++).
Also when I look at the RoadMap it seems dominated by .NET, but I guess if
along the way Win32 is still gets new features then I do see that as a
strong win for DevCo. That is being able to choose both native code and
.NET. However, I hope that the Win32 native VCL gets some advanced
features that .NET framework has (i.e. object serialization, ECO, etc).
Maybe it might make sense to also publish a Win32 and native VCL RoadMap.
However, I do understand now that DevCo has the resources they need, we
should give them some breathing room to finally catchup.
Don't get me wrong, I have alot of optimism about the new DevCo and I am
sure they will be much more responsive in listening to developers needs
than Borland was. This is after all going to be a company for developers :)
Maybe one day we can get David I to run around a stage screaming -
"Developers, Developers, Developers..." LOL
Craig Stuntz [TeamB]
> I have not heard any plans from DevCo that ECO will be made
> available in Win32 ....
ECO is built on .NET and its related technologies. While you could
make a reasonable case that Borland could/should continue to update
Bold in a more official way than they have, I don't think Borland has
any plans to implement .NET in native code, and hence things which are
completely designed around .NET are going to be .NET only. As I said
about XAML, if you want to program in .NET you should use .NET.
Actually, Bold itself is a pretty good case study as to why
implementing ECO for "native" VCL would be such a huge undertaking.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better? Use QC!
http://qc.borland.com -- Vote for important issues
Wayne Niddery [TeamB]
> A big issue
> is that ECO
> which is a major technology that could have been included with native
> VCL is only .NET.
The problem is that the functionality of ECO is highly dependent on various
.Net-only features - such as reflection (win32 VCL RTTI isn't nearly
comparable). While maybe they'll come up with something, I really doubt it
would be feasible to port this to Win32.
BOLD, ECO's Win32 predecessor, can still be obtained.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"It is error alone which needs the support of government. Truth can
stand by itself." - Thomas Jefferson
Randy Magruder
Delphi Win32 -- and truly allow me to have single source applications.
Randy
jeffc
.NET). I also have been explained that full object serialization is also
only possible in .NET because of reflection.
Is it possible for Borland to overhaul the RTTI to allow for a reflection
based technology, or is this just not possible in compiled languages?
Jim Cooper
> Is it possible for Borland to overhaul the RTTI to allow for a reflection
> based technology, or is this just not possible in compiled languages?
In theory reflection is possible in compiled languages (C# is a compiled
language). Overhauling Delphi's RTTI might be trickier if it was to remain both
backwardly compatible and consistent when extended.
I have a vague memory of Danny Thorpe posting on the subject a while back, if
you fancy a bit of Googling.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper jco...@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
Wayne Niddery [TeamB]
> Is it possible for Borland to overhaul the RTTI to allow for a
> reflection based technology, or is this just not possible in compiled
> languages?
It might be possible, *technically*, but I would expect it would be a very
long way from being feasible, it would require re-engineering the VCL from
the ground up and even then it may be difficult to really make it appear and
work exactly as it does in .Net.
Even if possible, given the likely cost of this, and despite how nice it
would be to have, I would rather DevCo spent that time and money on various
other things (including things for Win32, not just .Net).
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"In a tornado, even turkeys can fly." - unknown
Barry Kelly
> Wayne, I understand your points about ECO (RTTI vs power of reflection in
> .NET). I also have been explained that full object serialization is also
> only possible in .NET because of reflection.
>
> Is it possible for Borland to overhaul the RTTI to allow for a reflection
> based technology, or is this just not possible in compiled languages?
To add to the other's points, it would also make everyone's native
executables much bigger because very little code could be eliminated by
the linker. The richer the RTTI, the more code is "reachable" using
techniques that aren't amenable to automated analysis.
Marco van de Voort
> Wayne, I understand your points about ECO (RTTI vs power of reflection in
> .NET)
Isn't rtti reflection? Sure, it could be a bit more accessable, and not
everything is viewable.
> I also have been explained that full object serialization is also
> only possible in .NET because of reflection.
RTTI is roughly reflection, just exposed using an procedural interface and
only for published methods. From binaries with debuginfo you can get even
more info (e.g. by JCLSysUtils)
> Is it possible for Borland to overhaul the RTTI to allow for a reflection
> based technology, or is this just not possible in compiled languages?
Not easy, but possible I think:
- it is incompatible to expand RTTI to non-published properties,
- it would break all streaming code including delphi forms,
- published properties are generally stored twice
- However adding a _second_ rtti system for reflection could be done.
Together with a more friendly interface. Still a major change though,
since it might require adding pointers to table here and there in the VMT
etc.
- A native compiler won't be able to optimize away reflection as a JIT might.
- records (+ constructs that contain them) could be a problem. Could
probably be worked around though.
However why would you want it? If you serialise it, publish it or a property
to it and reap the performance benefit of not having to serialise
everything.
Marco van de Voort
> "jeffc" <nos...@hotmail.com> wrote:
>
>> Wayne, I understand your points about ECO (RTTI vs power of reflection in
>> .NET). I also have been explained that full object serialization is also
>> only possible in .NET because of reflection.
>>
>> Is it possible for Borland to overhaul the RTTI to allow for a reflection
>> based technology, or is this just not possible in compiled languages?
>
> To add to the other's points, it would also make everyone's native
> executables much bigger because very little code could be eliminated by
> the linker.
Why is that? fields are not eliminated by the linker now also.
The added RTTI tables would add a few hundred kb for a significant app, but
that is peanuts.
> The richer the RTTI, the more code is "reachable" using
> techniques that aren't amenable to automated analysis.
That is reflection with respect to code. This is about data. The
reachability of code doesn't change I think, and i'd expect that data is
never eliminated. (except when the whole class is eliminated, something that
doesn't change in this case either)
Barry Kelly
> That is reflection with respect to code. This is about data.
Yes, tired reading eyes of mine. I got up too early yesterday :)
Jim Cooper
> The reachability of code doesn't change I think
It does in a sense. If you have full reflection you can no longer rely on code
analysis to tell whether a class is needed or not, since classes that were not
otherwise needed could be accessed via reflection (the end user could be typing
in class and method names, for example), so you could never tell.
Marco van de Voort
>
> > The reachability of code doesn't change I think
>
> It does in a sense. If you have full reflection you can no longer rely on code
> analysis to tell whether a class is needed or not, since classes that were not
> otherwise needed could be accessed via reflection (the end user could be typing
> in class and method names, for example), so you could never tell.
That involves code. Which is why I made the difference. You don't need code
(finding method names) to do serialisation of the data, since you
effectively can't serialise code.
So if you do data only full reflection, you can do serialisation, and have
no problems with that. (you can't optimize e.g. the initialisation of fields
away anymore though)
If you disallow constructors to be accessed using code-reflection, you could
probably do this too, since you need to construct anyway before you can
reflect, which already pulls in the whole class, and the code reflection is
separated from the data reflection.
One step further (and coarser grained) is to link the class in on any access
of the VMT of the type (via the type-identifier), OR assignment of the type
to a tclass.
Jim Cooper
> That involves code. Which is why I made the difference. You don't need code
> (finding method names) to do serialisation of the data, since you
> effectively can't serialise code.
Ah, OK. But I could still get and set properties via reflection as well. The
point is that you cannot let the linker leave any classes out, since they might
be used another way. And since properties might have getter and setter methods...
Marco van de Voort
>
>> That involves code. Which is why I made the difference. You don't need code
>> (finding method names) to do serialisation of the data, since you
>> effectively can't serialise code.
>
> Ah, OK. But I could still get and set properties via reflection as well.
> The point is that you cannot let the linker leave any classes out, since
> they might be used another way. And since properties might have getter and
> setter methods...
But only if you instantiated it. And that always has a dependancy on the VMT
(or the similar structure in .NET), which you can use to pull the entire
class in.
Same for serialization over the network. _Somewhere_ you have to register
the class so that it can be automatedly get instantiated when such an object
is instantiated. Again a dependancy on the type (VMT) -> pull the class in.
Of course this is a very coarse method, but it also makes it clear _why_
having to forcedly register classes for serialization is a good thing.
Jim Cooper
> But only if you instantiated it.
You can instantiate objects via reflection. You can also get and set
static/class properties.
marg...@yahoo.com
its kind of like python but statically typed
Brad White wrote:
> "Mike Margerum" <ju...@mail.com> wrote in message
> news:448f1921$1...@newsgroups.borland.com...
> > you can use boo and ironpython on .net
>
> boo?
>
> Is this one-upmanship on C++ (cpp)?
>
> --
> Thanks,
> Brad.