bug or feature?
Wed Apr 19 18:33:26 CEST 2006
In a general case you are absolutely right as the complexity of the
proposed solution is still linear. Would anyone care that the other
approach would work 2 to 3 times faster? When it comes to
soft-real-time applications with extensive prefix analysis, I would.
Though I realize that the majority of apps don't care.
A more rhetorical question would be that if '++' is a "syntactic sugar"
why wouldn't that syntactic sugar apply for bound Prefix variables as
well to make it more generic?
Richard A. O'Keefe wrote:
> Serge Aleynikov <> wrote that
> strip_prefix(Prefix ++ Suffix, Prefix) ->
> strip_prefix(String, _Prefix) -> % fixed
> would be "much easier to read" than
> strip_prefix(String, Prefix) ->
> strip_prefix2(String, Prefix, String).
> strip_prefix2(Suffix, , _String) ->
> strip_prefix2([C|Tail], [C|PrefTail], String) ->
> strip_prefix2(Tail, PrefTail, String);
> strip_prefix2(_, _, String) ->
> I don't find either of them particularly easy to read, because the
> code contradicts the name. However implemented, this function DOESN'T
> always strip a prefix. By the time that has been addressed with a
> fair comment explaining what the function really does, there is little
> to choose between these functions.
> strip_prefix(List, Prefix) ->
> case lists:prefix(Prefix, List)
> of true -> lists:nthtail(length(Prefix), List)
> ; false -> List
> is only one line longer than the ++ version, and seems pretty clear
> (except for the non-intention-revealing name).
More information about the erlang-questions