You indicate a familiarity with Delphi but the example you present in your
complaint about the begin end and the comment about training newbies with
the code sample (see below) indicates that you may be part of the problem
if you write code like that (much less train other developers to do so).
At 7/29/2005 12:54 PM -0400, you wrote:
>if (s = 'test) and (sWork = 'Blah') then
>begin
> // some code
>end
>else
>if (s = 'test2) and (sWork = 'Blah2') then
>begin
> // some code
>end
>else
>begin
> // some code
>end;
Admittedly, I code Delphi with a slight quirk from my days as a PL/I
programmer but I would have coded that example as:
if (s = 'test') AND
(swork = 'Blah')
then begin
// some code
end
else begin
if (s = 'test2') AND
(sWork = 'Blah2')
then begin
// some code
end
else begin
// some code
end; {if}
end; {if}
Now if that seems a little key-stroke heavy, you obviously haven't learned
the magic of the <Ctrl><j>. I have a template in the list that gives me
the following (appropriately indented at the point of my typing "if"):
if (<here is where the cursor winds up)
then begin
end
else begin
end; {if}
When you point out that it "isn't as easy to write and read as a SQL CASE
or COBOL Evaluate", you seem to have forgotten the Delphi case statement
which is in the following form (which, again, I can have dropped into my
code, appropriately indented, by typing "case<Ctrl><j>"):
case variable of
<match1> : begin
end; {match1}
<match2> : begin
end; {match2}
{etc}
else begin
end;
end; {case}
Interestingly enough, Delphi is not just limited to integers,
either. Admittedly, Delphi's case is limited to some fairly basic sets of
controls (e.g. boolean, char, integer) but, as I mentioned, it is easy
enough to extend that capability. Admittedly, far too many programmers
fail to make use of cse statements but that is true for ANY language
(including SQL).
I have almost all of my preferred code templates available through the
<Ctrl><j> trick and it significantly speeds up my coding . . . as well as
providing some rudimentary comments that help keep the nestings straight.
I am not sure what you mean by "Honestly, I would settle for the auto
procedure create keystroke to create default parameters in the type and not
forget about them and generate compile errors''. If you declare your
procedure/function properly in your class object, when you do a
<Ctrl><Shift><c>, then the procedure/function is expanded with your
parameters INCLUDED AS YOU DEFINED THEM. Therefore, again assuming that
you have defined your procedure/function properly, there will be no compile
errors. If you add the unit to your "uses" list, the IDE will ven prompt
you with the nature of the parameters you need to add as you are typing.
"In .net the scope is in the class you create the variable just like a
unit. There are no global variables and I like that concept."
In Delphi the primary scope is within the unit. Yes, there is the ability
to create global variable (I confess to using them at times and even to
having created a "global variables unit" for constants that I find
frequently useful); however, I do NOT encourage the random use of global
variables. (I do, as I mentioned, believe that there are uses for
them.) I also like the fact that I can create a Delphi unit with
"handy-dandy" functions and procedures (e.g. my IsInt function, my
StringCase function, or my VINCheckDigit calculation function) as well as
ones with a tool-type class (e.g. I have a ConsoleLogger and Logger
unit/class for obvious uses).
"This is actually one of the problems at least for me. Single quote or
tick is often used as a plural such as "This is Bob's Car". '
Interestingly enough, one of my utility routines expands the single quotes
in a string to two single quotes (if it isn't already part of a pair) and I
use it inside of "QuotedStr(<string object>)". Of course this doesn't
address your problems when you are writing literals into your code . . .
but then I also find being accustomed to using single quotes causes me less
problems when I am writing SQL.
"Once you get used to it, no big deal but why should we have to get used to
it?"
So, you would have everyone get used to the quirks and foibles of VB.net or
Whatever.net rather than, for example, those of Delphi?
Sorry, I finally forced myself to complete a couple of projects using VB
and then returned to my weapon of choice, Delphi. I have written in a wide
variety of languages on everything from mainframes to mini's to PC's and
even down to 4-bit micros. I do not agree with the concept of trying to
create a language that is completely and totaly platform independent . . .
that was don with P-Code over 30 years ago and it didn't work any better
then than it does now. Jave was a noble effort at that concept but it was
"adjusted" for "improved performance" on WinTel boxes by Microsoft and it
never really recovered . . . and it was slow to begin with. I've been in
this profession for over 35 years and I have yet to see performance in the
way of speed of development, speed of execution, tightness of code, and
over all utility that compares to well written (notice, I did not say
"expertly written") Delphi code.
However, be that as it may, since this is a DELPHI discussion list, other
than wanting to bad mouth Delphi and try to convert the world to
whatever.net, I kid of wonder why you are hanging around. You obviously
don't like or want to code in Delphi.
Respectfully,
Ralph D. Wilson II Web
Site: <http:thewizardsguild.com>
Systems
Analyst Email:
<[EMAIL PROTECTED]>
San Antonio, TX 78259 Alt Email: <[EMAIL PROTECTED]>
H: (210) 497-2643
M: (210) 387-7744
"Any sufficiently advanced technology is indistinguishable from
magic." A.C.Clark
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
