>>>>>>All the more reason to have it, IMO. What do you think this means: GOMONTH(DATE() - DAY(DATE()) + 1, 1) - 1
>>>>>>
>>>>>>A rose by any other name would smell as sweet, but having to decipher a formula stinks.
>>>>>>
>>>>>
>>>>>It means last day of this month. What is there to decipher it? To decipher you need something like a cipher, no? Maybe I don't see the philosophy here:) IMHO that X2... was something to decipher for a simple task that you could do inline.
>>>>>Cetin
>>>>
>>>>I'm surprised you do not see the problem. GetLastDayOfMonth() needs no deciphering/decoding/thought. If you have never seen the above line, you cannot tell what it does as quickly as GetLastDayOfMonth().
>>>
>>>No I don't see the problem. I can easily say at a glance that code is for finding last day of this month while GetLastDayOfMonth() is not as clear and needs deciphering. Does that accept parameter and used for any month or this month?
>>>
>>>In case of X2... isn't it the same? You would use such a thing very rarely and probably each time you use you would need to check source to remember what it does. An inline code OTOH would be short, clear, concise (for me).
>>
>>Thank you for proving my point. I often tell customers programmers would rather run a pair of wires into a cylinder instead of using a spark plug. You are missing the obvious by looking too deeply. There are parameters in the formula and in the UDF. So that is no difference. The formula is like saying "a plant with thorns on the stem with a flower that is red". "red ROSE" is much easier. Any formula takes time to parse / type. Copy and pasting of said formula is wrong too.
>
>You are welcome:)
>Mike, I think the problem is that you are making irrelevant analogies. To you that function is complex, to me it is not and I can say what it does at a glance. Lets do not use analogies but the actual question's context here to see what I mean:
>-In an application -and not just one application include all applications you built so far- a function to differentiate if the variable is an array or not is needed very rarely, maybe at one, two or three places but hardly four (think objective please).

I have 19 places in MaxFrame where x2isarray is used. A function in this case means that via compiler directives, a system that migrated from 2.6 to 9 could be modified to use the latest syntax in vfp9 and not require 19 individual changes. If the function was called IsArray I am certain you could more easily see what it must do. It's a rose. By the way, I use Rose because of Romeo and Juliet.

>
>-If you are using a function so rarely it is hard to remember its name and what it does. For example (and believe me I am honest here) I can't remember the fullname of that X2.. function. X2Array, XIsArray, X2IsArray? I need to lookup to remember. Then read it to understand what it is supposed to do if I didn't use it recently.

You should not have to read it to understand. It must be so named as to make it obvious. I agree the x2 part isn't good. I originally wrote it as IsArray().

>
>-Problem that it solves is too much simple and doesn't need a separate function IMHO. It is not like GoMonth(...) but more like padl(m.x,2,'0'). Why would I create a separate helper function for:
>
>

type('alen(aVar)')

when it is barking at me it is about checking if aVar is an array or not?

As I'm trying to say, to me THAT says "what is the type of the len of the array"? You must include the ="N" part to further specify is it numeric and then you have to interpret that as "it is an array if it is numeric". Indirectly it means I have to remember that alen does not return a numeric if the parameter is not an array. That's a lot of work. Do not forget that you will do this much work in other cases, so why not avoid that process entirely?

>Do you really create a separate "redrose" like function for each and every type instead of using type() or vartype()? I don't think so.

No, I don't use helper functions for single functions, but when they are combined I tend to want the helper function to encapsulate.

"In computer science, encapsulation is the hiding of the internal mechanisms and data structures of a software component behind a defined interface, in such a way that users of the component (other pieces of software) only need to know what the component does, and cannot make themselves dependent on the details of how it does it."

>
>-As I noted in that wiki entry it doesn't work in every version. OTOH simple type('alen(aVar)') exits and works since fox2x (and maybe before that, I don't remember).

Good, I don't have a problem making it work in every version especially if it's going on the wiki! :) x2isarray is 9 characters and that won't be good in 2.6. It should drop the x2 and be simply IsArray. Agreed? It would only take some compiler directives to make it work.

Is it ok that it handles properties by matching the addproperty and removeproperty syntax?

>
>And I have to admit I have a set of date/datetime utuility functions and I sort of use cryptic (for 3rd parties) function names myself. I am lazy to name a function like GetLastDayOfMonth() and I name such as LDOM(), FDOM(), LDOW(),FDOW()...

I agree. That is the kind of obfuscation I am against. Intellisense makes it really simple to type long names.