bug or feature?

[Serge Aleynikov]

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?

Serge


Richard A. O'Keefe wrote:
> Serge Aleynikov <serge@REDACTED> wrote that
> 
> 	strip_prefix(Prefix ++ Suffix, Prefix) ->
> 	    Suffix;
> 	strip_prefix(String, _Prefix) ->	% fixed
> 	    String.
> 	
> would be "much easier to read" than
> 
> 	strip_prefix(String, Prefix) ->
> 	    strip_prefix2(String, Prefix, String).
> 
> 	strip_prefix2(Suffix, [], _String) ->
> 	    Suffix;
> 	strip_prefix2([C|Tail], [C|PrefTail], String) ->
> 	    strip_prefix2(Tail, PrefTail, String);
> 	strip_prefix2(_, _, String) ->
> 	    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
> 	     end.
> 
> is only one line longer than the ++ version, and seems pretty clear
> (except for the non-intention-revealing name).