Board index » delphi » OOP isn't so hard

OOP isn't so hard

Quote
<David Clegg> wrote in message news:3e6fdea5@newsgroups.borland.com...
> It won't blow up

It WILL blow up without a doubt.

Result := TJob(FJobList[0]).GetJobName();

will raise "item 0 out of bounds" or something like that

 

Re:OOP isn't so hard


Quote
"Adrian Gallero" <agall...@netscape.net> wrote in message

news:3e707e62$1@newsgroups.borland.com...

Quote
> But the idea is still valid. Even when you have one if, it is not inside
> the loop... And  in others languages not delphi, delete() might crash on
> an invalid string position,so you might need an if on the original
> version too.

Yes but that ends up being the same amount of code as deleting the last
char.
I gotta give you that your implementation is faster anyways, so I will
probabily start using it.

Quote
> for the record, the final code would be:

>     if FJobList.Count>0 then Result := TJob(FJobList[0]).GetJobName()
> else Result='';
>     for i := 1 to FJobList.Count-1 do
>          Result := Result + ',' + FJobList[i].GetJobName;

This is better:

    if (FJobList.Count>0) then begiin
       Result := TJob(FJobList[0]).GetJobName()
       for i := 1 to FJobList.Count-1 do
         Result := Result + ',' + FJobList[i].GetJobName;
    end
   else Result='';

It saves an operation (starting the loop and finding out 1 is > that the
list count)

Re:OOP isn't so hard


Quote
Mike Orriss (TeamB) wrote:
>>if not FileExists () then <-- Drives me crazy.

>>I like
>>   if (FileExist() = false) then <-- I like this better.

> I much prefer the first.

The problem with the first statement, you need to think whether the
FileExists returns true or false, then perfrom the 'not' operation, then
you can decide whether the if statements will be executed or not.

With the second sentence, you immediately can see, if the return value
of the function is false, then execute the statements under if.

Wien.

Re:OOP isn't so hard


Quote
Kristofer Skaug wrote:

> Perhaps the solution to your above dilemma ("if not FileExists" being
> ugly language) would be to invent a new function called "doesn't" or
> somesuch. <g> How about these?
> -> if Doesnt(FileExists()) then // Doesnt() function
> -> if IsFalse(FileExists()) then // IsFalse function, same as Doesnt
> -> if FileAbsent() then   // not-FileExists function
> etc.

See my reply to Mike.  The problem that I had with those statements, are
usually when the you want to handle when the function returns false.

if not FileAbsent () then

compared with

if FileAbsent() = false then

After a while, I found 'not' is kind of hard to read, especially when
you have little bit more complex boolean statement, when debugging, you
have to keep in mind what is the return value, perform the not
operation, keep the value if your brain and do complex boolean evaluation.

Your example, FileAbsent is really good function name, but IsFalse
returns true when false.

Wien.

Re:OOP isn't so hard


Quote
Kristofer Skaug wrote:

> I profiled it using Zprof and found it, on the average, twice as slow (on
> my P4/1700) as:

Interesting, thanks.  :)  I want to know why is that.  Probably I should
use some assembly.  I got this from back the old DOS days, with Turbo
Pascal, doing some graphic programming.  Lots of fun.

Wien.

Re:OOP isn't so hard


Quote
"Erwien Saputra" <erw...@nospam.codeline.dot.net> wrote in message

news:3E709370.9000809@nospam.codeline.dot.net...

Quote
> Mike Orriss (TeamB) wrote:
> >>if not FileExists () then <-- Drives me crazy.

> >>I like
> >>   if (FileExist() = false) then <-- I like this better.

> > I much prefer the first.

> The problem with the first statement, you need to think whether the
> FileExists returns true or false, then perfrom the 'not' operation, then
> you can decide whether the if statements will be executed or not.

> With the second sentence, you immediately can see, if the return value
> of the function is false, then execute the statements under if.

unit uExtendedFileUtils;

...

function FileDoesNotExist(...): boolean;

end.

if FileDoesNotExist(...) then
   ...

No thinking involved for day to day use.

John

Re:OOP isn't so hard


Quote
On Thu, 13 Mar 2003 06:19:28 -0800, Erwien Saputra wrote:
> The problem with the first statement, you need to think whether the
> FileExists returns true or false, then perfrom the 'not' operation, then
> you can decide whether the if statements will be executed or not.

Maybe logic is built into programmers' heads ;)
I much prefer the first statement as well, IMHO its closer to natural language,
I don't say:
  If "it rains" is false, then take an umbrella,
but
  If it doesn't rain, then take an umbrella

:-)
Anyway, to each his own (though, comparing to "true" is definitely
dangerous, at least with C/C++ APIs)

johannes

Re:OOP isn't so hard


Quote
Johannes Berg wrote:

> Maybe logic is built into programmers' heads ;)

I don't have that part installed in my brain, I guess... :)

Quote
> I much prefer the first statement as well, IMHO its closer to natural language,
> :-)

Which language?  <G>

Quote
> Anyway, to each his own (though, comparing to "true" is definitely
> dangerous, at least with C/C++ APIs)

Yes.  I am getting use to the explicit boolean comparison (or whatever
you call it) when worked to conform with the coding standard, and I like it.

Wien.

Re:OOP isn't so hard


Quote
On Thu, 13 Mar 2003 06:57:18 -0800, Erwien Saputra wrote:
>> Maybe logic is built into programmers' heads ;)

> I don't have that part installed in my brain, I guess... :)

Maybe its just because I study maths :-)

Quote
>> I much prefer the first statement as well, IMHO its closer to natural language,
>> :-)

> Which language?  <G>

You win here <G>
Dunno, it feels more natural to me anyway.

johannes

Re:OOP isn't so hard


Quote
> > Why would I want my Delphi code to be language nuetral?

> Because the thread is about OOP ;-))
> Plus I wanted to say that <G>

And that's why you used a Set type? <g>

--
Brian Moelk
bmo...@NObrainendeavorSPAM.FORcomME
http://www.brainendeavor.com

Re:OOP isn't so hard


"Erwien Saputra" <erw...@nospam.codeline.dot.net> wrote

Quote
> Josh P. wrote:
> > Thank you! Comparing booleans to constants bugs me. Where to stop?

> > If ((X=False)=True)=False ...
> That is ugly.  But the ugliness is not in the boolean, it is in the
writing.

> After using boolean comparison for a while, I like it better for example

>    if not FileExists () then <-- Drives me crazy.

> I like
>    if (FileExist() = false) then <-- I like this better.

Beg to differ. I don't mind placing extra paranthesis

Not(FileExists(A))

for clarity but that's as far as I'll go.

(FileExists(A) = False) Or (FileExists(B))

looks very clumsy to me and is no clearer than

(Not FileExists(A)) Or (FileExists(B))

Maybe a new language syntax is in order where the compiler will search for
the substring "NOT" in function calls and negate the result automagically :)
This will instantly double the number of boolean functions in your libraries
too!

Function AIsSmallerThanB(A,B:Integer):Boolean;
Begin
  Result:=A<B;
End;

Usage:

  AIsSmallerThanB(10,11);
  AIsNotSmallerThanB(10,11);

Re:OOP isn't so hard


Quote
> I like
>    if (FileExist() = false) then <-- I like this better.

FWIW, I prefer this form as well.

And so we can all appreciate all of Delphi's forms, in C++ you'll see this:

if (!FileExist())
{

Quote
}

which I find very hard to spot the bang.  And in other cases you'll see
stuff like:

if (false == FileExist())
{

Quote
}

as C++ allows you to assign in the expression of the "if".  Therefore it's
best to put the constant as the LHS as mistyping the logical double ='s is
easy to do.  Ahh...how I love Delphi.

--
Brian Moelk
bmo...@NObrainendeavorSPAM.FORcomME
http://www.brainendeavor.com

Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

Other Threads