[erlang-questions] If you are homesick for object.selector
Sun Jan 27 09:13:32 CET 2013
> While I have no idea how the Erlang parsing process works, I assume it
> would not be very hard to write a pre-processor that does the following;
> 1. parse all code for occurrences of record assignments. (i.e.
> 2. replace all occurrences of the Variable + "." with
> Variable#typeFromScope.) (i.e. replace "Person.[somevar]" with
Why do you assume that?
The preprocessor would have to do more work than the normal
f(X) -> X#???.a.
There isn't any type in scope. And this is far from
unusual in Erlang code.
> If you did forget to mention your type somewhere, compilation would still
> fail (which is what it should do IMO).
> Most of the frustration probably hides in the fact that the compiler
> be able to derive that info from the code, as it has been mentioned
Should be able to derive it? Please describe the algorithm.
I used to be an ML fan, and like Haskell a lot.
But there is one phenomenon common to programming
languages with type inference, unless you put a _lot_
of work into error reporting. This is where a tiny
change to a module in one place (like, for example,
removing one call to a function, leaving others) causes
an error report somewhere else in the module (like the
compiler no longer being able to disambiguate a field).
These days we do have the Dialyzer, but it is an _optional_
tool, and it wasn't designed for this particular task.
I honestly don't see what's so bad about putting the
record name in the selector. It was common practice in
Lisp-family languages to use things like
(set-circle-area! my-circle (* (circle-area my-circle) 2))
For that matter, look at C structs like 'struct tm' with its
tm_sec, tm_min, tm_hour. tm_mday &c fields.
More information about the erlang-questions