[erlang-questions] A Generic API for controlling software components

[Michael Richter]

2009/11/25 Joe Armstrong <erlang@REDACTED>

> >>     Rule4: All components C must have a file called
> >>
> >>            $HOME/eComponents/C.ec/Preferences.pl
> >>
> >>          The extension .pl means the file contains a property
> >>            list. Here is an example:
> >>
> >>            {codePath, "/bin"}.
> >>            {expiryDate, {2009,12,24}}.
> >>          {icon, "/images/myIcon.png"}
> >>          {version,1}
> >>            {myKey1, ...}
> >>
> >>            The keys codePath, version, and expiryDate are obligatory
> >>
> >>            Why do we need code path? - so that Erlang can find
> >>            a module called C.erl
> >>
> >>            Expiry date has a "time to live for the component"
> >>            Version is used for local configuration data (see later)
> >>            Version numbers should start at one and be increased by one
> >>            for each new release.
> >
> > Here I would like to have a consistent naming style. Until today most
> parts of Erlang don't use
> > camel case. I like it in Smalltalk, and I like the consistency inside
> Scheme, and until today I
> > like the consistency in Erlang. It's not like Python, where you can see
> which libs are from the
> > Smalltalk or Java side, from the .NET side or the C side. Awful. So it
> should be called
> > preferences.pl with code_path, expiry_date, and so on. Additionally I
> would like nested
> > preferences. My Tideland CEL celcfg module handles this well.
>
> I use names_like_this for function and module names but namesLikeThis
> for atoms in code
>

The idea is sound.  The execution is suboptimal here.  The ending *.pl* is
embedded in the minds of a very large number of people as a perl script.
Choose perhaps a longer, more descriptive extension like, say, .proplist or
.propl or .plist or whatever?