Macros for Generating Compiler Declaration in Methods

Jack Des Bouillons (5/19/14 1:49PM)
Chuck Miller (5/19/14 2:34PM)
Tim Nevels (5/19/14 4:41PM)
Joshua Fletcher (5/19/14 7:33PM)
Joshua Fletcher (5/19/14 7:37PM)
Joshua Fletcher (5/19/14 7:42PM)
Tim Nevels (5/27/14 6:56PM)
Arnaud de Montard (5/28/14 9:46AM)


Jack Des Bouillons (5/19/14 1:49 PM)

On 5/19/14 12:48 PM, "Bernard Escaich" <bernard.escaich@...
wrote:

color><param>00000,0000,DDEE/param>
I just change my naming convention due to autocompletion ; actually I
put
variable type at the end of variable name instead of beginning.
/color>
Where it belongs!

As always, in my opinion.

Jack des Bouillons

Chuck Miller (5/19/14 2:34 PM)

They do but constantly change
Regards
Chuck
On May 19, 2014, at 1:42 PM, Joshua Fletcher wrote:

color><param>00000,0000,DDEE/param>CClarification: the 4DPop macro
component allows you to edit the rules governing naming conventions,
so if you have a consistent naming convention throughout your app, it
can be quite convenient. ?But I have a feeling most real world 4D apps
don't enjoy that much consistency :)

Kind regards,

Josh
/color>

--------------------------------------------------------------------------
----------------------
Chuck Miller Voice: (617) 739-0306
Informed Solutions, Inc. Fax: (617) 232-1064 ?=A0?=A0?=A0
PO Box 1720 mailto:cjmiller<AT SIGN>iinformed-solutions.com
Brookline, MA 02446 USA Registered 4D Developer ?=A0?=A0?=A0?=A0?
?=A0?=A0?=A0
?=A0?=A0?=A0Providers of 4D and Sybase connectivity
?=A0?=A0?=A0?=A0?http://www.informed-solutions.com ?

--------------------------------------------------------------------------
----------------------
This message and any attached documents contain information which may
be confidential, subject to privilege or exempt from disclosure under
applicable law. ?These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution,
disclosure, printing, copying, storage, modification or the taking of
any action in reliance upon this transmission is strictly prohibited.
?Delivery of this message to any person other than the intended
recipient shall not compromise or waive such confidentiality,
privilege or exemption from disclosure as to this communication.

Tim Nevels (5/19/14 4:41 PM)

On May 19, 2014, at 2:57 PM, Joshua Fletcher wrote:

color><param>00000,0000,DDEE/param>JJust a forewarning: every
implementation of this that I've seen requires that you use a specific
naming scheme for variables. In other words I haven't seen anyone
implement a 4D lexer to automatically figure out what is a variable
and what isn't. So either you have to do the work to rename all your
variables, or just do the work to add the typing declarations.
/color>
Josh is correct. It would be very challenging to create a lexer that
took into account all they different syntax for all the 4D commands
and infer variable types. It's possible, but very challenging.
Currently the only way to accurately determine variable types --
local, process or interprocess -- is by using a naming convention.

I have two macros that I use every day to create compiler directives
-- C_TEXT, C_LONGINT, ARRAY TEXT, etc. -- for local variables in
methods and also to create compiler declarations for method parameters
-- C_TEXT(MethodName;$1).

The local variable declaration macro works by parsing the method text
and looking for strings that begin with "$" -- ignoring $0, $1, etc.
?The naming convention I use is to have the type as a suffix to the
variable name. So for text it is "_t", for longint it is "_l", for
array of text it is "_at" and etc. No suffix defaults to a longint.
Scan the method text, build a list of all local variable names. Check
the variable name suffix and create the compiler directive. Then it
auto pastes it into the insertion point or current selection of the
method. Works great. After i finish writing the method I run the macro
and it builds my compiler directives for me.

Using this macro can also help you spot some typos in your methods. I
check the compiler directives and if I see something like
C_LONGINT($i;$ii) I know I've probably got a typo.

The other macro takes the current selection in the method -- which are
compiler directives with parameter variables like C_LONGINT($1). It
then builds the compiler declaration for method parameters --
C_TEXT(MethodName;$1). I get the method name from the window title.
Then using the hmFree_OpenMethodEditor plugin command it pastes this
into my "Compiler Declare Parameters" method.

Using theses 2 macros I can easily run with "Compiler all variables
typed". I still have to manually declare process and interprocess
variables. But I like that. It makes me use them sparingly and add
them only when necessary.

Tim

Joshua Fletcher (5/19/14 7:33 PM)

Hi Tom,

Just a forewarning: every implementation of this that I've seen
requires that you use a specific naming scheme for variables. In other
words I haven't seen anyone implement a 4D lexer to automatically
figure out what is a variable and what isn't. So either you have to do
the work to rename all your variables, or just do the work to add the
typing declarations.

Note that if your "Compilation Path" in Database Settings is "All
variables are typed", the compiler will make sure you're doing what
you want to do (and give an idea how big the project will be). You can
safely switch between the compiler settings.

Kind regards,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>AAnyone have a macro for gathering
variables from a method and putting them
into a compiler declaration?
/color>

Joshua Fletcher (5/19/14 7:37 PM)

Not sure what you mean by "it is difficult to reverse Engeenering" but
I just wanted to mention that all 4D POP components include the source
code. If you're on OS X, you'll have to open the package to find it.

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>II can answer !
I had converted my macros successfully un V11, put in a component
based on
4D Pop macros and tried to ?=A9liminate some antiquities.
At That point I have issues and it is a priority for me to make them
work
again.
I did not use 4D Pop macro because it is difficult to reverse
Engeenering
and my code was much faster.
/color>

Joshua Fletcher (5/19/14 7:42 PM)

Clarification: the 4DPop macro component allows you to edit the rules
governing naming conventions, so if you have a consistent naming
convention throughout your app, it can be quite convenient. ?But I
have a feeling most real world 4D apps don't enjoy that much
consistency :)

Kind regards,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>JJust a forewarning: every
implementation of this that I've seen requires
that you use a specific naming scheme for variables. In other words I
haven't seen anyone implement a 4D lexer to automatically figure out
what
is a variable and what isn't. So either you have to do the work to
rename
all your variables, or just do the work to add the typing declarations.
/color>

Tim Nevels (5/27/14 6:56 PM)

On May 27, 2014, at 6:09 PM, Jim Dorrance wrote:

color><param>00000,0000,DDEE/param>WWhy at the end?
/color>
Most people read from left to right. The most significant piece of
information should come first.

So is the most important bit of information about a variable name the
name itself, or the variable type? ?For me it is the variable name.
The variable type is secondary. So I put the type at the end of the
variable name.

I've always disliked the naming scheme where you start every variable
with "v". Such a waste. Anyone that is still doing this, you need to
stop it! This is an old habit you need to break.

The reason for this stupid naming convention dates back the the 4D v1
days where you had only a black and white method editor and there was
no object methods, only form methods -- called "layout procedures"
back then. People would reference fields with only their name -- like
"LastName" instead of "[People]LastName". So to distinguish a variable
name from a field name the convention back then was to preface
variable names with "v".

Now we have colors in the method editor. Process variable can have
their own color to make them easy to identify. And field names can
have their own color. And it is now the convention to always specify
field names with the table name. Colors in the method editor provide
intrinsic meta data to names. Use it. That's why Laurent added colors
to the method editor back in 1990 with 4D v2.

There's also the "b" prefix for button variables -- "bOK" and
"bCancel". I prefer a descriptive name like "OKButton" or
"CancelButton". I leave off the "_l" suffix to indicate the type
because in my variable naming scheme, a variable without a type suffix
is by default a longint.

Tim

Arnaud de Montard (5/28/14 9:46 AM)

Le 28 mai 2014 &yacute; 01:13, Bernard Escaich a &Egrave;crit :

color><param>00000,0000,DDEE/param>II have reorganized my naming
convention to take advantage of autocompletion on all variables, not
only type.
/color>
very good point!

color><param>00000,0000,DDEE/param>AAdding type at the end may be
useful to distinguish $Date_d and $Date_t.
/color>
$guessWhat:=Table($table)
$headOrTails:=Field($field)

--
Arnaud de Montard

Reply to this message

Summary created 5/28/14 at 6:49PM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com