mjhjmtu

I have already seen these posts Macro defining macro and
Macros that define other macros, which also define other macros but unfortunately I didn't manege to figure it out how to correct my attempt to the problem.
I want to create a macro which will produce macro + global macro with @ in front of macro name, like in the following example:

 defBob#1gdef@Bob#1
 BobMy name is Bob
 makeatletter
 @Bob % it will display `My name is Bob'
 BobName: Bob
 @Bob % it will display `Name: Bob'
 makeatother

So this works. However:

 defDefineField#1%
 expandafteredefcsname #1endcsname##1%
 gdefcsname @#1 endcsname##1%
 %
 
 DefineFieldAlice
 AliceMy name is Alice

doesn't work. I got Undefined control sequence. with @Alice. I have checked Alice and Bob with show command:

> Bob=macro:
#1->gdef @Bob #1.
l.20 showBob
> Alice=macro:
#1->gdef @Alice #1.
l.21 showAlice

They have exactly the same structure. What did I miss?
MWE:

documentclass[preview]standalone
makeatletter

defDefineField#1%
 expandafteredefcsname #1endcsname##1%
 gdefcsname @#1 endcsname##1%
 %

DefineFieldAlice
AliceMy name is Alice


defBob#1gdef@Bob#1
BobMy name is Bob

begindocument
%@Alice % Undefined control sequence.
@Bob
BobNo my name is Alice

@Bob
showBob
showAlice
makeatother
enddocument

The definition of DefineField has a superfluous space in gdefcsname @#1 endcsname##1%, it should be

defDefineField#1%
 expandafteredefcsname #1endcsname##1%
 gdefcsname @#1endcsname##1%
 %

With the space you would define the command @Alice␣ (where ␣ represents a space) as can be verified by checking @Alice␣'s definition with

expandaftershowcsname @Alice endcsname

If we want to define @Alice we need to get rid of the space.

Note that the use of edef in DefineField can have unintended consequences, so you may want to consider going for the solution presented in Martin Scharrer's answer or egreg's answer.

I would not use edef here but work with a second expandafter.

The main problem here is that you have a space between #1 and endcsname, so you actually define @Alice<space>, which is possible with csname.

Correct code is:

defDefineField#1%
 expandafterdefcsname #1endcsname##1%
 expandaftergdefcsname @#1endcsname##1%
 %

You're defining csname @Alice endcsname which results in a control sequence token having a trailing space in its name. The space after csname doesn't find its way during tokenization, because it follows a control word, but the space between #1 and endcsname will not be removed.

Your usage of edef is quite problematic as well: if you mistakenly use DefineFieldAlice twice,

DefineFieldAlice
AliceMy name is Alice
showAlice

DefineFieldAlice
showAlice

you'll get

> Alice=macro:
#1->gdef @Alice #1.

> Alice=macro:
#1->gdef My name is Alice#1.

This can be cured by checking first if Alice is defined:

defDefineField#1%
 @ifundefined#1
 % go on, it's undefined
 expandafteredefcsname #1endcsname##1%
 gdefcsname @#1endcsname##1%
 %
 
 % ignore the redefinition
 PackageWarningandywiecko%
 expandafternoexpandcsname #1endcsname already defined%
 %
 %

A simpler approach with xparse and expl3:

documentclassarticle
usepackagexparse

ExplSyntaxOn

NewDocumentCommandDefineFieldm
 
 cs_new_protected:cpn #1 ##1
 
 cs_new_protected:cpn @#1 ##1 % or `cs_new:cpn
 
 

ExplSyntaxOff

DefineFieldAlice
AliceMy name is Alice

expandaftershowcsname @Aliceendcsname

This will produce a standard error if DefineFieldAlice is used twice or if you try doing DefineFieldbox; the code will show

> @Alice=protectedlong macro:
->My name is Alice.

You may want to use cs_new:cpn in the second instance, depending on what expansion context you will use the @Alice macro.

A more proper expl3 interface, where instead of defining @foo macros you do UseFieldfoo when needed. A way to override already existing fields is provided.

documentclassarticle
usepackagexparse

ExplSyntaxOn

prop_new:N g_andywiecko_fields_prop
cs_new:Nn andywiecko_define_field:nn
 
 prop_gput:Nnn g_andywiecko_fields_prop #1 #2 
 

NewDocumentCommandDefineFieldsm
 
 cs_set_protected:Nn __andywiecko:n
 
 andywiecko_define_field:nn #2 ##1 
 
 IfBooleanTF #1 
 % override an existing definition
 cs_gset_eq:cN #2 __andywiecko:n
 
 % new field
 cs_new_eq:cN #2 __andywiecko:n
 
 

NewExpandableDocumentCommandUseFieldm
 
 prop_item:Nn g_andywiecko_fields_prop #1 
 

ExplSyntaxOff

DefineFieldauthor % gives error

DefineField*author % no error, use new interface

DefineFieldAlice
AliceMy name is Alice

DefineFieldAlice % gives error

In the other answers the spurious space within the csname..endcsname-expression is already pointed out.

In case you wish to avoid typing so many csname..endcsname-expressions, I can offer a macro name.

name takes following tokens that are not nested in braces for its first argument and following tokens nested in braces for its second argument and applies csname..endcsname to its second argument.

The tokens that form the first argument can, e.g., be: globallongouterdef or newcommand or string or meaning or whatever.
You can also leave the first argument empty.

Examples:

nameshowfoo yields: showfoo

namedeffoo... yields: deffoo...

namegloballongouterdeffoo... yields: globallongouterdeffoo...

namenewcommandfoo... yields: newcommandfoo...

namefoo... yields: foo

namenamegloballetfoo=bar

yields:
namegloballetfoo=bar

yields:
globalletfoo=bar

documentclassarticle

newcommandUDExchange[2]#2#1
newcommandnamelongdefname#1#romannumeral0innername#1%
newcommandinnername[2]%
 expandafterUDExchangeexpandaftercsname#2endcsname #1%
%

makeatletter
newcommandnovalueprovidednfss@textreset@fontbfseries??
makeatother

newcommandDefineField[2][novalueprovided]%
 namenewcommand#2[1]namegdef@#2##1%
 namenewcommand@#2%
 name#2#1%
%

newcommandUseField[1]name@#1%

DefineField[initial value of field Alice]Alice

DefineFieldBob

begindocument

UseFieldAlice:

hrulefill

Now the fields are changed:

AliceMy name is Alice

BobMy name is Bob

UseFieldAlice:

enddocument

If you provide more info about what you try to achieve in practice, an interface could be developed which also does better error-management.