I really hate .NET especially inside Delphi
AnnShip
[Pascal Fatal Error] E2328 Linker error while emitting metadata
What is this error as I have been using .NET for quite a long time and
suddenly
it screws up.
When I use VCL.NET, it works perfectly. What could be wrong ?
Removing and Reinstall BDS2006 Pro Edition, .NET, Pack , Roll up won't
help.
Need to add .NET .bpl at all time as it will not remember next time when
loading IDE.
Any help appreciated.
Ann
Robert Giesecke
While being a Delphi32 developer, who really likes that language and advocates its usage over
other tools like (cough) VB, I am embarrassed by the extend in which Delphi.Net sucks.
Most other serious .Net languages do not, btw. ;-)
Nick Hodges (Borland/DTG)
> I am embarrassed by the extend in which Delphi.Net sucks.
What, exactly, makes you say this?
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
http://blogs.borland.com/nickhodges
Robert Giesecke
> Robert Giesecke wrote:
>
>> I am embarrassed by the extend in which Delphi.Net sucks.
>
> What, exactly, makes you say this?
>
Nick Hodges (Borland/DTG)
> Haven't I ranted over pointless compiler added bloat and units in
> D.Net often enough?
I guess not -- what bloat? What is wrong with units?
Robert Giesecke
> Robert Giesecke wrote:
>
>> Haven't I ranted over pointless compiler added bloat and units in
>> D.Net often enough?
>
> I guess not -- what bloat?
>
Well, everything that gets added by the D.Net compiler but that wasn't in your code?
>
> What is wrong with units?
>
Well, units are absolutely poor compared to namespaces. Also the coupling between filename and
unit name (thus namespace) is not exactly what I would call superior or even equal to how other
.Net languages handle it.
A D.Net developer has a lot of disadvantages because D.Net tries to mimic Delphi32. And there's
no way to turn this compatibility stuff off.
more here: http://tinyurl.com/nlee7
I could certainly dig out more. ;)
Nick Hodges (Borland/DTG)
> Well, everything that gets added by the D.Net compiler but that
> wasn't in your code?
I'm not understanding -- what are you talking about?
> Well, units are absolutely poor compared to namespaces.
That's totally subjective -- what's wrong with them?
> Also the coupling between filename and unit name (thus namespace) is
> not exactly what I would call superior or even equal to how other
> .Net languages handle it.
Why not? No one complained about it for the 20 years Pascal used the
exact same system, and it works like it always has with the added
benefit of being able to put any unit in a namespace.
In addition -- these are pretty small complaints, really. "Delphi for
.NET sucks" seems a bit of hyperbole relative to them, don't you think?
AnnShip
it.
Just today something has gone wrong with BDS 2006 Pro with such error.
How can VCL.NET works perfectly well but .NET Winform can not compile
with such error.
This is really weird as Delphi VCL.NET suppose to encapsulates .NET to
run perfectly
but the IDE itself comes up with such error.
If I had to remove and install BDS 2006 again I would move to Turbo
Delphi .NET instead.
Take like 20-30 miniutes for installation.
Ann
"AnnShip" <ans...@gmail.com> wrote in message
news:45229b68$1...@newsgroups.borland.com...
Clinton R. Johnson
> I guess not -- what bloat? What is wrong with units?
I've done very little with Delphi.net aside from some reading as
articles drift by, but correct me if I am wrong, but isn't "UNIT"
treated as something different from "namespace" inspite of the fact
that they are direct conceptual equivalents (dating back all the way to
how they were described in Turbo Pascal 4.0 when they were first
introduced)?
If I understand correctly, then I would consider that something wrong
with units, to be sure.
Kevin Frevert
news:4522ad98$1...@newsgroups.borland.com...
> Well, units are absolutely poor compared to namespaces. Also the coupling
> between filename and unit name (thus namespace) is not exactly what I
> would call superior or even equal to how other .Net languages handle it.
I actually find that superior. For the VS projects I'm working on, I name
my .cs files the same as the namespace it supports (ex. Mailers.Objects.cs,
Mailers.Common.cs, etc). For the other developers here, they really like
not having to open each file to figure out how the namespace is declared.
To each his own, I guess.
krf
David Berneda
> Robert Giesecke wrote:
>> Well, units are absolutely poor compared to namespaces.
> That's totally subjective -- what's wrong with them?
I think he refers to the ability (like C#) for a unit to contribute to an arbitrary namespace, decoupling unit name from
namespace, something like:
unit Unit1;
namespace System.Windows.Forms.Foo1;
...
namespace System.Windows.Forms.Foo2;
so all contents in Unit1 is visible to consumers of System.Windows.Forms.Foo namespace, including other units.
This breaks Pascal #1 rule of top-down unit visibility via "uses" (ie: single-pass parser).
> Why not? No one complained about it for the 20 years Pascal...
Everybody likes anarchy, at least until facing it <g>
regards
david
Robert Giesecke
> Robert Giesecke wrote:
>
>> Well, everything that gets added by the D.Net compiler but that
>> wasn't in your code?
>
> I'm not understanding -- what are you talking about?
>
>> Well, units are absolutely poor compared to namespaces.
>
> That's totally subjective -- what's wrong with them?
>
In most .Net language, I can "use" a namesspace and that way can use all classes within that
namespace.
Also a namespace has no bound to the filename and multiple files can have the same namesspace.
In D.Net you *have* to "use" units if it was a D.Net assembly you are consuming.
This is a pointless and annoying "feature". ;-)
>
>> Also the coupling between filename and unit name (thus namespace) is
>> not exactly what I would call superior or even equal to how other
>> .Net languages handle it.
>
> Why not? No one complained about it for the 20 years Pascal used the
> exact same system, and it works like it always has with the added
> benefit of being able to put any unit in a namespace.
>
Well, this is not 1986 is it? I am missing *choice* here, whether I want to do it in a .Net way
or whether I want to be compatible. Being compatible but handicap yourself for new development
seems to me like a good argument not to do new development in D.Net. ;)
>
> In addition -- these are pretty small complaints, really. "Delphi for
> .NET sucks" seems a bit of hyperbole relative to them, don't you think?
>
No they are not. Not in an environment where certain guidelines exist on how to design APIs.
Basically every D.Net class violates them by having class methods that are named like
properties should be. Also every D.Net class has *public* members that are not necessary and
people will ask you why you wrote that ugly stuff into *every* class.
.Net is not Delphi32 even if it isn't all that different. Having a compiler that doesn't let
you play by the rules is not a nice thing, IMHO.
Peter Morris [Droopy eyes software]
files are small, and the organisation is obvious.
Kevin Frevert
"Peter Morris [Droopy eyes software]" <pete@NO_droopyeyes_SPAM.com> wrote in
message news:4522...@newsgroups.borland.com...
>I have a folder per namespace, and a file per class within each folder.
>The files are small, and the organisation is obvious.
Yes, I forgot to add that part. I too try to mimic the directory structure
to the namespace/classes (ex. Mailers.Common.cs is in
D:\Projects\Mailers\Common).
I won't get into the #$%$'ed up way VS handles project/file/directory
structures (another area where Delphi shines).
krf
Nick Hodges (Borland/DTG)
> I've done very little with Delphi.net aside from some reading as
> articles drift by, but correct me if I am wrong, but isn't "UNIT"
> treated as something different from "namespace" inspite of the fact
> that they are direct conceptual equivalents (dating back all the way
> to how they were described in Turbo Pascal 4.0 when they were first
> introduced)?
No, you've not understood correctly. A unit name corresponds directly
to it's namespace. Very easy to work with and understand.
FOr instance -- it's very easy to see in the project manager which
files contribute to what namespaces. Can't do that in other .Net
languages.
Delphi is just different. I think it's better. Others' don't. Now,
again, you may prefer the other way of doing things, but it's quite a
leap to argue that "Delphi Sucks" because of it.
Nick Hodges (Borland/DTG)
> In D.Net you have to "use" units if it was a D.Net assembly you are
> consuming. This is a pointless and annoying "feature". ;-)
Well, it may be annoying to you, sure, but it is far from pointless.
It's, well, "point-full". I suppose that you can argue that arbitrary
files contributing to arbitrary namespaces is good, but I personally
don't find "arbitrary" a word that I like to associate with my code.
> Well, this is not 1986 is it? I am missing choice here, whether I
> want to do it in a .Net way or whether I want to be compatible. Being
> compatible but handicap yourself for new development seems to me like
> a good argument not to do new development in D.Net. ;)
Delphi for .Net is perfectly compatible with the CLR.
> Basically every D.Net class violates them by having class methods
> that are named like properties should be.
Huh?
> Having a compiler that doesn't let you play by the rules is not a
> nice thing,
Huh? What rules doesn't the compiler play by?
If your argument is "Delphi isn't exactly like C# and therefore I don't
like it", then I'll say "okay, that's your perogative". But if you are
saying -- as it seems that you are saying "Delphi doesn't do it like
C#, and therefore Delphi for .Net sucks", well, I'll dispute that
notion.
Nick Hodges (Borland/DTG)
> For the other developers here, they really like not having to open
> each file to figure out how the namespace is declared.
Exactly.
> To each his own, I guess.
Exactly.
Bryce K. Nielsen
> name my .cs files the same as the namespace it supports (ex.
> Mailers.Objects.cs, Mailers.Common.cs, etc). For the other developers
> here, they really like not having to open each file to figure out how the
> namespace is declared.
>
While I can see why some people like being able to have multiple namespaces
in one unit (it's the same complaint I have against Java, that in Delphi I
can have as many classes as I want in one unit), I feel it's so minor that
it's effectively a preference as opposed to a superior/inferior feature.
What I *do* feel is superior is the ability to have 1 source to compile for
2 platforms (which I have done, with an old middle-tier object library, had
a DotNet and Win32 versions of each).
The pain I had with Delphi and namespaces was D8 to D2005, how they changed
the way they behaved (highly annoying, I hate it when backwards
compatibility is removed) and also how packages vs. libraries vary if you're
consuming the DLL by Delphi or C# (we ended up having to have 3 projects, a
Win32 DLL, a DotNet Package (for Delphi.Net consumers) and a DotNet Library
(for C#/VB.Net consumers)).
-BKN
Bryce K. Nielsen
> files contribute to what namespaces. Can't do that in other .Net
> languages.
>
And I would emphasize that the main reason for this is backwards
compatibility as well as cross platform-ability.
-BKN
Brian Moelk
>> To each his own, I guess.
>
> Exactly.
IMO, that's exactly the problem with the way Delphi for .NET does
namespaces. It doesn't give the developer any choice because something
that should be logical is coupled to the physical.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Nick Hodges (Borland/DTG)
> I think he refers to the ability (like C#) for a unit to contribute
> to an arbitrary namespace,
In my view, this is an inferior solution, as it makes for arbitrary
code that can be scattered all over creation. I prefer the unit name
to clearly determine what the namespace is. I realize other's prefer
the "C#-way". That's cool -- to each his own. But to get from "Delphi
does namespaces in a way different than C#" to "Delphi for .NET sucks
is a pretty large chasm that I dont' think can be leaped.
Nick Hodges (Borland/DTG)
> And I would emphasize that the main reason for this is backwards
> compatibility as well as cross platform-ability.
A perfectly valid reasons. But I still prefer the Delphi solution.
Robert Giesecke
>
> Delphi for .Net is perfectly compatible with the CLR.
>
I never said it wasn't compatible with the CLR.
With "Being compatible" I meant this Delphi32-lookalike and all that unit stuff does not add
anything or new projects, it is only a handicap.
>> Basically every D.Net class violates them by having class methods
>> that are named like properties should be.
>
> Huh?
>
>> Having a compiler that doesn't let you play by the rules is not a
>> nice thing,
>
> Huh? What rules doesn't the compiler play by?
>
> If your argument is "Delphi isn't exactly like C# and therefore I don't
> like it", then I'll say "okay, that's your perogative".
There are guidelines ( http://tinyurl.com/zpwy3 ) on how to design your APIs in .Net. The
methods ClassName and ClassType do not comply to them, and they will be added to *every* class.
And every method of TObject from D32 will be added, which simply looks stupid from the
consumers POV as he won't use it.
Delphi does not have to be exactly like C#, that would be pointless. But it should be possible
to compile "normal" looking assemblies, even if you will complain why I don't consider the
current output as normal. ;-)
>
> But if you are saying -- as it seems that you are saying "Delphi doesn't do it like C#, and
> therefore Delphi for .Net sucks", well, I'll dispute that notion.
>
Well, if a compiler is twisted with an RTL and those unit classes in such a way like it is the
case with D.Net, I am not surprised that it took years to get it working with partial classes
and generics.
That code snippet with class fragment shows a new extreme if it comes to how units vs
namespaces are an handicap: Now one has to "use" multiple units, just to use a single class?
btw:
I do not want to say that it was pointless to have that compatibility, I simply think that
being forced to it is not good. And a single pass compiler is simply not up to date.
What made Delphi special in the native world is not true in the .Net world. Most .Net languages
have Delphi-like features, but they go beyond it.
Using Delphi in .Net will not give you the same ease or compliance to API guidelines as say
using C# or Chrome.
Robert Giesecke
> Clinton R. Johnson wrote:
>
>> I've done very little with Delphi.net aside from some reading as
>> articles drift by, but correct me if I am wrong, but isn't "UNIT"
>> treated as something different from "namespace" inspite of the fact
>> that they are direct conceptual equivalents (dating back all the way
>> to how they were described in Turbo Pascal 4.0 when they were first
>> introduced)?
>
> No, you've not understood correctly. A unit name corresponds directly
> to it's namespace. Very easy to work with and understand.
>
single unit.
Since D2005 the namespace is the unit name before the last dot.
So "Namespacename.Unitname1.pas" and "Namespacename.Unitname2.pas" will place all their types
into "Namespacename".
>
> FOr instance -- it's very easy to see in the project manager which
> files contribute to what namespaces. Can't do that in other .Net
> languages.
>
Well, there's class view. I name my files after the types they contain.
And often I have more folders than namespaces.
>
> Delphi is just different. I think it's better. Others' don't. Now,
> again, you may prefer the other way of doing things, but it's quite a
> leap to argue that "Delphi Sucks" because of it.
>
Well, I see it not from a ProductMan's or Delphi zealot's POV.
If I consider something not as good as the alternatives, it sucks from my POV. Simply because I
can't see a reason why to use it.
Brian Moelk
> But I still prefer the Delphi solution.
Of course you do.
Allen Bauer (Borland/DTG)
> Nick Hodges (Borland/DTG) wrote:
> >> To each his own, I guess.
> >
> > Exactly.
>
> IMO, that's exactly the problem with the way Delphi for .NET does
> namespaces. It doesn't give the developer any choice because
> something that should be logical is coupled to the physical.
So how would you propose that we preserve the implicit built-in make
logic without having some physical mapping? Remember, removing that
functionality is not an option. This implementation was certainly not
done without a lot of thought and consideration. There is so many
things that folks either take for granted or are blithly unaware are
happening behind the scenes that changing the subtle sematics of them
would really hurt the language and the productivity.
--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
http://blogs.borland.com/abauer
Kevin Frevert
news:4522...@newsgroups.borland.com...
> The pain I had with Delphi and namespaces was D8 to D2005, how they
> changed the way they behaved (highly annoying, I hate it when backwards
> compatibility is removed) and also how packages vs. libraries vary if
> you're consuming the DLL by Delphi or C# (we ended up having to have 3
> projects, a Win32 DLL, a DotNet Package (for Delphi.Net consumers) and a
> DotNet Library (for C#/VB.Net consumers)).
Fortunatly, we haven't had to travel down that road yet. A road we did
travel was creating a D2005 .Net package/assembly using units from a legacy
D6 project (a datamodule) to use in an ASP.Net application (Visual
Studio/C#) with zero code changes. Worked like a champ.
krf
Nick Hodges (Borland/DTG)
> I never said it wasn't compatible with the CLR.
> With "Being compatible" I meant this Delphi32-lookalike and all that
> unit stuff does not add anything or new projects, it is only a
> handicap.
Ahh, sorry. Yes, it is backwards compatible. And that is a good
thing. Not a think that makes it "suck".
> But it should be possible to compile "normal" looking assemblies,
> even if you will complain why I don't consider the current output as
> normal. ;-)
Of course I'm going to complain about what you think is "normal". What
you think is normal is what C# does. Frankly, I think Delphi
assemblies are "normal" and C# assemblies look weird. ;-)
> Well, if a compiler is twisted with an RTL and those unit classes in
> such a way like it is the case with D.Net, I am not surprised that it
> took years to get it working with partial classes and generics.
That's a total non-sequitur. The two are unrelated.
> That
> code snippet with class fragment shows a new extreme if it comes to
> how units vs namespaces are an handicap: Now one has to "use"
> multiple units, just to use a single class?
You don't have to use both units to use a single class. You have to
use the unit in which the code is: perfectly normal and sensible.
You appear to be making it sound like the simple act of using a unit is
some sort of horrible burden. I don't think it is.
Nick Hodges (Borland/DTG)
> Of course you do.
Right -- you are surprised? Note that I've got no problem with people
preferring the other way. I do have a problem with people saying
"Delphi sucks" because they prefer the other way.
Nick Hodges (Borland/DTG)
> If I consider something not as good as the alternatives, it sucks
> from my POV. Simply because I can't see a reason why to use it.
Well, that's a pretty low threshold for "sucking". Do all the other
cars in the world suck except the one you own?
mr_organic
$1...@newsgroups.borland.com:
> Brian Moelk wrote:
>
>> Of course you do.
>
> Right -- you are surprised? Note that I've got no problem with people
> preferring the other way. I do have a problem with people saying
> "Delphi sucks" because they prefer the other way.
>
Yeah, that whole "X sucks because I like Y" mentality is pretty rife
among programmers -- at least, *young* programmers. As I have gotten
older, I've lost my zeal for defending one language over another. This is
mostly because I've been around long enough to see the warts and ugliness
of most popular languages. Nothing is ever as good (or as bad!) as people
say.
These days I argue that some languages are semantically and structurally
better for some tasks than others, but overall...you write in whatever
language you're most productive in.
mr_organic
Nick Hodges (Borland/DTG)
Agreed. Though now I get paid to have zeal about the language and to
try to find out why people think stuff "sucks". In this case, I
suspect it's just "I don't like it, therefore it sucks."
Brian Moelk
> So how would you propose that we preserve the implicit built-in make
> logic without having some physical mapping?
I'm not proposing anything.
> Remember, removing that
> functionality is not an option.
What about breaking compatibility? What about changing Delphi's .NET
strategy completely?
We can go there if you want. I particularly don't since I think I've
expressed some of my ideas already. DevCo is going to do what you guys
think is best, I have a feeling that I disagree..but that's cool. We'll
see what happens.
> This implementation was certainly not
> done without a lot of thought and consideration.
Understood; IMO, it's an elegant-ish hack...but I wouldn't call it
*better* than how other .NET languages do it.
> There is so many
> things that folks either take for granted or are blithly unaware are
> happening behind the scenes that changing the subtle sematics of them
> would really hurt the language and the productivity.
With all due respect and despite the bluntness of what I'm about to say,
it's not meant to be rude...but IMO that's your job.
Bruno Fierens [tmssoftware.com]
> to it's namespace. Very easy to work with and understand.
will that not have to change with partial classes ?
Brian Moelk
> Right -- you are surprised?
Of course not.
> Note that I've got no problem with people
> preferring the other way. I do have a problem with people saying
> "Delphi sucks" because they prefer the other way.
I think you're being a bit sensitive here.
I would hope the C# product manager would acknowledge that there are
legitimate reasons for their preferences. Although, that brings up a
separate issue that I believe you already know what my thoughts are.
Bruno Fierens [tmssoftware.com]
>> namespaces. It doesn't give the developer any choice because
>> something that should be logical is coupled to the physical.
>
> So how would you propose that we preserve the implicit built-in make
> logic without having some physical mapping? Remember, removing that
> functionality is not an option. This implementation was certainly not
> done without a lot of thought and consideration. There is so many
> things that folks either take for granted or are blithly unaware are
> happening behind the scenes that changing the subtle sematics of them
> would really hurt the language and the productivity.
but won't it have to change with partial classes
how else will a class in 2 units belong to one namespace
or am I overlooking something ?
Brian Moelk
> Agreed. Though now I get paid to have zeal about the language and to
> try to find out why people think stuff "sucks".
Are you coding in other languages now?
> In this case, I
> suspect it's just "I don't like it, therefore it sucks."
IMO, this shouldn't be dismissed so easily or because of your own
defensiveness.
"Sucks" is certainly hyperbole, but at the end of the day, you're
talking about missed revenue no matter how politely or impolitely one
phrases it. It's much more important to really understand why they like
or dislike something.
Nick Hodges (Borland/DTG)
> IMO, this shouldn't be dismissed so easily or because of your own
> defensiveness.
It wasn't dismissed so easily. I've dismissed it after a rather lengthy
discussion and after the poster himself admitted pretty much that very
point.
> "Sucks" is certainly hyperbole, but at the end of the day, you're
> talking about missed revenue no matter how politely or impolitely one
> phrases it. It's much more important to really understand why they
> like or dislike something.
I'm not sure how I'm "missing revenue". There are valid, revenue
generating reasons for doing things the way we've done them. And I do
understand why he doesn't like the way these things work.
Nick Hodges (Borland/DTG)
> So "Namespacename.Unitname1.pas" and "Namespacename.Unitname2.pas"
> will place all their types into "Namespacename".
Right - perfectly sensible.
Allen Bauer (Borland/DTG)
> Allen Bauer (Borland/DTG) wrote:
> > So how would you propose that we preserve the implicit built-in make
> > logic without having some physical mapping?
>
> I'm not proposing anything.
>
> > Remember, removing that
> > functionality is not an option.
>
> What about breaking compatibility? What about changing Delphi's .NET
> strategy completely?
There are no "sacred cows," but we don't want to slaughter it just
because we were hungry for some bacon (I know.. bacon comes from pigs..
that was part of the alagory ;-).
> We can go there if you want. I particularly don't since I think I've
> expressed some of my ideas already. DevCo is going to do what you
> guys think is best, I have a feeling that I disagree..but that's
> cool. We'll see what happens.
Yep.. We'll see. I also know that you can't please everyone all the
time. There will always be those that disagree.
> > This implementation was certainly not
> > done without a lot of thought and consideration.
>
> Understood; IMO, it's an elegant-ish hack...but I wouldn't call it
> *better* than how other .NET languages do it.
I don't actually remember saying it was "better"... hold on... nope,
didn't say that. I was just expressing that we have a lot more
datapoints to consider when choosing an implementation than the nice
clean slate of other emerging languages such as C#.
> > There is so many
> > things that folks either take for granted or are blithly unaware are
> > happening behind the scenes that changing the subtle sematics of
> > them would really hurt the language and the productivity.
>
> With all due respect and despite the bluntness of what I'm about to
> say, it's not meant to be rude...but IMO that's your job.
Hehe.. good answer! And, yes, that is certianly my job. I just like
to challenge folks' assumptions.
Nathaniel L. Walker
"Kevin Frevert" <ke...@workdrinkingicewater.com> wrote in message
news:4522...@newsgroups.borland.com...
> "Robert Giesecke" <Sp...@Spam.Spam> wrote in message
> news:4522ad98$1...@newsgroups.borland.com...
>> Well, units are absolutely poor compared to namespaces. Also the coupling
>> between filename and unit name (thus namespace) is not exactly what I
>> would call superior or even equal to how other .Net languages handle it.
>
> I actually find that superior. For the VS projects I'm working on, I
> name my .cs files the same as the namespace it supports (ex.
> Mailers.Objects.cs, Mailers.Common.cs, etc). For the other developers
> here, they really like not having to open each file to figure out how the
> namespace is declared.
>
>
>
There is a more superior way to see which namespace a class belongs to,
and that is organizing your projects into folders in the solution. VS will
create a new namespace for each folder in the soluciton, and will properly
nest namespaces as you nest folders.
Unfortunately, this is method is not possible in BDS2006.
- Nate.
Nick Hodges (Borland/DTG)
> I think you're being a bit sensitive here.
Someone says "Your product sucks" and I respond by discussing with him
why he thinks it sucks and why he might consider why it doesn't really
sucks, and I'm a "bit sensitive"? I'm not sure I agree. I've said
more than once that he can think was he likes, but that his rather
harsh assessment (which you agreed is hyperbole) was over the top.
> I would hope the C# product manager would acknowledge that there are
> legitimate reasons for their preferences.
I'm quite sure he would. Not really a big revelation. ;-)
Nick Hodges (Borland/DTG)
> will that not have to change with partial classes ?
Both parts of a partial class will have to be in the same namespace, as
you might imagine, yes.
Nick Hodges (Borland/DTG)
> but I wouldn't call it
> *better* than how other .NET languages do it.
And that's fine -- no problem. But I would.
Jolyon Smith
(Borland/DTG) says...
> So how would you propose that we preserve the implicit built-in make
> logic without having some physical mapping?
The question answers itself - you can't preserve the implicit make logic
by moving to explicit make logic.
The question is, would the move to explicit make logic bring any
additional benefits over the implicit system?
> Remember, removing that functionality is not an option.
For immutable technical reasons (it simply can't be done) or for less
tangible reasons (we don't want to do it because...) ?
> This implementation was certainly not
> done without a lot of thought and consideration.
Which would suggest that the answer is the latter - you positively
decided /not/ to do it, rather than having no choice.
I have yet to get deeply into namespaces, but it seems to me that the
explicit make system of a language (like Chrome, to use an Object Pascal
.net example) increases the flexibility of the language no end and
improves it's credentials as a .net citizen.
i.e. aiui - the ability to "inject" classes into a namespace other than
that in which the physical module containing that class is implemented.
So when I write a class that extends a class in some other namespace, I
can put that class in the namespace it logically belongs in, despite it
being physically tied to a source file that is not part of any project
in that other namespace.
aiui this is not possible with the Delphi.net approach?
But to return to the original question: How to preserve implicit make
logic (presumably for backwards compatability)...
Why not a project option?
Project -> Options -> Compiler:
[x] Explicit Make
(off by default for legacy projects, on by default for new projects)
--
Jolyon Smith
Brian Moelk
> It wasn't dismissed so easily. I've dismissed it after a rather lengthy
> discussion and after the poster himself admitted pretty much that very
> point.
It all comes down to understanding, which I believe you've dismissed
without appreciating why other languages handle a purely logical
construct, i.e. namespaces, without coupling it to a physical file name.
If I saw coupling like that in code, I would fix it (if possible).
What is more telling to me is that you didn't answer my question about
coding in other languages. I know from my own experience, until I coded
in another language, I couldn't really understand that language and
culture and appreciate the differences in a real way.
I'm not certain that anyone really can without some level of immersion,
which brings me back to "Delphi myopia" and my question to you: are you
coding in other languages now?
> I'm not sure how I'm "missing revenue".
If you want to compete in the .NET space, you will have lost revenue if
you cannot provide a more compelling product. And yes, I know...you
think Delphi for .NET is more compelling....
> There are valid, revenue
> generating reasons for doing things the way we've done them. And I do
> understand why he doesn't like the way these things work.
Understood, and you can't please everyone, nor should you try.
Nick Hodges (Borland/DTG)
> It all comes down to understanding, which I believe you've dismissed
> without appreciating why other languages handle a purely logical
> construct, i.e. namespaces, without coupling it to a physical file
> name.
Well, you believe incorrectly. I'm quite clear on the issue and
appreciate it just fine.
> are you
> coding in other languages now?
Nope -- I don't write code much anymore -- it's not part of my job. Of
course, that doesn't mean, as you appear to be implying, that I am
unaware of what other languages are up to. I'm very well aware. That
/is/ part of my job.
> If you want to compete in the .NET space, you will have lost revenue
> if you cannot provide a more compelling product. And yes, I
> know...you think Delphi for .NET is more compelling....
Yes, indeed it is.
> Understood, and you can't please everyone, nor should you try.
Right, and it appears that we haven't pleased you. As much as I'd like
to, I'm not sure that it is possible for us to do that.
Brian Moelk
> There are no "sacred cows," but we don't want to slaughter it just
> because we were hungry for some bacon (I know.. bacon comes from pigs..
> that was part of the alagory ;-).
But I think that's kind of what you've done with your golden goose.
It's now a goose and goat, and it up to now it still only lays eggs.
We'll see if it starts making some milk in the next release.
IMO, a far better approach would be to invest in a separate goat...but
hey, I just buy the milk.
> Yep.. We'll see. I also know that you can't please everyone all the
> time. There will always be those that disagree.
Certainly, and I admit that I'm tough to please. The issue is how many
will you displease for backward compatibility.
> I don't actually remember saying it was "better"... hold on... nope,
> didn't say that.
Nick did.
> I was just expressing that we have a lot more
> datapoints to consider when choosing an implementation than the nice
> clean slate of other emerging languages such as C#.
And that's really the point I was trying to make. A language with a
clean slate would probably have taken a different approach; many of
those languages have done so.
If it were *better*, I believe clean slate languages would have taken
the same approach that Delphi for .NET did. ISTM, if Nick designed a
clean slate language, he would take the same approach and I would
promptly call him crazy.
> Hehe.. good answer! And, yes, that is certianly my job.
;)
> I just like
> to challenge folks' assumptions.
So do I.
Brian Moelk
>> are you
>> coding in other languages now?
>
> Nope -- I don't write code much anymore -- it's not part of my job.
That's too bad. To paraphrase a smart dude: there is value in keeping
one's hands dirty.
> Of
> course, that doesn't mean, as you appear to be implying, that I am
> unaware of what other languages are up to. I'm very well aware. That
> /is/ part of my job.
Certainly, but IMO there is a huge difference between practical
use-in-anger experience and theoretical understanding.
>> Understood, and you can't please everyone, nor should you try.
>
> Right, and it appears that we haven't pleased you.
In some respects Borland hasn't, in others they have. We'll see with
DevCo.
I love Delphi, I just think Delphi's .NET story isn't a viable one long
term.
> As much as I'd like
> to, I'm not sure that it is possible for us to do that.
It is possible, it might not be worth it though. ;)
Chris Uzdavinis
> What is more telling to me is that you didn't answer my question
> about coding in other languages. I know from my own experience,
> until I coded in another language, I couldn't really understand that
> language and culture and appreciate the differences in a real way.
I agree it's good to use multiple programming languages to broaden
ones own horizons. We can learn the different strenghts of the
languages, and think about problem solving in new ways once we become
familiar with the idioms the different languages offer.
That said, it is a disastrous mistake to transplant one language's
idioms into another language when they don't fit well. For example,
one (mis)feature that actually made it into C++ Builder due to Delphi
programmer's requests is the addition of try-finally blocks. They're
great in Delphi, but C++ has other ways to deal with resource cleanup,
which fits the C++ object model much better. In essence, such a
langauge transplant is for Delphi programmers wishing to write Delphi
code with C++ syntax--arguably the worst of both worlds.
If language X uses idiom A, there is no reason to feel that language Y
must also work exactly the same way, or that language Y is in any way
inferior to X simply because it's different. That's simply viewing
the world through a single lens and assuming anything different is
somehow inferior. The world should be viewed through many lenses, and
judgement should be a little more relative to the subject.
--
Chris (TeamB);
Dave Nottage [TeamB]
> I actually find that superior.
Ditto. The C# way can cause no end of confusion, not to mention
disorganization.
--
Dave Nottage [TeamB]
Dave Nottage [TeamB]
> Both parts of a partial class will have to be in the same namespace,
> as you might imagine
To me, it would be way too confusing otherwise.
--
Dave Nottage [TeamB]
Nick Hodges (Borland/DTG)
> Certainly, but IMO there is a huge difference between practical
> use-in-anger experience and theoretical understanding.
Understood -- but I have input from folks who really know languages
that I rely on for the more in depth stuff. I don't have to have all
the knowledge, and indeed I can't.
Nick Hodges (Borland/DTG)
Very well put in light of the topic at hand.
Craig
>
> Of course I'm going to complain about what you think is "normal". What
> you think is normal is what C# does. Frankly, I think Delphi
> assemblies are "normal" and C# assemblies look weird. ;-)
>
Yes, but you are a Delphi programmer and the vast majority of .NET
programmers are not. It means when trying to integrate systems that are
partially written in Delphi and part C# is a PITA.
Nick Hodges (Borland/DTG)
> To me, it would be way too confusing otherwise.
Not to mention to the compiler. ;-)
Nick Hodges (Borland/DTG)
> It means when trying to integrate systems that are partially written
> in Delphi and part C# is a PITA.
How so?
Kyle A. Miller
> Yes, but you are a Delphi programmer and the vast majority of .NET
> programmers are not.
And we're not going to hold that against them either! ;-)
Allen Bauer (Borland/DTG)
> In article <4522c7e4$1...@newsgroups.borland.com>, Allen Bauer
> (Borland/DTG) says...
>
> > So how would you propose that we preserve the implicit built-in make
> > logic without having some physical mapping?
>
> The question answers itself - you can't preserve the implicit make
> logic by moving to explicit make logic.
Yeah... you're right... I certainly coded the only available answer in
the question itself ;-)
> The question is, would the move to explicit make logic bring any
> additional benefits over the implicit system?
This is a thought/research excercise we went through at the very
beginning. Since all the tooling around the language is predicated on
this aspect of the language, it makes changing this behavior *far* more
expensive than just a few tweaks to the compiler. For example, if we
tossed the notion of linking in .dcuils in favor of *only* linking with
packages, maybe, just maybe a move to explicit make logic would work.
However, that is also giving up on, what we've found in our research, a
very important thing that our customers really cling to as a clear
advantage.
>
> > Remember, removing that functionality is not an option.
>
> For immutable technical reasons (it simply can't be done) or for less
> tangible reasons (we don't want to do it because...) ?
I think I answered a little of it above. Certainly there *are*
technical hurdles that would have placed too high a burden (and thus,
cost) on the entire tool-chain. There are also the intangible reasons
of having a very diverse, passionate, loyal, and vocal customer base
that probably would have been more than a little irked at loosing that
key point.
> > This implementation was certainly not
> > done without a lot of thought and consideration.
>
> Which would suggest that the answer is the latter - you positively
> decided not to do it, rather than having no choice.
Again, you seemed to have inferred correctly.
> I have yet to get deeply into namespaces, but it seems to me that the
> explicit make system of a language (like Chrome, to use an Object
> Pascal .net example) increases the flexibility of the language no end
> and improves it's credentials as a .net citizen.
Sometimes perceived flexibility can come at a cost... a cost that is
very hard to quantify. Rather than codifying into the language certain
constraints, that is left to the developers, who will invariably all
choose different variations. Some feel that certain constraints are
liberating, while others feel it stifles their creativity.
> i.e. aiui - the ability to "inject" classes into a namespace other
> than that in which the physical module containing that class is
> implemented.
This was certainly a problem with the way namespaces were done in D8.
Now, it is possible to do exactly that. However, no .NET language
allows you to physically inject into the namespaces of a precompiled
assembly. There is also a *lot* of confusion between an assembly name
and a namespace. An assembly name has zero, none, nada, bearing on the
contained namespaces. The only similarity they may ever have is what
the developer(s) of that assembly have specifically done.
> So when I write a class that extends a class in some other namespace,
> I can put that class in the namespace it logically belongs in,
> despite it being physically tied to a source file that is not part of
> any project in that other namespace.
As long as the unit name maps to that namespace, you can put it into
any namespace.
> aiui this is not possible with the Delphi.net approach?
Borland.Vcl.Classes.pas
Borland.Vcl.Forms.pas
Borland.Vcl.Menus.pas
All the classes in the above units will end up in the Borland.Vcl
namespace. You *could* create a unit Borland.Vcl.Jolyon.pas and it too
will place all the classes into the Borland.Vcl namespace.
> But to return to the original question: How to preserve implicit
> make logic (presumably for backwards compatability)...
>
> Why not a project option?
>
> Project -> Options -> Compiler:
>
> [x] Explicit Make
>
> (off by default for legacy projects, on by default for new projects)
:-)... I think I went into that above...
Clinton R. Johnson
> Robert Giesecke wrote:
>
> > So "Namespacename.Unitname1.pas" and "Namespacename.Unitname2.pas"
> > will place all their types into "Namespacename".
>
> Right - perfectly sensible.
Hmmm. Not sure I'm 100% on board here.
Unit <filename> Namespace a.b.c; Would perhaps read more
straightforward.
filename = <namespace>.<unitname> is perhaps a little stranger, but I
suppose you could USES a namespace and expect the compiler to suck in
all the <namespace>.* files it knows about.
I can see where that would be easier from an implemenation point of
view, maybe even a speed of compilation point of view... Might need to
think about that for a while before I'm totally convinced.
Maybe name files <namespace>.<unit> and the ability to have the unit
header declared Unit <namespace>.<unit> or Unit <unit> Namespace
<Namespace>;
I dunno, I can see the technical issues, but don't like the clumsy
feel...
Time to fire up a VPC and install Delphi.Net and do some actual
playing(have BDS 2005, but you couldn't pay me to start that sucker
up... ugh)
Kyle A. Miller
> So how would you propose that we preserve the implicit built-in make
> functionality is not an option.
This is just an idea I will throw out. Firefox's renderer, Gecko, works
in multiple modes, quirks mode and compliance mode. A mode is chosen
based on the page being rendered.
Would it be possible for the .NET compiler to have a Win32 compatibility
mode which would cause the compiler to operate as it does in 2006? If
the option isn't checked, which would be the case for new .NET projects,
the Delphi.NET compiler provides some .NET specific syntax and features.
This would allow the compiler to grow in .NET without always being tied
to Win32 compatibility.
Kyle A. Miller
> but won't it have to change with partial classes
> how else will a class in 2 units belong to one namespace
> or am I overlooking something ?
As I understand it, the last part of a unit name is trunc'ed and that's
the namespace the classes in the unit belong to. So partial classes can
be supported in the current structure.
If I have TMyClass defined in the following units,
MyCompany.MyProject.MyClassPart1.pas
MyCompany.MyProject.MyClassPart2.pas
then TMyClass belongs to the MyCompany.MyProject namespace.
Wayne Niddery [TeamB]
>
> i.e. aiui - the ability to "inject" classes into a namespace other
> than that in which the physical module containing that class is
> implemented.
I guess I'm not sure what the need is here - why is this so important?
Example, I create a specialized collection class. You're saying I should be
able to make that class available in the existing System.Collections
namespace (a namespace provided by Microsoft).
I don't necessarily *disagree* with this and I would certainly not be
against having the option, but I don't see why it's so crucial - I don't
know why I would actually *want* to pretend my class was written and
provided by MS (as that is basically how it would look).
What I *can* do is name my unit (e.g.) System.Collections.Extras. I can then
add System.Collections.Extras to the uses clause of an application (adding
my package reference to the project) and see my special class. What I would
probably *actually* do is something like System.Collections.Winwright. I can
create a single package that has units that add a Winwright namespace to any
number of existing namespaces - System.Text.Winwright,
Borland.Delphi.Winwright, Microsoft.DirectX.Winwright, etc.
I won't actually say it's *better*, but IMO it makes more sense - my
additions are going to stand out while still being part of a logical
namespace hierarchy.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"It is error alone which needs the support of government. Truth can
stand by itself." - Thomas Jefferson
Allen Bauer (Borland/DTG)
> Allen Bauer (Borland/DTG) wrote:
> > There are no "sacred cows," but we don't want to slaughter it just
> > because we were hungry for some bacon (I know.. bacon comes from
> > pigs.. that was part of the alagory ;-).
>
> But I think that's kind of what you've done with your golden goose.
> It's now a goose and goat, and it up to now it still only lays eggs.
> We'll see if it starts making some milk in the next release.
>
> IMO, a far better approach would be to invest in a separate goat...but
> hey, I just buy the milk.
There's always room for innovation and improvements. However, I also
want to try and preserve as much of the "spirit and intent" of the
language as possible. It makes for a more consistent and cohesive
story.
> > Yep.. We'll see. I also know that you can't please everyone all the
> > time. There will always be those that disagree.
>
> Certainly, and I admit that I'm tough to please. The issue is how
> many will you displease for backward compatibility.
So far it's been not been that bad. In fact there have been a lot of
folks that have lauded this compatibility.
> > I don't actually remember saying it was "better"... hold on... nope,
> > didn't say that.
>
> Nick did.
OK. That's Nick's bias, which is cool. You have another bias, and
that's cool too. To me it's like arguing the notion of right-hand
drive versus left-hand drive between the States and the UK. It's a
matter of what you are exposed to and are comfortable with.
Personally, I think left-hand drive is better... is it, really? Tell
that to a British citizen.
> > I was just expressing that we have a lot more
> > datapoints to consider when choosing an implementation than the nice
> > clean slate of other emerging languages such as C#.
>
> And that's really the point I was trying to make. A language with a
> clean slate would probably have taken a different approach; many of
> those languages have done so.
>
> If it were better, I believe clean slate languages would have taken
> the same approach that Delphi for .NET did. ISTM, if Nick designed a
> clean slate language, he would take the same approach and I would
> promptly call him crazy.
Good point. However, there's really no way to quantify that.
Hindsight is really nice... :-)
> > Hehe.. good answer! And, yes, that is certianly my job.
>
> ;)
>
> > I just like
> > to challenge folks' assumptions.
>
> So do I.
Then keep doing so.
Lord Crc
<nickh...@gmail.com> wrote:
>I don't have to have all the knowledge, and indeed I can't.
Puny human!
- Asbjørn ;)
Allen Bauer (Borland/DTG)
No... contrary to popular belief.. The Incredible Hulk is *not* on the
language analysis commitee. We've reserved him for our business
negotiation commitee ;-).
Jolyon Smith
(Borland/DTG) says...
> Rather than codifying into the language certain
> constraints, that is left to the developers, who will invariably all
> choose different variations.
But isn't that what you have done?
Namespace and unit name are irrevocably tied - that's a constraint (and
one that brings with it further constraints, namely one unit cannot
"service" multiple namespaces).
The developer doesn't get any choice in the matter (or did I
misunderstand your comment? At first reading the sentence seemed
incomplete, and I may have misinterpreted one or both of those comma's).
:$
> Borland.Vcl.Classes.pas
> Borland.Vcl.Forms.pas
> Borland.Vcl.Menus.pas
>
> All the classes in the above units will end up in the Borland.Vcl
> namespace. You *could* create a unit Borland.Vcl.Jolyon.pas and it too
> will place all the classes into the Borland.Vcl namespace.
Ah, of course. Then in months to come when someone is browsing the
files in my project and they see "Borland.Vcl.Forms.<whatever>" they
think "Hmm, I wonder why there is Borland source in this project".
Also, isn't it more likely that I would end up with (silly example
maybe):
Borland.Vcl.Forms.Modal.pas
Which could be a problem if someone else had had the same idea of adding
some Modal specific extensions to Borland.Vcl.Forms - one or other of us
is going to have to choose a different filename.
But if I use something personal and distinctive:
Borland.Vcl.Forms.Jolyon.pas
I'm also likely to end up with:
Borland.Vcl.Classes.Jolyon.pas
Borland.Vcl.Controls.Jolyon.pas
Not only is this confusing as a filenaming convention, aren't I
introducing a high level namespace distinction at a lower level? In any
event imho this illustrates the problem that tying filename to namespace
the constraint creates.
As I see it the problem arises from the occasionally differing needs of
the two things that Namespace and Filename address separately (even
though in some cases, perhaps even the majority, the two /seem/ similar,
if not the same):
Namespaces address the organisation of referenceable code entities.
Filenames address source/project management and organisation.
The two aren't always synonymous.
Surely it would be preferable to use a filename helpful in project
orgnaisation:
Jolyon.VCLExtensions.Forms.pas
with the source referencing resolved separately in the module:
"namespace Borland.VCL.Forms;"
In fact, given that any such extensions are likely to be fairly trivial,
I might even have simply:
Jolyon.VCLExtensions.pas
And in that unit:
type
Borland.VCL.Forms.TJolyonsForm = class(TCustomForm);
Borland.VCL.Menus.TJolyonsMenu = class(TCustomMenu);
As I said, I've yet to get into namespaces in Chrome to any real depth,
but this seems to be preferable.
+0.02
--
Jolyon Smith
Jolyon Smith
says...
> I guess I'm not sure what the need is here - why is this so important?
Not important maybe, but desirable almost certainly.
See reply to Allen's post.
It boils down to the organisation of referenceable code entities
(namespaces) vs the organisation of source code.
Much of the time the two are synergistic, but occasionally I could see
they would not be.
--
Jolyon Smith
Oliver Townshend
> with it.
> Just today something has gone wrong with BDS 2006 Pro with such error.
> How can VCL.NET works perfectly well but .NET Winform can not compile
> with such error.
> This is really weird as Delphi VCL.NET suppose to encapsulates .NET to
> run perfectly
> but the IDE itself comes up with such error.
Because of your provocative subject, your thread has been hijacked. I
suggest you ask this question in a more straightforward way in a more
technical group like borland.public.delphi.language.delphi.dotnet or
borland.public.delphi.rtl.dotnet
Oliver Townshend
Oliver Townshend
> language analysis commitee. We've reserved him for our business
> negotiation commitee ;-).
And Bruce Banner gives you advice on gamma testing?
Oliver Townshend
I.P. Nichols
> Robert Giesecke wrote:
>
>> If I consider something not as good as the alternatives, it sucks
>> from my POV. Simply because I can't see a reason why to use it.
>
> Well, that's a pretty low threshold for "sucking". Do all the other
> cars in the world suck except the one you own?
Nick, I'm not sure what your objective in this thread might be but if it's
to keep badgering Robert until he changes his mind then you may not be in a
winnable position.
And in the meantime you have encouraged the growth of a long thread that so
far has mentioned the word "suck" in 19 message of which 10 were posted by
you. Is that the best use of the Delphi Product Manager's time?
Which is the better approach, to engage in protracted defensive non-tech ng
word wars with any and all who posts something you consider offensive or
just turn a deaf ear and spend that time reaching out and attracting new
customers to your company?
Tim Jarvis [Borland/DTG]
> David Berneda wrote:
>
> > I think he refers to the ability (like C#) for a unit to contribute
> > to an arbitrary namespace,
>
> In my view, this is an inferior solution, as it makes for arbitrary
> code that can be scattered all over creation. I prefer the unit name
> to clearly determine what the namespace is. I realize other's prefer
> the "C#-way". That's cool -- to each his own. But to get from
> "Delphi does namespaces in a way different than C#" to "Delphi for
> .NET sucks is a pretty large chasm that I dont' think can be leaped.
One of the nice advantages of being able to spread namespaces over
multiple files is in multi-developer project environments, for example
we ourselves have a situation where our common controls ( TEdit,
TListBox etc etc) are all contained in one unit, and unless you are
happy to merge your checkins (fine with Starteam, subversion etc but
out of the question with Source-Safe) it's awkward to split it up for
team development.
Sometimes it simply does make sense for tightly coupled and related
classes to be contained in the same naming and reference scope, but
equally advantageous to be in it's own physical file. (most noticiable
in component suites)
Regards
--
Tim Jarvis
Product Evangelist APAC Team Lead (DTG)
Tim Jarvis [Borland/DTG]
Oh, and just to be clear, Delphi.NET does allow for this. So the major
flexibility point that people are talking about is covered, its just
the other way that is not covered (multiple namespaces in one file)
which IMO is not really that good an idea, in 2 years of C# coding
(which allows this feature) I have never once needed or used it.
Cheers Tim.
Kevin Frevert
"Nathaniel L. Walker" <NatLW...@NoEmail.Hah> wrote in message
news:4522...@newsgroups.borland.com...
>>
> There is a more superior way to see which namespace a class belongs to,
> and that is organizing your projects into folders in the solution. VS
> will
> create a new namespace for each folder in the soluciton, and will properly
> nest namespaces as you nest folders.
>
Yea, solutions. I love the fact I *have* to right-click, set the project as
the default before I can run it. Talk about a time waster.
I also love how when creating a new project, VS requires the directory name
match the project name.
I'd go on, but it would be a small book and I don't have the time.
Don't get me wrong, there is a lot I do like about VS/C# (right now,
auto-format and debugging). It's those small things that really irk me.
krf
Allen Bauer (Borland/DTG)
> In article <4522f434$1...@newsgroups.borland.com>, Allen Bauer
> (Borland/DTG) says...
>
> > Rather than codifying into the language certain
> > constraints, that is left to the developers, who will invariably all
> > choose different variations.
>
> But isn't that what you have done?
>
> Namespace and unit name are irrevocably tied - that's a constraint
> (and one that brings with it further constraints, namely one unit
> cannot "service" multiple namespaces).
I guess that was my point... It seems that less anarchy can envelop
with certain constraints codified in the language.
> The developer doesn't get any choice in the matter (or did I
> misunderstand your comment? At first reading the sentence seemed
> incomplete, and I may have misinterpreted one or both of those
> comma's).
And look at how well that has done for C++ ;-)... C++ was quickly
becoming more a meta-language rather than a strict set of syntactical
and semantic rules. (I'm not picking on C++, just expressin my POV).
> > Borland.Vcl.Classes.pas
> > Borland.Vcl.Forms.pas
> > Borland.Vcl.Menus.pas
> >
> > All the classes in the above units will end up in the Borland.Vcl
> > namespace. You could create a unit Borland.Vcl.Jolyon.pas and it
> > too will place all the classes into the Borland.Vcl namespace.
>
> Ah, of course. Then in months to come when someone is browsing the
> files in my project and they see "Borland.Vcl.Forms.<whatever>" they
> think "Hmm, I wonder why there is Borland source in this project".
I did present a somewhat extreme contrived example. I would not expect
someone to inject into the Borland.Vcl namespace.
> Also, isn't it more likely that I would end up with (silly example
> maybe):
>
> Borland.Vcl.Forms.Modal.pas
>
> Which could be a problem if someone else had had the same idea of
> adding some Modal specific extensions to Borland.Vcl.Forms - one or
> other of us is going to have to choose a different filename.
>
> But if I use something personal and distinctive:
>
> Borland.Vcl.Forms.Jolyon.pas
>
> I'm also likely to end up with:
>
> Borland.Vcl.Classes.Jolyon.pas
> Borland.Vcl.Controls.Jolyon.pas
I would inject the new namespace at the Borland.Vcl level and not at
the "unit" level. In the above examples, the namespaces are
Borland.Vcl.Classes and Borland.Vcl.Controls. The items in the two
units are in different namespaces.
> Not only is this confusing as a filenaming convention, aren't I
> introducing a high level namespace distinction at a lower level? In
> any event imho this illustrates the problem that tying filename to
> namespace the constraint creates.
Again, the above example is probably not a likely scenario. However
with a judicious level of discipline and forethought, the file names
become *very* clear to their meaning and their association.
> As I see it the problem arises from the occasionally differing needs
> of the two things that Namespace and Filename address separately
> (even though in some cases, perhaps even the majority, the two seem
> similar, if not the same):
>
> Namespaces address the organisation of referenceable code entities.
> Filenames address source/project management and organisation.
>
> The two aren't always synonymous.
There are other languages that use filenames to indicate namespaces...
Java, for example takes this to the extreme by using the directories
and subdirectories hierarchy. So this isn't unique to Delphi at all.
Jolyon Smith
(Borland/DTG) says...
> There are other languages that use filenames to indicate namespaces...
> Java, for example takes this to the extreme by using the directories
> and subdirectories hierarchy. So this isn't unique to Delphi at all.
Um, so Delphi is the way it is because other languages are the way they
are?
I thought it was decided to adopt the approach after long and careful
consideration for positive reasons, influenced in part by technical
practicalities?
;D
--
Jolyon Smith
Wayne Niddery [TeamB]
>
> I'm also likely to end up with:
>
> Borland.Vcl.Classes.Jolyon.pas
> Borland.Vcl.Controls.Jolyon.pas
>
> Not only is this confusing as a filenaming convention, aren't I
> introducing a high level namespace distinction at a lower level?
Actually I agree on this (despite my own similar example). Why would you not
name it:
Jolyon.Vcl.Classes
Jolyon.Vcl.Controls
instead?
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Light is faster than sound, which is why some folks appear bright
before they speak."
Allen Bauer (Borland/DTG)
> In article <4523222e$1...@newsgroups.borland.com>, Allen Bauer
> (Borland/DTG) says...
>
> > There are other languages that use filenames to indicate
> > namespaces... Java, for example takes this to the extreme by using
> > the directories and subdirectories hierarchy. So this isn't unique
> > to Delphi at all.
>
> Um, so Delphi is the way it is because other languages are the way
> they are?
I was merely saying that other language designers have taken similar
approaches to making filenames and namespaces have a strong
relationship. Just a statement as an added datapoint.
> I thought it was decided to adopt the approach after long and careful
> consideration for positive reasons, influenced in part by technical
> practicalities?
I did say that didn't I.
Nathaniel L. Walker
"Kevin Frevert" <ke...@workdrinkingicewater.com> wrote in message
news:4523...@newsgroups.borland.com...
>
> Yea, solutions. I love the fact I *have* to right-click, set the project
> as the default before I can run it. Talk about a time waster.
> I also love how when creating a new project, VS requires the directory
> name match the project name.
Since when? I can create a project and move it to another directory, and
run
it without problems. I can create a project, then rename it in the same
directory
(making the names not match) and then run it without problem. I can get a
project
from someone else in a zip file, and then unzip it in a directory that
doesn't match
its name, and run it with no problem. There are ways to avoid having your
project
in a directory that matches its name. /yawns/
> I'd go on, but it would be a small book and I don't have the time.
>
> Don't get me wrong, there is a lot I do like about VS/C# (right now,
> auto-format and debugging). It's those small things that really irk me.
>
There are small things that irk everyone about every product. That is why
there
is more than one version (1.0, 2.0 .... ....), right?
> krf
>
>
- Nate.
Tom Reiertsen
news:4522f974$1...@newsgroups.borland.com...
>
> No... contrary to popular belief.. The Incredible Hulk is *not* on the
> language analysis commitee. We've reserved him for our business
> negotiation commitee ;-).
>
How about putting him on the committe that's holding up the DevCo news for a
few minutes?
Best Regards,
Tom Reiertsen
Rick Beerendonk
>> in Delphi and part C# is a PITA.
>
> How so?
I am following the whole discussion here and every post of Nick I am more
amazed about his lack of understanding of the .NET users. There are a number
of usability issues involved with the features Robert Giesecke is missing in
Delphi, but Nick doesn't seem to give a damn. Really, Nick clearly shows
that he doesn't understand fully the implications of the differences between
choices made in pure .NET languages and choices made in Delphi.
It gives me a bad feeling that the people behind Delphi doesn't understand
Robert's (and my) needs. Especially since Nick continuesly writes that
Robert's issues aren't "a big thing", while it clearly is a big thing for
Robert (and me)!!! This kind of behaviour allienates users.
Rick
Tom Reiertsen
>
> OK. That's Nick's bias, which is cool. You have another bias, and
> that's cool too. To me it's like arguing the notion of right-hand
> drive versus left-hand drive between the States and the UK. It's a
> matter of what you are exposed to and are comfortable with.
> Personally, I think left-hand drive is better... is it, really? Tell
> that to a British citizen.
>
Isn't the whole point here that when left-hand drivers and right-hand
drivers are trying to drive on the same road it's a complete mess?
Best Regards,
Tom Reiertsen
Clinton R. Johnson
Kaster, and even I'm wondering wtf?
He asked for details to understand better and you call him for not
giving a crap?
Ok, granted that I think the whole Delphi team needs more time on real
world projects, but Nick is a recent addition with some of that very
same experience, so when he has an opinion, it isn't always just that
he's been locked in the ivory tower too long.
And sometimes, somethings really aren't a big deal to anyone but you.
And ya, even I trip out, but seriously, if yer gonna call a guy on
something, do it when he's actually doing it, instead of doing
something about it, like actually asking for details.
Dan Smith
"Rick Beerendonk" <rick@fake_beerendonk.com> wrote:
>It gives me a bad feeling that the people behind Delphi doesn't understand
>Robert's (and my) needs.
I guess it is easier to feel bad that needs aren't being met by being the only two
developers in the world.
--
Dan
Oliver Townshend
> drivers are trying to drive on the same road it's a complete mess?
No, its only a problem if left hand drivers get on the road. Otherwise
everything's ok :)
Oliver Townshend
Chad Z. Hower
> > It means when trying to integrate systems that are partially
> > written in Delphi and part C# is a PITA.
>
> How so?
Nick,
1) Just try it. There are dozens of things. Take any object made in
Delphi and try to use it from C#. The Indy team had massive issues here
and eventually had to remove the VCL. Even then there were issues and
why there is now a C# port under way as a fork.
2) Check the Delphi 2005 Field Test newsgroups assuming such a beast
existed of course - I had several lengthy threads with Danny before he
left about many issues, many of which are pretty simple to fix.
Delphi CANNOT create an assembly that looks like a "native" .NET asm
created by other langauges. It always has Delphiisms in it that confuse
and complicate use by other non Delphi languages. Delphi.system for
one, how it exports its metadata, class methods, global variables and
more. And the VCL has several unsafe calls, in fact there are also
quite a fe things in initiailzation sections that have problems under
pverified environments.
--
"Programming is an art form that fights back"
http://www.KudzuWorld.com/
Need a professional technical speaker at your event? See www.woo-hoo.net
Chad Z. Hower
> I am following the whole discussion here and every post of Nick I am
> more amazed about his lack of understanding of the .NET users. There
> are a number of usability issues involved with the features Robert
> Giesecke is missing in Delphi, but Nick doesn't seem to give a damn.
To be fair - I've known Nick a long time. I believe he does give a damn
- but he just doesn't understand the issues becaues his background is
so heavily Delphi and thats where he's focused. If he was to spend a
year or so in C# then come back to Delphi he'd quickly see the issues.
> Really, Nick clearly shows that he doesn't understand fully the
> implications of the differences between choices made in pure .NET
> languages and choices made in Delphi.
He doesn't. And to be honest, neither did Danny when he was at Borland.
He understood many of them after I had some long discussions with him
and some he already understood before, but at the time they werent high
priority. For Borland it was to make Delphi a good .NET consumer, not
exporter.
> It gives me a bad feeling that the people behind Delphi doesn't
> understand Robert's (and my) needs. Especially since Nick continuesly
> writes that Robert's issues aren't "a big thing", while it clearly is
> a big thing for Robert (and me)!!! This kind of behaviour allienates
> users.
I'm not sure what more we can do to convince him. I dont have time to
write them up one by one. I only use Delphi now for Win32 code.
Chad Z. Hower
> That said, it is a disastrous mistake to transplant one language's
> idioms into another language when they don't fit well. For example,
Its not one language idioms for another. .NET is a platform. Many of
C#'s features are not there because its C#, but because it conforms to
.NET's CLS. VB has the same required features as does Fortran for .NET
and so on. Delphi in the .NET world is a second class citizen and does
not speak "Native .NET" but instead speaks with a heavy accent and poor
grammar. Just like such a speaker, it understands English speakers just
fine - but the reverse is not always true.
Tom Reiertsen
"Clinton R. Johnson" <sp...@not.xepol.com> wrote in message
news:45234bd3$1...@newsgroups.borland.com...
>
> He asked for details to understand better and you call him for not
> giving a crap?
>
Hi,
Don't bash Rick's post, I've only observed this thread too but agree with
most of Rick's observations. I genuinely believe that Nick wanted to find
out why Robert disliked Delphi .Net, but when it all came out in the open he
quickly dismissed it as "you're wrong"/"I don't agree" and then began the
futile discussion trying to persuade him to think otherwise. Sometimes less
is more.
I'm not Nick so I don't know for sure, I'm just saying that's how I read
this thread.
Best Regards,
Tom Reiertsen
Rick Beerendonk
> giving a crap?
He asked for details, but not before he has given his opinion about what the
other wrote:
"That's totally subjective -- what's wrong with them?"
"I guess not -- what bloat? What is wrong with units?"
"Huh? What rules doesn't the compiler play by?"
In my view this is not the best way to approach customers who take the time
to explain to you what they like to see different and why. And if it is very
important to them, at least show you understand that it is important to
them, even when it is not important to you or to most other users.
Rick
Tom Reiertsen
news:4523...@newsgroups.borland.com...
>
> No, its only a problem if left hand drivers get on the road. Otherwise
> everything's ok :)
>
I believe otherwise. In right-hand driving countries we should gradually
move to left-hand driving. Start with big-trucks and buses first and the
problem should sort itself out eventually :)
Tom
Rick Beerendonk
> only two
> developers in the world.
Although the words used by Robert were not at all friendly about Delphi.NET,
I do think that Nick should be more careful in showing his opinion. He asks
questions, but not before he has made a slightly unfriendly remark (see my
reaction to Clinton R. Johnson).
I am especially not happy about Nick's attitude towards Robert (who shares
my ideas).
Rick
Ingvar Nilsen
> I prefer the unit name to clearly determine what the namespace is.
??? + ???
What about having several classes under the same namespace? This is
more the rule than the exception.
Myself, I never have more than one class/interface in one physical
file. The filename is always the name of the class/interface. I use
folders to organise namespaces, and have units belonging to the same
namespace in the same folder.
--
Ingvar Nilsen
http://www.ingvarius.com
Ingvar Nilsen
> its just the other way that is not covered
> (multiple namespaces in one file)
Yeech!
> which IMO is not really that good an idea
Not at all, yeech!
> in 2 years of C# coding
> (which allows this feature) I have never once needed or used it.
I don't see the need for it at all.
BTW, the more I program, the more years go by, the more files I get and
the less code in each file I have.
Rick Beerendonk
> - but he just doesn't understand the issues becaues his background is
> so heavily Delphi and thats where he's focused. If he was to spend a
> year or so in C# then come back to Delphi he'd quickly see the issues.
I understand Nick's background, but I do think that we also get to see why
Delphi.NET is not a huge success. Borland still believes that a number of
issues are a matter of opinion, while in fact that is not a practical point
of view. In fact when you want to be in the .NET world, you'd better live by
their guidelines. It makes life a lot easier. Maybe it is easier to see for
someone in Europe with a lot of different cultures and nationalities in one
spot. You can quickly see the problems that arise when everyone stick to
their own habits. Life can be so much easier if you give up some of the
least important habits. In .NET perspective:
- Don't use T for classes
- Don't use On for events
- Unit names are a problem when using a lot of code files.
- Don't try to port VCL to new platforms (Like WinForms, Compact Framework,
is WPF next?), while all other .NET users use the "standard" platform.
- Etc. etc.
Delphi.NET lives on it's own island. Everyone drives on the left side of the
road and the cars produced have the steering on the right. That is not
problem if you stay on the island, but a pain when you leave or enter the
island to/from a world where things are the other way around.
Sometimes the best product isn't the best solution.
> For Borland it was to make Delphi a good .NET consumer, not exporter.
That explains a lot! Now I understand why it is so hard to write component
packages or an application that supports add-ins that have to be written in
other .NET languages. It simply wasn't their goal. I just wonder why anyone
would be interested in consuming only, while you can also get exporting for
the same price elsewhere. The only reason I can come up with are the current
users unwilling to invest in learning a new language.
> I'm not sure what more we can do to convince him. I dont have time to
> write them up one by one.
That is why Nick should be happy with Robert's comments, although they were
unfriendly. Nick however couldn't hide his emotions enough. That will
decrease the number of people willing to invest time in explaining Borland
what might be wrong with their .NET approach.
Rick Beerendonk
Holger Flick
> No, you've not understood correctly. A unit name corresponds directly
> to it's namespace. Very easy to work with and understand.
I disagree as soon as you import ActiveX, a WebService etc. Guessing
the unit name is a chore. Make it more obvious or at least write some
documentation how the unit name is being "produced" if you import a
webservice. With C# this is just so much easier...
Furthermore, as has been pointed out in this thread already w/o
actually giving that as a reason Delphi.NET is a pain to work with
interop-wise because of dcpil-files which seldom seem to get updated
when you recompile or rebuild and thus make the IDE unaware of the
changes.
Whenever there is interop in .NET I "default" to C# right now.
--
Holger
Rick Beerendonk
> assemblies are "normal" and C# assemblies look weird. ;-)
It is much harder to get Delphi code samples when you want to learn .NET
technologies (how .NET handles XML, WinForms, Remoting, etc.) then to find
C# material. I like to buy a good book and most of the time that book is a
C# book. So, even if I program in Delphi, I get used to some of the C#
habits. I tend to get used to the C# habits that seems better than the
Delphi habits (and surely, some Delphi habits won't go away, because C# has
its weaknesses too).
So I am "forced" to get exposed to some C# code/habits and then looking
normal or weird isn't really the issue. Some solutions are actually more
productive or making me more happy.
Rick
Rick Beerendonk
>
> Both parts of a partial class will have to be in the same namespace, as
> you might imagine, yes.
I've read http://www.drbob42.com/examines/examin82.htm
It is confusing to see that if you use the namespace, you get the whole
partial class, but if you use one of it units, you get only a part of the
partial class. That is perfectly logical, but it also shows how confusing it
is to have two almost (!) identical solutions (units & namespaces) for a
single problem in the same product.
Rick
Clinton R. Johnson
> with most of Rick's observations.
My issue is primarilly with the timing. This is basically the question
he wants asked, without any of the preface. This isn't the time to bob
and weave, it is the time to lay it out as he sees it.
You might have a bitch with past behaviour, but when you finally get to
the point you want, it is counter productive to keep bitching.
> I genuinely believe that Nick
> wanted to find out why Robert disliked Delphi .Net, but when it all
> came out in the open he quickly dismissed it as "you're wrong"/"I
> don't agree" and then began the futile discussion trying to persuade
> him to think otherwise. Sometimes less is more.
I'll grant that Nick has some communication issues, but clearly so do
all the rest of us. So, he asked the question, and all I saw was a
litany of past sins instead of answers. That is why I called foul (and
I knows 'em when I see 'em, cause I've done it myself, and it's only
hurt my point of view instead of furthering my cause)
So ya, let's get on with it and actually see an answer to the question
which Rick so anxiously wants to answer.
Clinton R. Johnson
apparently irritates you so.
Rather than hash over past hurt feelings, take this opportunity to
explain your point of view in clear, objective terms and maybe you'll
get what you were really after in the first place - Listened to.