Re: Strong parameter checking

[MB Software Solutions]

Stephen the Cook wrote:


dDate = dDate +1

dDate = dDate.AddDays(1);
 

A simple function: 


FUNCTION AddDays(tdDate as Date, tiNumDays as Integer) as Date
 * parameter checking goes here of course (but omitted for this email 
example)

   return tdDate + tiNumDays
ENDFUNC


So it is more verbose, in that you have to define what your adding to the
object.
But you do get more out of it.


dDate = dDate.AddMonths(2);
dDate = dDate.AddYears(1);
 


and likewise:

FUNCTION AddMonths(tdDate as Date, tiNumMonths as Integer) as Date
 * parameter checking goes here of course (but omitted for this email 
example)

   return GOMONTHS(tdDate,tiNumMonths)
ENDFUNC

FUNCTION AddYears(tdDate as Date, tiNumYears as Integer) as Date
 * parameter checking goes here of course (but omitted for this email 
example)

   return GOMONTHS(tdDate,tiNumYears*12)
ENDFUNC


.a couple more lines, but no big deal!

--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

David Crooks wrote:


On Tuesday, June 27, 2006 10:56 AM Michael Babcock wrote:

 


Is that like VFP's Code References option in the IDE?  That's one of my
   

favorite 
 


features so that I can quickly locate all instances of certain code
   


strings.

I like the tool as well, but do not think it is that quick.
 



Close your debugging Window and it flies (otherwise, yeah, it's slow).

--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking (Kevin Cully)

[MB Software Solutions]

Kevin Cully wrote:

I try to work with a n-tier design.  My example really was an over 
simplification of what I normally do.


Most of my development, I'll have a THIS.SetError() method that sets 
the error flag, and message.  It'll be up to the UI layer to decide 
what to do with the error at hand.



That's exactly what I do too, Kevin!


--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Stephen the Cook]

Dominic Burford <> wrote:
> <<
> I must say that for large projects involving multiple developers and
> changing requirements, strong, static typing speeds things up, simply
> because refactoring is so much easier to do.  
>>> 
> 
> I'm curious to find out how.  I would have thought a strongly typed
> language would have been *more* difficult to refactor, for the same
> rasons that it can take longer to develop using them i.e. they can
> prevent certain object interactions due to their enforcement of data
> types, and thus leads to additional code being written which conforms
> to these constraints. 

I work in a strongly typed language and find this totally FALSE.  It is
easier to refactor in C# /VS2005 then any other IDE I have worked in.  In
VS2003 it took a little more time.  Just hit Build and it would find all the
parts missed in a single refactor of a method used all over your app.

Now "thus leads to additional code being written which conforms to these
constraints."  OK this is a valid POV from a VFP person who says I just need
to add a day to my date.

dDate = dDate +1

dDate = dDate.AddDays(1);

So it is more verbose, in that you have to define what your adding to the
object.
But you do get more out of it.

dDate = dDate.AddMonths(2);
dDate = dDate.AddYears(1);


Stephen Russell
DBA / Operations Developer

Memphis TN 38115
901.246-0159

http://spaces.msn.com/members/srussell/

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/377 - Release Date: 6/27/2006
 



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Eyvind Axelsen]

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Dominic Burford
Sendt: 28. juni 2006 14:04
Til: ProFox Email List
Emne: RE: Strong parameter checking

< I'm curious to find out how.  I would have thought a strongly typed language 
would have been *more* difficult to refactor, for the same rasons that it can 
take longer to develop using them i.e. they can prevent certain object 
interactions due to their enforcement of data types, and thus leads to 
additional code being written which conforms to these constraints. >

True, but on the other hand, if you change, say, a method signature, a compiler 
can spot every place in which a change is needed. Furthermore, if you change 
the name of a function or class member or the order in which parameters are 
sent to a function, a tool such as VS can do the refactoring for you 
automatically.

Still, I guess the answer to the question of development speed and 
strong/static vs weak typing is: "it depends" =)

Eyvind.


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

<<
I must say that for large projects involving multiple developers and changing 
requirements, strong, static typing speeds things up, simply because 
refactoring is so much easier to do.
>>

I'm curious to find out how.  I would have thought a strongly typed language 
would have been *more* difficult to refactor, for the same rasons that it can 
take longer to develop using them i.e. they can prevent certain object 
interactions due to their enforcement of data types, and thus leads to 
additional code being written which conforms to these constraints.

<<
Furthermore, IMO, static (as opposed to just strong) typing is very valuable 
for intellisense, which is able to provide a lot more info in than in a 
language with weak/dynamic typing, and this alone can speed up development 
considerably.
>>

I agree, but I don't think this was ever under dispute, as the article 
concentrated solely on strong typing. 

Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
* [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design: One way 
is to make it so simple there are obviously no deficiencies, and the other way 
is to make it so complicated that there are no obvious deficiencies." -- Tony 
Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyvind Axelsen
Sent: 28 June 2006 12:27
To: ProFox Email List
Subject: Re: Strong parameter checking

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Dominic Burford



I would say that this is highly dependant on the type of application that you 
are making. I have worked with both weakly and strongly typed languages, and I 
must say that for large projects involving multiple developers and changing 
requirements, strong, static typing speeds things up, simply because 
refactoring is so much easier to do.

Furthermore, IMO, static (as opposed to just strong) typing is very valuable 
for intellisense, which is able to provide a lot more info in than in a 
language with weak/dynamic typing, and this alone can speed up development 
considerably.

Eyvind


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Eyvind Axelsen]

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Dominic Burford



I would say that this is highly dependant on the type of application that you 
are making. I have worked with both weakly and strongly typed languages, and I 
must say that for large projects involving multiple developers and changing 
requirements, strong, static typing speeds things up, simply because 
refactoring is so much easier to do.

Furthermore, IMO, static (as opposed to just strong) typing is very valuable 
for intellisense, which is able to provide a lot more info in than in a 
language with weak/dynamic typing, and this alone can speed up development 
considerably.

Eyvind


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

<< The two are not mutually exclusive, and why have only one when you can have 
both?

No they are not, and the article did not state that either.  It was making the 
point that strongly typed languages can lead to more inflexible implementations 
compared to a weaker typed language.  It was also making the point that a 
criticism that is often levelled at weakly types languages is that they are 
more likely to lead to run-time errors related to their impementation.  
However, this criticism can be discarded with a greater emphasis on testing.  
And there is likely to be more time available for testing due to the quicker 
development times that weakly types languages are capable of.

Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
* [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design: One way 
is to make it so simple there are obviously no deficiencies, and the other way 
is to make it so complicated that there are no obvious deficiencies." -- Tony 
Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyvind Axelsen
Sent: 28 June 2006 09:11
To: [EMAIL PROTECTED]
Subject: Re: Strong parameter checking

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Ed Leafe

< As Bruce Eckel stated, strong testing, not strong typing. >

The two are not mutually exclusive, and why have only one when you can have 
both?

The compiler does not lead to a "false" feeling of security, because we as 
professional developers understand what sort of errors the compiler can catch, 
and we can develop appropriate (unit) tests for the rest. 

Eyvind.


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.



__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Eyvind Axelsen]

-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Ed Leafe

< As Bruce Eckel stated, strong testing, not strong typing. >

The two are not mutually exclusive, and why have only one when you can have 
both?

The compiler does not lead to a "false" feeling of security, because we as 
professional developers understand what sort of errors the compiler can catch, 
and we can develop appropriate (unit) tests for the rest. 

Eyvind.


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: MB Software Solutions <[EMAIL PROTECTED]>
> Date: Tue, June 27, 2006 7:56 am
> To: profox@leafe.com
> 
> [EMAIL PROTECTED] wrote:
> 
> >Overloading?  
> >
> >Like this:
> >
> >void setanswer(String answer){ 
> >}
> >
> >void setanswer(String answer, String title){ 
> >}
> >
> >or This?
> >
> >void setanswer(String answer){ 
> >}
> >
> >void setanswer(String title){ 
> >}
> >
> >  
> >
> 
> Isn't this last example invalid, because both are string parms?  
> Overloading is great when the parms differ.  I don't know how the 
> compiler would be able to tell in your last example which 
> function/procedure to call since both are the same type?

Yes your compiler will throw that as an error in a build, actually you
will see it in red squiggly as your trying to create it.

 



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: MB Software Solutions <[EMAIL PROTECTED]>
> 
> [EMAIL PROTECTED] wrote:
> 
> >Is that a problem for you?  So sorry.  I just go and do a refactor for
> >it, and I am presented with all the occurrences.  VS2005 is really
> >great in adding that.  :)
> >
> >  
> >
> 
> Is that like VFP's Code References option in the IDE?  That's one of my 
> favorite features so that I can quickly locate all instances of certain 
> code strings.

Not sure?  VS2005 Refactor is now it's own menu, so I'm just guessing
here that the VFP9 code references is not near as robust.  



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 27, 2006, at 10:56 AM, MB Software Solutions wrote:

Or when you can add the same named function several times,  
each with  a different parameter signature! Compilers have no  
problem with that!


"Overloading" is what you're describing, right?  I liked doing that  
in PL/SQL programming.


	The point is that the compiler isn't telling you anything once you  
overload it with various possible parameter signatures for a method.  
As far as the compiler is concerned, what you passed is one of the  
possibilities that it accepts, so it is happy, but meanwhile you are  
executing code that is wrong. This is where there is a false sense of  
security created by compile-time checking. As Bruce Eckel stated,  
strong testing, not strong typing.


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[David Crooks]

On Tuesday, June 27, 2006 10:56 AM Michael Babcock wrote:

>Is that like VFP's Code References option in the IDE?  That's one of my
favorite 
>features so that I can quickly locate all instances of certain code
strings.

I like the tool as well, but do not think it is that quick.

David L. Crooks



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

Ed Leafe wrote:


On Jun 26, 2006, at 10:52 AM, [EMAIL PROTECTED] wrote:


Indeed! Especially when you after having used the function/method in
quite a few places need to refactor the damn thing, and change, say,
parameter types...



Is that a problem for you?  So sorry.  I just go and do a refactor for
it, and I am presented with all the occurrences.  VS2005 is really
great in adding that.  :)



Or when you can add the same named function several times, each 
with  a different parameter signature! Compilers have no problem with 
that!



"Overloading" is what you're describing, right?  I liked doing that in 
PL/SQL programming.


--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

[EMAIL PROTECTED] wrote:

Overloading?  


Like this:

void setanswer(String answer){ 
   }


void setanswer(String answer, String title){ 
   }


or This?

void setanswer(String answer){ 
   }


void setanswer(String title){ 
   }


 



Isn't this last example invalid, because both are string parms?  
Overloading is great when the parms differ.  I don't know how the 
compiler would be able to tell in your last example which 
function/procedure to call since both are the same type?


--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

[EMAIL PROTECTED] wrote:


Is that a problem for you?  So sorry.  I just go and do a refactor for
it, and I am presented with all the occurrences.  VS2005 is really
great in adding that.  :)

 



Is that like VFP's Code References option in the IDE?  That's one of my 
favorite features so that I can quickly locate all instances of certain 
code strings.


--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking (Kevin Cully)

[Ed Leafe]

On Jun 27, 2006, at 9:59 AM, Michael Hawksworth wrote:

I don't agree, if you catch error within your code you can code to  
allow one exit.


	*IF* you catch it in the same block as it was raised. But most  
designs don't limit themselves to something like that. For example,  
Dabo's dForm.requery() method looks like:


try:
self.PrimaryBizobj.requery()
except dException.NoRecordsException:
self.StatusBarText = "No records returned"
except dException.ConnectionClosedException:
dabo.ui.stop("Connection to the database was lost")
...

	The form doesn't care where those exceptions were raised; in fact,  
they are raised several levels down in the code that actually  
executes the database query. But the beauty of raising exceptions  
like this is that they are not limited to returning only one level up  
the call stack; they percolate up to the appropriate handler, where  
they can be processed (and re-raised if needed). You don't bracket  
all your code at every level; only the places where the exception  
handling occurs needs to have code present


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking (Kevin Cully)

[stephen . russell]

> From: Michael Hawksworth <[EMAIL PROTECTED]>
> Date: Tue, June 27, 2006 6:59 am
> To: profox@leafe.com
>
> I don't agree, if you catch error within your code you can code to allow
> one exit.
>
> The code will be c**p, but you can have one exit.  This is one argument
> for having GOTO. You set the error condition and jump to the exit code.

This is why Try Catch Finally is good.

It just seems like a lot of repeat code for EVERY method in your app
with a param associated.



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking (Kevin Cully)

[Michael Hawksworth]

I don't agree, if you catch error within your code you can code to allow 
one exit.


The code will be c**p, but you can have one exit.  This is one argument 
for having GOTO. You set the error condition and jump to the exit code.


--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Michael Hawksworth]

"Unexpected Critical error, please contact the IT department"  being my 
favourite meaningful message.  Usually it has '&& TODO:Sort out proper 
message' in the code next to it ;)


--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

<< I often recommend messages should be extremely clear.

Hi Mike

The code I posted was for example purposes only.  In a real life
application, I would insert more meaningful error messages.

Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
* [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design:
One way is to make it so simple there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies." -- Tony Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Mike yearwood
Sent: 27 June 2006 14:21
To: profox@leafe.com
Subject: RE: Strong parameter checking

Hi Dominic

> << The single vs multiple point of exit argument has been going on for

> years, made more intense by the arrival of the newer development 
> theories.
>
> I find that the DO CASE...ENDCASE construct does away with such
worries.
> You check for all the parameters and initial validation first in the 
> DO CASE tests, then the OTHERWISE section contains the heart of the 
> code where you know that everyting is OK.
>
> To the person who said that this construct cannot pass back meaningful

> error information, it can, as I have demonstrated below.  If an empty 
> string is returned, everything is OK, otherwise an error message is 
> returned
>
> Function MyFunction (tcSomething)
> Local lcErrorMsg
> lcErrorMsg = ""
> Do Case
>Case Pcount() <> 1
>lcErrorMsg = "No parameters passed"
>Case IsNull(tcSomething)
>lcErrorMsg = "Parameter is Null"
>Case Not (Vartype(tcSomething) = "C")
>lcErrorMsg = "Parameter is of incorrect data type"
>Otherwise
>*-- Everything is OK
> EndCase
>
> Return lcErrorMsg

I will begin using the do case instead of multiple ifs. Thanks for that.
May I suggest a slight modification to your code?

Case Pcount() = 0
   lcErrorMsg = "No parameters passed"
Case Pcount() <> 1
  lcErrorMsg = "Incorrect number of parameters passed"

I often recommend messages should be extremely clear. A message that
says "Your network card has melted or your hard drive has buried it's
heads in the platters" just doesn't help me find the real problem. ;)


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list:
http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of
the author, and do not constitute legal or medical advice. This
statement is added to the messages for those lawyers who are too stupid
to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking (Kevin Cully)

[Ed Leafe]

On Jun 27, 2006, at 9:19 AM, Kevin Cully wrote:


I've forgotten about the ERROR call though.  Thanks!


	The whole Try/Catch model breaks the "one exit" design. Errors  
immediately return, whether explicitly raised or not.


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking (Kevin Cully)

[Kevin Cully]

I try to work with a n-tier design.  My example really was an over 
simplification of what I normally do.


Most of my development, I'll have a THIS.SetError() method that sets the 
error flag, and message.  It'll be up to the UI layer to decide what to 
do with the error at hand.


I've forgotten about the ERROR call though.  Thanks!

Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!
http://foxforward.net


Mike yearwood wrote:

Hi Kevin

I forgot to mention one thing. IMO the routine should not trigger a
message box when things fail. It should return the message or invoke a
common message display routine so you have a place to augment message
delivery. Decouple the messaging from the routine. Return the message,
but don't display it.

One thing Tamar Granor showed me was to ...

IF something's wrong
 ERROR more appropriate error message
ENDIF

This still let's you augment messaging via the error event or error 
handler.


Mike
 > Message: 4


Date: Mon, 26 Jun 2006 08:11:23 -0400
From: Kevin Cully <[EMAIL PROTECTED]>
Subject: Strong parameter checking
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
   LOCAL lcRetVal
   lcRetVal = []
   IF PCOUNT() = 1
  IF NOT ISNULL(tcSomething)
 IF VARTYPE(tcSomething) = "C"
IF NOT EMPTY(tcSomething)
   lcRetVal = [My Function ] + tcSomething
ENDIF
 ENDIF
  ENDIF
   ENDIF
   IF EMPTY(lcRetVal)
  =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
"  Try again."
   ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

--





[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Mike yearwood]

Hi Dominic


<< The single vs multiple point of exit argument has been going on for
years, made more intense by the arrival of the newer development
theories.

I find that the DO CASE...ENDCASE construct does away with such worries.
You check for all the parameters and initial validation first in the DO
CASE tests, then the OTHERWISE section contains the heart of the code
where you know that everyting is OK.

To the person who said that this construct cannot pass back meaningful
error information, it can, as I have demonstrated below.  If an empty
string is returned, everything is OK, otherwise an error message is
returned

Function MyFunction (tcSomething)
Local lcErrorMsg
lcErrorMsg = ""
Do Case
   Case Pcount() <> 1
   lcErrorMsg = "No parameters passed"
   Case IsNull(tcSomething)
   lcErrorMsg = "Parameter is Null"
   Case Not (Vartype(tcSomething) = "C")
   lcErrorMsg = "Parameter is of incorrect data type"
   Otherwise
   *-- Everything is OK
EndCase

Return lcErrorMsg


I will begin using the do case instead of multiple ifs. Thanks for
that. May I suggest a slight modification to your code?

Case Pcount() = 0
  lcErrorMsg = "No parameters passed"
Case Pcount() <> 1
 lcErrorMsg = "Incorrect number of parameters passed"

I often recommend messages should be extremely clear. A message that
says "Your network card has melted or your hard drive has buried it's
heads in the platters" just doesn't help me find the real problem. ;)


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Strong parameter checking (Kevin Cully)

[Mike yearwood]

Hi Kevin

I forgot to mention one thing. IMO the routine should not trigger a
message box when things fail. It should return the message or invoke a
common message display routine so you have a place to augment message
delivery. Decouple the messaging from the routine. Return the message,
but don't display it.

One thing Tamar Granor showed me was to ...

IF something's wrong
 ERROR more appropriate error message
ENDIF

This still let's you augment messaging via the error event or error handler.

Mike
> Message: 4

Date: Mon, 26 Jun 2006 08:11:23 -0400
From: Kevin Cully <[EMAIL PROTECTED]>
Subject: Strong parameter checking
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
   LOCAL lcRetVal
   lcRetVal = []
   IF PCOUNT() = 1
  IF NOT ISNULL(tcSomething)
 IF VARTYPE(tcSomething) = "C"
IF NOT EMPTY(tcSomething)
   lcRetVal = [My Function ] + tcSomething
ENDIF
 ENDIF
  ENDIF
   ENDIF
   IF EMPTY(lcRetVal)
  =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
"  Try again."
   ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

--



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

A good article.  I particularly liked the emphasis on testing your code,
rather than assuming the the compilation process has done this.

The following adage makes a lot of sense: 'Strong testing, not strong
typing.'

Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
* [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design:
One way is to make it so simple there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies." -- Tony Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Leafe
Sent: 26 June 2006 18:10
To: ProFox Email List
Subject: Re: Strong parameter checking

On Jun 26, 2006, at 12:45 PM, [EMAIL PROTECTED] wrote:

> I don't agree with you on this, at least in .NET terms.  Intellisence 
> pops up to allow you to see all the overloads of setanswer(), you can 
> step through them and they report what your passing.

So with Intellisense telling you what to pass, you still need a
compiler to catch bad data types??

I agree with Bruce Eckel on the value of Strong Testing vs.
Strong
Typing:

<http://www.mindview.net/WebLog/log-0025>


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list:
http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of
the author, and do not constitute legal or medical advice. This
statement is added to the messages for those lawyers who are too stupid
to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Alan Bourke]

I think there's a point you reach where checking things at the top and
bailing out as needed is vastly better and more debuggable and more
readable than 25 nested IF's put in there to just achieve a single exit.

And what about multithreaded code?
-- 
  Alan Bourke
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - A fast, anti-spam email service.



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 27, 2006, at 3:11 AM, Michael Hawksworth wrote:

The single vs multiple point of exit argument has been going on for  
years, made more intense by the arrival of the newer development  
theories.


	That arose in the days of 'top-down' programming, which was all the  
rage when I was in college. When you wrote your code, you created  
pseudo-code where you defined your procedures and their return  
values, and then you fleshed out the actual code that produced those  
return values. Probably the biggest reason for insisting on the "one  
entry, one exit" style was the prevalence then of GOTO, which was  
abused terribly; this style was a reaction to that 'anything goes'  
style and its spaghetti code results.


	Personally, I think that what's important is predictable, readable  
code. The one exit style is just an attempt at achieving this. But  
having a style that checks for conditions at the top of a procedure  
and exits if they are not met is a very clear, readable and  
maintainable style. In fact, most main methods in Dabo follow the  
pattern I added to Codebook methods:


def doSomething(self):
errorCode = self.beforeDoSomething()
if errorCode:
return errorCode

self.afterDoSomething()
return resultCode

	IOW, every X method has a built-in test: beforeX(), and returning an  
error code from that will prevent the rest of the method from  
running. Sure, I could have structured it with only one return, but I  
don't believe that the code would be better or more readable if I did./


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Michael Hawksworth]

::Slaps head::

I have used Case statements for testing multiple conditions for years 
and never thought of using it as a case statement, which is why I don't 
(didn't) like case for parameter testing.  What a Muppet am I.


To go back to the comments about engineering code, it just shows how you 
get blinkered until someone shows you are wrong.


Cheers Dominic.

--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

<< The single vs multiple point of exit argument has been going on for
years, made more intense by the arrival of the newer development
theories.

I find that the DO CASE...ENDCASE construct does away with such worries.
You check for all the parameters and initial validation first in the DO
CASE tests, then the OTHERWISE section contains the heart of the code
where you know that everyting is OK.  

To the person who said that this construct cannot pass back meaningful
error information, it can, as I have demonstrated below.  If an empty
string is returned, everything is OK, otherwise an error message is
returned

Function MyFunction (tcSomething)
Local lcErrorMsg
lcErrorMsg = ""
Do Case
Case Pcount() <> 1
lcErrorMsg = "No parameters passed"
Case IsNull(tcSomething)
lcErrorMsg = "Parameter is Null"
Case Not (Vartype(tcSomething) = "C")
lcErrorMsg = "Parameter is of incorrect data type"
Otherwise   
*-- Everything is OK
EndCase

Return lcErrorMsg


Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
*   [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design:
One way is to make it so simple there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies." -- Tony Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Hawksworth
Sent: 27 June 2006 08:12
To: profox@leafe.com
Subject: Re: Strong parameter checking

The single vs multiple point of exit argument has been going on for
years, made more intense by the arrival of the newer development
theories.

Personally I can't decide.  I think it foolish to not to exit at the top
of a procedure if some major item is missing (that business object you
need hasn't loaded) but I can see the benefit of single exist points for
the main code.

So overall I use single exit point in my main code but allow multiple
exit points in the set-up/checking code.

Erm, that would be 'multiple, single point returns'.  I think I'll write
a book about about it... ;)

--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list:
http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of
the author, and do not constitute legal or medical advice. This
statement is added to the messages for those lawyers who are too stupid
to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Michael Hawksworth]

The single vs multiple point of exit argument has been going on for 
years, made more intense by the arrival of the newer development theories.


Personally I can't decide.  I think it foolish to not to exit at the top 
of a procedure if some major item is missing (that business object you 
need hasn't loaded) but I can see the benefit of single exist points for 
the main code.


So overall I use single exit point in my main code but allow multiple 
exit points in the set-up/checking code.


Erm, that would be 'multiple, single point returns'.  I think I'll write 
a book about about it... ;)


--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Mike yearwood]

Hi Kevin


Message: 2
Date: Mon, 26 Jun 2006 10:01:21 -0400
From: Kevin Cully <[EMAIL PROTECTED]>
Subject: Re: Strong parameter checking
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I would guess that it's a matter of preference but I never like to
RETURN in the middle of a function.  I think keeping this philosophy
forces modularity and keeps my functions small which hopefully increases
their re-use.  With smaller (shorter) functions, it also keeps the
indentation to a minimum.  Yes, I do end up with many more
methods/functions though.

The way you combined the commands, you've already decreased the number
of indentations compared to the way that I wrote it out, which is a
plus.  Dominic's CASE .. ENDCASE decreases the indentation levels as well.

Thanks.



I've started to think personal preference is too valued. Engineering
should be more important. Standards should be more important. In other
words, you show me a good reason to do something and I'll drop my
"personal preference" in a flash.

I'm returning from the beginning of the function, not the middle. ;)
However, using objects that remember settings, you can safely exit
almost anywhere. The objects will restore settings when they are
destroyed. If it's safe and allows me to have the meat of the function
clearly delineated and uncluttered, then that outweighs
habits/traditions/personal preference.

I too have lots of tiny functions. That's what increases their reuse,
regardless of where you return from the function. Those issues are not
causally related. Size depends on the task. The bigger functions often
reuse the little ones. This is the way the universe is organized.

HTH


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: Ed Leafe <[EMAIL PROTECTED]>

>   So with Intellisense telling you what to pass, you still need a  
> compiler to catch bad data types??

Only when I'm patching older VB.NET stuff that was just copy paste to
begin with.  ;->




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Bill Arnold]

In terms of 'tightly coupled' vs 'loosely coupled' (to use old terms)
code, we're now more inclined towards passing parameters to modules
versus having modules be aware of their environment. That's a good
thing, but it increases the number of parameters being passed around,
which could - if the caller is not to be trusted - have the effect of
requiring considerable code to inspect parameters in each called method.


In any case, my own practice is have some checking of parameters (e.g.
pcount), but mostly to aid developers from making mistakes, not to
thwart intentional misuse. From that side of the coin, I'd look to
global resource protection mechanics and not even think about trying to
make every module "secure".


Bill




> > I'm working on a class that I'm wanting to make Open Source and I'm 
> > making functions/methods that take parameters.  This 
> function could be 
> > abused in ways that I have never anticipated.  Since VFP is loosely 
> > typed, I'm wondering what checking I have to do on these 
> parameters to 
> > make sure that the parameter is provided, not .NULL. and of 
> the type 
> > expected?  Is this overkill?
> >
> > FUNCTION MyFunction(tcSomething AS String) AS String
> >LOCAL lcRetVal
> >lcRetVal = []
> >IF PCOUNT() = 1
> >   IF NOT ISNULL(tcSomething)
> >  IF VARTYPE(tcSomething) = "C"
> > IF NOT EMPTY(tcSomething)
> >lcRetVal = [My Function ] + tcSomething
> > ENDIF
> >  ENDIF
> >   ENDIF
> >ENDIF
> >IF EMPTY(lcRetVal)
> >   =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
> > "  Try again."
> >ENDIF
> > RETURN lcRetVal
> > ENDFUNC
> >
> > What's the most graceful way in VFP to accomplish this?  
> ASSERTS work 
> > in development but what about data driven production 
> systems?  There 
> > must be a better way that I'm unaware of.
> 
> Personally I find it easiest to check parameters first and 
> get out if necessary and then follow with the heart of the 
> function. This clearly separates the two steps and the meat 
> of the function is cleaner and easier to follow.
> 
> FUNCTION MyFunction(tcSomething AS String) AS String
>LOCAL lcRetVal
>lcRetVal = []
>IF PCOUNT() = 0 OR VARTYPE(tcSomething) # "C"
>  RETURN lcRetVal
>ENDIF
> 
>  *Now the real meat of the function is not tabbed way over 
> for nothing.
> 
> RETURN lcRetVal
> ENDFUNC
> 
> Mike
> 



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 1:34 PM, MB Software Solutions wrote:

default parameter values - which was done much better in Clipper  
<~g>


Which is done even better in Python!


Well don't just say that without an example!!  Otherwise, you're  
missing an opportunity to plug Dabo!!


	It's not a Dabo thing; it's just the way Python works. You can pass  
parameters by either position or by name, with named parameters  
preferred due to less ambiguity. Any parameter can accept a default  
value.


	You can also have 'catch-all' arguments that handle variable numbers  
of parameters. So, since you want an example, here goes:


def __init__(self, parent, properties=None, attProperties=None,
*args, **kwargs):

	This initialization method accepts two positional parameters that  
are required, since they have no default values: 'self' and 'parent'.  
'self' is by convention the name used in all instance methods,  
equivalent to VFP's 'This'. You can optionally pass the 'properties'  
and/or 'attProperties' parameters; if you don't, they are initialized  
with a value of None (VFP's .NULL.).


	The 'catch-all' parameters are '*args' and '**kwargs', which is the  
convention used for 'arguments' and 'key-word arguments'. If you pass  
any additional unnamed parameters, their values will be in a list  
(array) variable named 'args', and any additional named parameters  
will be in a dictionary named 'kwargs', with the name as the key and  
the value as the value. The asterisks are a shorthand for expanding  
lists and dictionaries, respectively.


	Why would anyone want to create methods with variable parameters?  
Well, in Dabo you can initialize a control with as many properties as  
you need. So I can create a button with:


btn = dabo.ui.dButton(mainPanel)

...which will create a standard button on the mainPanel object. Or, I  
can write:


btn = dabo.ui.dButton(mainPanel, Caption="Click Me!", Left=42)

...which will do the same, except now the text caption and the left  
edge will be set. If I later create a new property named 'Foo', and  
add it to all my classes, I don't have to go back and change all the  
initialization signatures for every class; I can just pass a Foo  
parameter, and thanks to Dabo's property introspection, it will set  
it without having to write additional code.


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

[EMAIL PROTECTED] wrote:


Personally I find it easier when the damn compiler throws the error
because you can't get your params correct.

YMMV.
 



A Visual Studio plug, right?  

--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[MB Software Solutions]

Ed Leafe wrote:


On Jun 26, 2006, at 8:55 AM, Andy Davies wrote:


There must be a better way that I'm unaware of.



default parameter values - which was done much better in Clipper <~g>



Which is done even better in Python!



Well don't just say that without an example!!  Otherwise, you're missing 
an opportunity to plug Dabo!!


--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 12:45 PM, [EMAIL PROTECTED] wrote:


I don't agree with you on this, at least in .NET terms.  Intellisence
pops up to allow you to see all the overloads of setanswer(), you can
step through them and they report what your passing.


	So with Intellisense telling you what to pass, you still need a  
compiler to catch bad data types??


	I agree with Bruce Eckel on the value of Strong Testing vs. Strong  
Typing:





-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: Ed Leafe <[EMAIL PROTECTED]>

>   Of course, the point was that this defeats the "advantage" of having
> the compiler do your type checking for you! You think that you're
> calling setanswer() with one thing, but you're actually calling
> another, completely different method, and the compiler will happily
> let you do so.

I don't agree with you on this, at least in .NET terms.  Intellisence
pops up to allow you to see all the overloads of setanswer(), you can
step through them and they report what your passing.

If your not familiar with the method just "Go to Definition" and
investigate from there.

In my experience of working with others code, this has never been a
confusing area at all.  Actually it's been straight forward with or
without documentation ;->





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 11:48 AM, [EMAIL PROTECTED] wrote:


But to overload setanswer 15 different ways is no problem, and when
necessary it's fantastic that you can!


	Of course, the point was that this defeats the "advantage" of having  
the compiler do your type checking for you! You think that you're  
calling setanswer() with one thing, but you're actually calling  
another, completely different method, and the compiler will happily  
let you do so.


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: Ed Leafe <[EMAIL PROTECTED]>

> > Overloading?
> >
> > Like this:
> >
> > void setanswer(String answer){
> > }
> >
> > void setanswer(String answer, String title){
> > }
> >
> > or This?
> >
> > void setanswer(String answer){
> > }
> >
> > void setanswer(String title){
> > }
>
>   Both. And also:
>
> void setanswer(String answer){
>  }
>
> void setanswer(Int style){
>  }

The only wrong answer was changing the param name.  You can do that in
VS, but only the bottom one is used?  I forget if it's the bottom or
the most recent addition that overrides the former one.  Anyway the
compiler ignores the dupe.  If your on your call to that method, you
can rt click it and go to the method itself and verify which one it's
hitting.

But to overload setanswer 15 different ways is no problem, and when
necessary it's fantastic that you can!

My data tier has 10+ overloads when dealing with SaveDataSet.  You pass
the ds, and it will save all tables, pass in a table name as well and
just that table's updates are saved.  Add a row param and just that
row.





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 11:15 AM, [EMAIL PROTECTED] wrote:


Overloading?

Like this:

void setanswer(String answer){
}

void setanswer(String answer, String title){
}

or This?

void setanswer(String answer){
}

void setanswer(String title){
}


Both. And also:

void setanswer(String answer){
}

void setanswer(Int style){
}

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: Ed Leafe <[EMAIL PROTECTED]>
>   Or when you can add the same named function several times, each with  
> a different parameter signature! Compilers have no problem with that!

Overloading?  

Like this:

void setanswer(String answer){ 
}

void setanswer(String answer, String title){ 
}

or This?

void setanswer(String answer){ 
}

void setanswer(String title){ 
}






___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Eyvind Axelsen]

>> Indeed! Especially when you after having used the function/method in
>> quite a few places need to refactor the damn thing, and change, say,
>> parameter types...
>
>Is that a problem for you?  So sorry.  I just go and do a refactor for
>it, and I am presented with all the occurrences.  VS2005 is really
>great in adding that.  :)

That's exactly what I meant - at times I _really_ hate VS 2005
(especially the [EMAIL PROTECTED]" designer), but the refactoring bit is 
brilliant
(and as good as impossible to implement in a dynamic language without
static type checking).

Eyvind.


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 10:52 AM, [EMAIL PROTECTED] wrote:


Indeed! Especially when you after having used the function/method in
quite a few places need to refactor the damn thing, and change, say,
parameter types...


Is that a problem for you?  So sorry.  I just go and do a refactor for
it, and I am presented with all the occurrences.  VS2005 is really
great in adding that.  :)


	Or when you can add the same named function several times, each with  
a different parameter signature! Compilers have no problem with that!


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Paul Hill]

On 6/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> From: "Mike yearwood" <[EMAIL PROTECTED]>

> Personally I find it easiest to check parameters first and get out if
> necessary and then follow with the heart of the function. This clearly
> separates the two steps and the meat of the function is cleaner and
> easier to follow.

Personally I find it easier when the damn compiler throws the error
because you can't get your params correct.

YMMV.


Fully agree!

I don't see why this wasn't done.  It would only apply where
parameters are defined as strong types.

Even VB6 does this!

--
Paul


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: "Eyvind Axelsen" <[EMAIL PROTECTED]>
> Date: Mon, June 26, 2006 7:46 am
> To: "ProFox Email List" 
>
> < Personally I find it easier when the damn compiler throws the error
> because you can't get your params correct. >
>
> Indeed! Especially when you after having used the function/method in
> quite a few places need to refactor the damn thing, and change, say,
> parameter types...

Is that a problem for you?  So sorry.  I just go and do a refactor for
it, and I am presented with all the occurrences.  VS2005 is really
great in adding that.  :)



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Eyvind Axelsen]

< Personally I find it easier when the damn compiler throws the error
because you can't get your params correct. >

Indeed! Especially when you after having used the function/method in
quite a few places need to refactor the damn thing, and change, say,
parameter types...

Eyvind.


[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Michael Hawksworth]

This is my standard procedure header (stripped of the documentation 
section that is geared towards HelpBuilder).





&& vfs[Form and or Proc Name]
&&
&& Created By :  Michael Hawksworth
&& Copyright  :  Visual Fox Solutions
&& Created On :  
<> 
[ or whatever works for you ]

&&
&& Description:
&&
&&---
&& Return Value:
&&---
&& Parameters:
&&---

Lparameters

&&-
&& Verify Parameters
&&-

&& Not required

&&
&& Declare Variables
&&


&&-
&& Initialise Variables
&&-

&&-
&& Code
&&-

--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Hal Kaplan]

I would do nothing ... No error checking ... Nothing.  If the user is so
impolite as to ignore the instructions for proper use, (s)he does not
deserve the courtesy of acknowledgement.  It's about time that we
started using functions in a gentrified manner.

On the other hand, you could check for errors and send an e-mail
notification to yourself advising of same.  Then contact the offender
and offer to repair his installation for a fat non-refundable fee. Then,
while making the repairs, inject some other low-level problem that will
necessitate a callback.  Prudent and imaginative use of this technique
could yield a vast array of emoluments, a la the auto repair industry.

HTH

HALinNY

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kevin Cully
Sent: Monday, June 26, 2006 08:11
To: profox@leafe.com
Subject: Strong parameter checking

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
LOCAL lcRetVal
lcRetVal = []
IF PCOUNT() = 1
   IF NOT ISNULL(tcSomething)
  IF VARTYPE(tcSomething) = "C"
 IF NOT EMPTY(tcSomething)
lcRetVal = [My Function ] + tcSomething
 ENDIF
  ENDIF
   ENDIF
ENDIF
IF EMPTY(lcRetVal)
   =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
 "  Try again."
ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

-- 

Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!



[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Steve Ellenoff]

This is the style I tend to use as well.. It's good knowing that once 
you scroll down past any initial validation code, your variables are 
assumed to be just fine, and I do like the logical division of having 
the validation section and then the heart of the logic section as 
outlined by Mike.


-Steve



FUNCTION MyFunction(tcSomething AS String) AS String
  LOCAL lcRetVal
  lcRetVal = []
  IF PCOUNT() = 0 OR VARTYPE(tcSomething) # "C"
RETURN lcRetVal
  ENDIF

*Now the real meat of the function is not tabbed way over for nothing.

RETURN lcRetVal
ENDFUNC

Mike



[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Kevin Cully]

I would guess that it's a matter of preference but I never like to 
RETURN in the middle of a function.  I think keeping this philosophy 
forces modularity and keeps my functions small which hopefully increases 
their re-use.  With smaller (shorter) functions, it also keeps the 
indentation to a minimum.  Yes, I do end up with many more 
methods/functions though.


The way you combined the commands, you've already decreased the number 
of indentations compared to the way that I wrote it out, which is a 
plus.  Dominic's CASE .. ENDCASE decreases the indentation levels as well.


Thanks.

Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!
http://foxforward.net


Mike yearwood wrote:

Personally I find it easiest to check parameters first and get out if
necessary and then follow with the heart of the function. This clearly
separates the two steps and the meat of the function is cleaner and
easier to follow.

FUNCTION MyFunction(tcSomething AS String) AS String
  LOCAL lcRetVal
  lcRetVal = []
  IF PCOUNT() = 0 OR VARTYPE(tcSomething) # "C"
RETURN lcRetVal
  ENDIF

*Now the real meat of the function is not tabbed way over for nothing.

RETURN lcRetVal
ENDFUNC




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[stephen . russell]

> From: "Mike yearwood" <[EMAIL PROTECTED]>

> Personally I find it easiest to check parameters first and get out if
> necessary and then follow with the heart of the function. This clearly
> separates the two steps and the meat of the function is cleaner and
> easier to follow.

Personally I find it easier when the damn compiler throws the error
because you can't get your params correct.

YMMV.



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Strong parameter checking

[Mike yearwood]

Hi Kevin


Message: 4
Date: Mon, 26 Jun 2006 08:11:23 -0400
From: Kevin Cully <[EMAIL PROTECTED]>
Subject: Strong parameter checking
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
   LOCAL lcRetVal
   lcRetVal = []
   IF PCOUNT() = 1
  IF NOT ISNULL(tcSomething)
 IF VARTYPE(tcSomething) = "C"
IF NOT EMPTY(tcSomething)
   lcRetVal = [My Function ] + tcSomething
ENDIF
 ENDIF
  ENDIF
   ENDIF
   IF EMPTY(lcRetVal)
  =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
"  Try again."
   ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.


Personally I find it easiest to check parameters first and get out if
necessary and then follow with the heart of the function. This clearly
separates the two steps and the meat of the function is cleaner and
easier to follow.

FUNCTION MyFunction(tcSomething AS String) AS String
  LOCAL lcRetVal
  lcRetVal = []
  IF PCOUNT() = 0 OR VARTYPE(tcSomething) # "C"
RETURN lcRetVal
  ENDIF

*Now the real meat of the function is not tabbed way over for nothing.

RETURN lcRetVal
ENDFUNC

Mike


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Kevin Cully]

Bad Dave! 

Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!
http://foxforward.net


Dave Crozier wrote:

Kevin,
If the wrong parameters are passed then immediately reformat the hard disk.
That way you will get very few repeat errors and the evidence of your
mischief will be completely erased.  




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Ed Leafe]

On Jun 26, 2006, at 8:55 AM, Andy Davies wrote:


There must be a better way that I'm unaware of.


default parameter values - which was done much better in Clipper <~g>


Which is done even better in Python!

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dave Crozier]

Kevin,
If the wrong parameters are passed then immediately reformat the hard disk.
That way you will get very few repeat errors and the evidence of your
mischief will be completely erased.  


Dave Crozier
"A computer is a stupid machine with the ability to do incredibly smart
things, while computer programmers are smart people with the ability to do
incredibly stupid things. They are, in short, a perfect match"  - Bill
Bryson
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kevin Cully
Sent: 26 June 2006 13:11
To: profox@leafe.com
Subject: Strong parameter checking

I'm working on a class that I'm wanting to make Open Source and I'm making
functions/methods that take parameters.  This function could be abused in
ways that I have never anticipated.  Since VFP is loosely typed, I'm
wondering what checking I have to do on these parameters to make sure that
the parameter is provided, not .NULL. and of the type expected?  Is this
overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
LOCAL lcRetVal
lcRetVal = []
IF PCOUNT() = 1
   IF NOT ISNULL(tcSomething)
  IF VARTYPE(tcSomething) = "C"
 IF NOT EMPTY(tcSomething)
lcRetVal = [My Function ] + tcSomething
 ENDIF
  ENDIF
   ENDIF
ENDIF
IF EMPTY(lcRetVal)
   =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
 "  Try again."
ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must be a
better way that I'm unaware of.

--
Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!



[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Kevin Cully]

Thanks Dominic and Michael.  I just had one of those moments where I'm 
stepping back after writing that code and saying "I wonder if what I 
think I know is the best way to do this?"


-Kevin

Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!
http://foxforward.net


Michael Hawksworth wrote:
In vfp 9 you can skip the is null and just use the additional parameter 
in vartype.


For numbers you need to check if they are ints etc, strings if they are 
empty (if they shouldn't be etc), check for illegal characters.


I try(!) to do this for all procedures anyway as it cuts down 
development problems.  Although a lot of the tests are then in asserts.


I suggest creating a set of functions that you can call to do this if 
you are in earnest which will make it easier to code.


The problem with Dominics approach (using case) is getting a meaningful 
error message back (e.g. invalid number of parameters etc.)


P.S.  Dominic... is that job title getting longer?





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Andy Davies]

>There must be a better way that I'm unaware of.

default parameter values - which was done much better in Clipper <~g>

Andrew Davies  MBCS CITP
  - AndyD    8-)#


**

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.

Please contact [EMAIL PROTECTED] with any queries.

**



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Andy Davies]

>Is this overkill?

No, which is why everyone just ships Beta's 

Andrew Davies  MBCS CITP
  - AndyD    8-)#


**

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager.

This footnote also confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.

Please contact [EMAIL PROTECTED] with any queries.

**



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

<< P.S.  Dominic... is that job title getting longer?

LOL! 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Hawksworth
Sent: 26 June 2006 13:39
To: profox@leafe.com
Subject: Re: Strong parameter checking

In vfp 9 you can skip the is null and just use the additional parameter
in vartype.

For numbers you need to check if they are ints etc, strings if they are
empty (if they shouldn't be etc), check for illegal characters.

I try(!) to do this for all procedures anyway as it cuts down
development problems.  Although a lot of the tests are then in asserts.

I suggest creating a set of functions that you can call to do this if
you are in earnest which will make it easier to code.

The problem with Dominics approach (using case) is getting a meaningful
error message back (e.g. invalid number of parameters etc.)

P.S.  Dominic... is that job title getting longer?

--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list:
http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of
the author, and do not constitute legal or medical advice. This
statement is added to the messages for those lawyers who are too stupid
to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: Strong parameter checking

[Michael Hawksworth]

In vfp 9 you can skip the is null and just use the additional parameter 
in vartype.


For numbers you need to check if they are ints etc, strings if they are 
empty (if they shouldn't be etc), check for illegal characters.


I try(!) to do this for all procedures anyway as it cuts down 
development problems.  Although a lot of the tests are then in asserts.


I suggest creating a set of functions that you can call to do this if 
you are in earnest which will make it easier to code.


The problem with Dominics approach (using case) is getting a meaningful 
error message back (e.g. invalid number of parameters etc.)


P.S.  Dominic... is that job title getting longer?

--
Michael Hawksworth
Visual Fox Solutions

[EMAIL PROTECTED]
www.foxpro.co.uk





___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

RE: Strong parameter checking

[Dominic Burford]

Hi

I tend to use a DO CASE construct when I want to do something like this.

Function MyFunction (tcSomething)
Do Case
Case Pcount() <> 1
Case IsNull(tcSomething)
Case Not (Vartype(tcSomething) = "C")
Otherwise   
*-- Everything is OK
EndCase

Regards

Dominic Burford BSc Hons MBCS CITP
Third Party Developer Program Senior Software Engineer 

* Tel: +44 (0) 1536 495074
* [EMAIL PROTECTED] 

"I conclude that there are two ways of constructing a software design:
One way is to make it so simple there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies." -- Tony Hoare, Turing Award Lecture 1980


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kevin Cully
Sent: 26 June 2006 13:11
To: profox@leafe.com
Subject: Strong parameter checking

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
LOCAL lcRetVal
lcRetVal = []
IF PCOUNT() = 1
   IF NOT ISNULL(tcSomething)
  IF VARTYPE(tcSomething) = "C"
 IF NOT EMPTY(tcSomething)
lcRetVal = [My Function ] + tcSomething
 ENDIF
  ENDIF
   ENDIF
ENDIF
IF EMPTY(lcRetVal)
   =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
 "  Try again."
ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

--
Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list:
http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of
the author, and do not constitute legal or medical advice. This
statement is added to the messages for those lawyers who are too stupid
to see the obvious.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

__
Pegasus Software Limited is a member of the Systems Union Group plc

Registered Office:  Systems Union House, 1 Lakeside Road, Aerospace Centre, 
Farnborough, Hampshire GU14 6XP  Registered No: 1601542

This e-mail is from Pegasus Software Limited. The e-mail and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom it is addressed. If you have received this e-mail 
in error you must not copy, distribute or take any action in reliance on it. 
Please notify the sender by e-mail or telephone.

Pegasus Software Limited utilises an anti-virus system and therefore any files 
sent via e-mail will have been checked for known viruses. You are however 
advised to run your own virus check before opening any attachments received as 
Pegasus Software Limited will not in any event accept any liability whatsoever 
once an e-mail and/or any attachment is received.

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Strong parameter checking

[Kevin Cully]

I'm working on a class that I'm wanting to make Open Source and I'm
making functions/methods that take parameters.  This function could be
abused in ways that I have never anticipated.  Since VFP is loosely
typed, I'm wondering what checking I have to do on these parameters to
make sure that the parameter is provided, not .NULL. and of the type
expected?  Is this overkill?

FUNCTION MyFunction(tcSomething AS String) AS String
   LOCAL lcRetVal
   lcRetVal = []
   IF PCOUNT() = 1
  IF NOT ISNULL(tcSomething)
 IF VARTYPE(tcSomething) = "C"
IF NOT EMPTY(tcSomething)
   lcRetVal = [My Function ] + tcSomething
ENDIF
 ENDIF
  ENDIF
   ENDIF
   IF EMPTY(lcRetVal)
  =MESSAGEBOX("Your call to " + PROGRAM() + " is lacking." + ;
"  Try again."
   ENDIF
RETURN lcRetVal
ENDFUNC

What's the most graceful way in VFP to accomplish this?  ASSERTS work in
development but what about data driven production systems?  There must
be a better way that I'm unaware of.

--
Kevin Cully
CULLY Technologies, LLC

Sponsor of Fox Forward 2006!



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.