[erlang-questions] implementing annotation in erlang

Robert Virding rvirding@REDACTED
Thu Sep 3 01:00:40 CEST 2009


You have a problem in that Erlang has practically no global data stored
implicitly by the system. Everythig is in ets tables, processes or in
modules. So however you decide to store your data you will have to do
yourself, you will have to actually build the table somewhere.

To save having to keep multiple copies of the table you can either put it an
ets table, which can be made accessible to all processes, or use a dict in a
named dispatch process which all process could then access. This is what I
understand Igor was saying.

An alternative would be to add dispatch tables as code in the actual modules
and have a central dispatch module to call the right module. The dispatch
table would effectively be stored in code. To change the table you would
need to modify and recompile the module. This is doable.

It's tough but if you don't have any global data then you don't,

Robert

2009/9/3 paweł kamiński <kamiseq@REDACTED>

> yes sure, but you need to somehow insert the association into the
> dict/list/ets whatever, I dont want to do it manually, I would like to mark
> my function (like in java, yes Im aware that erlang is not java:) with some
> metadata that is far simpler to maintain in development cycle. so the
> problem is how to put name->fun mapping into some structure rather than
> what
> type of the structure to use.
>
> the simplest solution would be to have a fun in the module like
>
> *commandMap()->
>    NewMap = dict:new(),
>    Map1 = dict:store("**getDevTimeCmd", **getTime, NewMap),
>    Map2 = dict:store("**getDevTimeCmd", **getTime, Map1),
>    ..
>    MapN
>    .*
>
> but then every time I change my function name or command name or add or
> delete something I need to update commandMap as well in every command
> module, I would rather write one general function that gets info about
> function and generates insert to the structure so I can focus on more
> interesting things.
>
> pozdrawiam
> Paweł Kamiński
>
> kamiseq@REDACTED
> pkaminski.prv@REDACTED
> ______________________
>
>
> 2009/9/2 Igor Ribeiro Sucupira <igorrs@REDACTED>
>
> > From what I understand, you want to associate names with functions, so
> > that you can decide which function to run just by "calling its name".
> >
> > If I am right, one way to implement what you want is to have a dict
> > holding those associations (Name -> Function). That dict could be the
> > responsibility of a named process, that would provide a wrapper (a
> > message-passing "API") for the dict operations.
> >
> > Or you could use ets.
> >
> > Igor.
> >
> > 2009/9/2 paweł kamiński <kamiseq@REDACTED>:
> > > hi,
> > > I need to implement simple command dispatcher like this
> > >
> > > *[{cmdA, module_name, funA},{cmdB, module_name, funB}, ...] *
> > >
> > > and then use it with each call to my process with specific command
> name.
> > But
> > > then every time I change or add function I need to remember to manually
> > > change cmd-fun list.
> > > normally I would annotate a function with command name (ie
> > > @command(name="getDevTimeCmd")) and then use the information to build
> > > dispatcher map while initializing object.
> > >
> > > I know I can use *module_info()*  to get list of all exported function
> in
> > > the module, but then I can't decide which function is command's
> callback
> > nor
> > > define a name of the command(and use only function name instead).
> > >
> > > The promising solution I'm thinking about is to use macro
> > > *-define(command(Name, Fun), assignCommandCallback(Name, Fun)).*
> > > and
> > > *?command("getDevTimeCmd", getTime).
> > > getTime(Args)->... .*
> > >
> > > but I'm not really sure how to use the information provided that way,
> > when
> > > the assignCommandFun/2 will be executed???
> > >
> > > tanks for any suggestions
> > >
> > > pozdrawiam
> > > Paweł Kamiński
> > >
> > > kamiseq@REDACTED
> > > pkaminski.prv@REDACTED
> > > ______________________
> > >
> >
>


More information about the erlang-questions mailing list