# Thread: Differentiating Methods from Functions (...and even Properties)

1. ## Differentiating Methods from Functions (...and even Properties)

When searching for ways to do things.... (No smart remarks here, please! ~ Just think abut this for a moment, and I believe you will understand.)

~ APPARENTLY, I HAVE ISSUES ~
I have a heck of a time figuring out whether I'm looking for a function, or a method.... (when learning new things & ways of doing things)
It seems to me, the only real difference is that a method "technically" is "applied to an object. (and a function is an action "called" by an object)......

Always seemed (still seems) like a "grey area" to me....
The wiki isn't overly helpful in this matter either. On some pages functions (*CONCAT() function for example) are referred to as: *CONCAT function (all functions page), and not CONCAT() (*CONCAT() page) ~ (missing the parenthesis, which would indicate it is in fact a function and not a method)

To a lesser extent, this also seems a touch ambiguous even when referring to object properties..... (although I guess the assignment of = .T., or ="RED" clarifies this) ie: When specifying an object's .color property (are we "coloring something red" or are we "assigning the attribute of red?")

Is there a simple thought process / trick I am missing here????..........
("I may be suffering from too much thinking/learning, and not enough sleep.")

2. ## Re: Differentiating Methods from Functions (...and even Properties)

A Function: is when you go to the synagogue, church, soup kitchen...wherever and take tomato sauce mix it with some onions cook it with some ground meat, salt and pepper and produce sloppy Joe, i.e.
mixing (using operands or others) ingredients (parameters) to produce something (output).

A method is to be able to tell: How does the sloppy Joe look like? How does it taste like? What is it made off? How much salt in it? Does it have real meat?..etc. i.e.:
finding out (exposing) attributes (properties) about something.

I really tried very hard not to make any smart remarks about you having issues!! Hope it's only programming issues.

3. ## Re: Differentiating Methods from Functions (...and even Properties)

I don't remember where I saw or learned it but try this.

A function performs a task and generally returns a value.

Think of Alpha objects as power tools.
Object methods are attachments that you can use with a tool, some methods work with different types of objects.
A power drill can accept a drill bit, a screwdriver bit, a paint stirrer, etc. These are methods of the power drill.
A power drill has a color, a weight, a model name, etc. These are properties of the power drill.
A screwdriver bit can be flat tipped, Phillips, Torx, etc. These are properties of the screwdriver bit. A screwwdriver bit doesn't have any methods.

If the documentation is properly stated, all methods should have a period as the leading character. The period indicates that it must be connected to something else (period as drill chuck). Functions do not begin with a period.

Are you using the wiki exclusively? I find it most helpful to utilize the alphafivehelp.chm as a primary source and then the wiki for new features. Much faster search times and you can search with the leading period as in .fetch_last().

4. ## Re: Differentiating Methods from Functions (...and even Properties)

Originally Posted by Stan Mathews
Think of Alpha objects as power tools.
Object methods are attachments that you can use with a tool, some methods work with different types of objects.
A power drill can accept a drill bit, a screwdriver bit, a paint stirrer, etc. These are methods of the power drill.
A power drill has a color, a weight, a model name, etc. These are properties of the power drill.
A screwdriver bit can be flat tipped, Phillips, Torx, etc. These are properties of the screwdriver bit. A screwwdriver bit doesn't have any methods.

If the documentation is properly stated, all methods should have a period as the leading character. The period indicates that it must be connected to something else (period as drill chuck). Functions do not begin with a period.

Are you using the wiki exclusively? I find it most helpful to utilize the alphafivehelp.chm as a primary source and then the wiki for new features. Much faster search times and you can search with the leading period as in .fetch_last().
I'm already using any and all a5 resources known to man......
When looking at the "All functions topics" page, functions are listed differently, (ie: no trailing parenthesis ().) ~That's what I meant with regards to inconsistencies.*

*Because of this, you can't necessarily search the wiki for "functionX()" and find it.... You have to search for "functionX" which returns both functions and similar methods.

As for the alphafivehelp.chm, I do use it as I have older versions of a5. (Even though it's outdated a bit, it's still very useful. Although it's no longer shipped with version 11, right?)

Originally Posted by G Gabriel
I really tried very hard not to make any smart remarks about you having issues!! Hope it's only programming issues.
Got me laughing "G". (Hope you got a kick out of it too!)

In essence you've stated that:

Functions ~ "Perform (actions)"
Methods ~ "Expose (properties)"
Properties ~ "Are (attributes)"

What seems contradictory here (using your analogy) is the A5.COMPACT Method (for example) is considered a method, and not a function...... (That's why I was "thinking" a method is merely a function "tied to a particular object type." ~ as Stan implied)

In this instance, Stan's analogy clarifies things.....

I guess the real issue (that I find rather confusing) here remaining is that there are many functions that can be used, which do the same/similar things as an object's method does. ~ Much overlap, redundancy actually, which adds to my confusion when "learning new things & ways of doing things."

Do you try to accomplish something with a method, or do you search for a function?????....
Also, the complexity of concatenating functions and methods on one line of code adds additional "ambiguity" at times....... ie: br.table_get().fetch_goto(table.current().recno()) as presented in this thread:

5. ## Re: Differentiating Methods from Functions (...and even Properties)

Also, the complexity of concatenating functions and methods on one line of code adds additional "ambiguity" at times....... ie: br.table_get().fetch_goto(table.current().recno()) as presented in this thread:
Sorry, don't see any functions there.
Field object br and the built in table object
Methods .table_get(), .fetch_goto(), .current(), and .recno()

I really don't think there is any benefit to nesting objects and methods as indicated other than if you do so you can use it in an expression where you can't the individual xbasic steps.

rec = table.current().recno()
tbl = table.current()
tbl.fetch_goto(rec)

assuming br is a field object on a form from the table or parent table of the set upon which the form is based.

6. ## Re: Differentiating Methods from Functions (...and even Properties)

Do you try to accomplish something with a method, or do you search for a function?????....
If you have an object (table, field, browse, tabbed, conditional, etc) you likely will use a method to do something. If you have a value (can be the .value property of an object) you will likely use a function to transform that value into another form or gather other information based on the value.

7. ## Re: Differentiating Methods from Functions (...and even Properties)

Hi Stan,

I like your power drill analogy. I'd add the another tool, such as a power saw, and it has totally different methods (attachments), and properties (settings)

A5. is in general an object of the Alpha Five program. It's methods and properties include pretty much everything including functions and code and variable spaces. However, it is essentially a shortcut that is provided that allows us to run the functions() without a prefix pointer (although you can). There are a few functions that have a decimal point as as part of an inner character of it's name (and Alpha Five allows this), so there can be function names that look like methods, e.g.
• a5.Get_CSS_Path()
• file.create_time()

For most intents and purposes, functions and methods are the same. But whether to use a function or method is up to the specific usage, and what capabilities/speed it supplies.

A method implies a specific usage (instance) of an object, whereas a function generally does not have any object associated with it except those indicated by parameters of the function. However, there are functions that do implicitly imply the object, but it either references it directly (e.g. the code editor if open), or derives it from system values (such as the current table or current form)

Object Properties (values) are either current status values of a specific instance of an object, or if writable, allows settings (attributes) of the object. Whether the object does anything with those properties is up to how Alpha created the object.

8. ## Re: Differentiating Methods from Functions (...and even Properties)

Thanks, as stated the analogy is not original property.

so there can be function names that look like methods, e.g.
•a5.Get_CSS_Path()
•file.create_time()
So aren't those object specific methods?

.Get_CSS_Path() being a method of the a5 object and .create_time() being a method of the file object?

I didn't want to get too wordy and discuss the blade method of the skillsaw or the tooth and pitch properties of the blade method.

9. ## Re: Differentiating Methods from Functions (...and even Properties)

I think a "property" of an object is basically just an attribute of the object. It does nothing by itself. It contains a setting that may or may not be changeable by the system or the user. Its akin to a variable that's been bound to the object. It has a value. The value might change. But by itself it does nothing.

10. ## Re: Differentiating Methods from Functions (...and even Properties)

Hi Stan,

Originally Posted by Stan Mathews
So aren't those object specific methods?
No. Let's look at the two I gave you

Code:
```' Create pointer
dim file_ptr as p
' open file
file_ptr=file.open("c:\sc1.txt",FILE_RW_SHARED)
' while object is implied, the method still requires the filename because Alpha just redirected the method to a bunch of file functions
?file_ptr.create_time("c:\sc1.txt")
= 11/10/2011 09:47:43 93 am
' Unfortunately, there is no way to get the open file name and path from the file pointer, although you can with a table.

' compare to this, which uses no pointer.  Unfortunately, there is a file object as well that does have methods that look like this, so it get's confusing
?file.create_time("c:\sc1.txt")
= 11/10/2011 09:47:43 93 am

' This will list the file object methods including file.create_time() which is not the same as the function.  I believe the function overrides the method.
?file.this

' More clear to what I am saying.  This function gets a path
?a5.get_css_path()
= "C:\Program Files\A5V8\css"

' The a5 object pointer does not have this function
?a5.this
= Activating()  'Return name of object that is being activated (if known).
.Active([L fullname])  'Returns the name of the control that has focus.
.Active_Drilldown([L force_active_children])  'Returns the name of the deepest control that has focus.
.Append_Enum(C lastname|N object_enum_flags)  'Returns name of next saved Append operation.
.....
.....
More stuff, doesn't include a5.get_css_path(), because it is not a method, but a function.```

11. ## Re: Differentiating Methods from Functions (...and even Properties)

I see what you mean.

Personally not knowing anything about the compiler, do you think this is just a question of how the coders implemented the functionality. In other words perhaps one coder found it easier to implement a function while another would have presumably gone deeper and added a new method?

12. ## Re: Differentiating Methods from Functions (...and even Properties)

Functions and Methods are pretty much universal terms across many applications. Don't confuse yourself by overthinking it.
When the teacher asked you in first grade: what is 1 plus 1? you used, hopefully in your head, a function (adding, which used an operand: adding) to arrive at the outcome. The outcome DID NOT EXIST untill your brilliant mind produced it via a function.
But when the teacher asked you: what's your name? and your brilliant mind said: Robert. You did not use a function, you used a method. Your name DID exist. Your brilliant mind EXPOSED it via a method: recalling your name.
As to compacting a db, as you can see by the above simple examples, compacting the db did not produce something new ( as in a solution to a quiz, 1+1, or 2X3..etc.) but rather did something to an existing something, thus it is rather a method not a function. You use a function to arrive at an answer. You use method to achieve an objective. Stated otherwise: you use a function to solve a problem. You use a method to LEARN something about an object or PERFORM a task.

The term "Function" is sometimes used indiscriminately. For instance, you could write an "USER DEFINED FUNCTION" to compact your db or zap a table..etc which are methods. The term here is a misnomer, generic and generalized that could perform a method or a function. Leave that alone until the basics sink in.

13. ## Re: Differentiating Methods from Functions (...and even Properties)

Hi Stan,

Originally Posted by Stan Mathews
Personally not knowing anything about the compiler, do you think this is just a question of how the coders implemented the functionality. In other words perhaps one coder found it easier to implement a function while another would have presumably gone deeper and added a new method?
Just a wild guess, but I suspect it is partially coders, and partially historical to the early roots of A5.

But, I like to think about it this way.

A Method should be to the instance of the object it applies to (not so with file. above, but should be). So if you have 2 forms open, and use a form_ptr1.name() or form_ptr2.name(), it should return the name of the form object that the pointer is for.

A function like formname(form_pointer) would return the name of the given form_pointer.

Is either one better than the other? Probably not, however, consider that the 1st is basically code, where the 2nd is more like code with a parameter. If you wanted to say, enumerate all form names, you could create a text that was then evaluated as code (evaluate_template()), or use a function with a parameter value that you change, and repeat in a loop. For that, I think the function would be more straight forward.

However, suppose you had a case where you wanted a sub-form to inherit the properties (styles) of a main form. Then, you might be better copying the properties/methods of the main form, than running generic functions made for forms.

There is probably should be no effective difference in speeds between a function and method doing the identical thing per say. Of course, how each is coded will make a big difference.

14. ## Re: Differentiating Methods from Functions (...and even Properties)

Originally Posted by G Gabriel
Functions and Methods are pretty much universal terms across many applications. Don't confuse yourself by overthinking it.
When the teacher asked you in first grade: what is 1 plus 1? you used, hopefully in your head, a function (adding, which used an operand: adding) to arrive at the outcome. The outcome DID NOT EXIST untill your brilliant mind produced it via a function.
~Concerned, as in elementary school I may have come up with the answer of 11 on that one....

Originally Posted by G Gabriel
....you use a function to solve a problem. You use a method to LEARN something about an object or PERFORM a task.
~I like this analogy!

Originally Posted by csda1
A5. is in general an object of the Alpha Five program. It's methods and properties include pretty much everything including functions and code and variable spaces. However, it is essentially a shortcut that is provided that allows us to run the functions() without a prefix pointer (although you can). There are a few functions that have a decimal point as as part of an inner character of it's name (and Alpha Five allows this), so there can be function names that look like methods, e.g.
• a5.Get_CSS_Path()
• file.create_time()
Very interesting! Your explanation here may also explain why sometimes you can get the bubble coding help (in the code editor) by using XbE drag & drop bubble help only if you drag and drop from the a5.System branch of the XbE. (I've found that dragging from the Objects.Windows (branch) does not always provide code reference popup help in the coding window.) ~And when it doesn't, I can get frequently get the assistance by temporarily dragging the a5.system methods over as reference!

~It also explains why I have a difficult time in "drawing the line between methods and functions."

So methods are essentially "object specific functions." ~ Which are tied/attached/hard coded to specific a5 objects, via a5 internals.
(And, there are a5 functions that may do the same thing (even be the same) as their "method equivalent", yet these functions are not "object specific."

~Here's to over-thinking this out.

15. ## Re: Differentiating Methods from Functions (...and even Properties)

Originally Posted by SNusa
So methods are essentially "object specific functions." ~ Which are tied/attached/hard coded to specific a5 objects, via a5 internals.
Alpha is an object oriented language. You use a method either to learn something about an object or perform a task on an object. You use a function to obtain an output based on parameters. As the parameters change so does the output.
The difference between method and function is the difference between knowledgeable and intelligent.
A knowledgeable person can provide you with information.
An intelligent person can process the information and provide conclusions and/or deductions based on the information.
Sadly and unfortunately you will see these two used interchangeably and you will do yourself a favor by not getting stuck on definitions.

16. ## Re: Differentiating Methods from Functions (...and even Properties)

Thanks everyone...

One more "tiny-quesiton"

When you enter <obj>.this in the IW, what exactly does and doesn't get returned?
(Sometimes I see remarks implying there are functions along with methods returned in the result list.)

ie:
?<FORM>.this (Enter in IW, and you see the remarks in the list referencing functions, methods and properties.)

~Yet in your example with .a5, you don't get .Get_CSS_Path returned...

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•