From: Nicolas C. <war...@fr...> - 2003-04-21 02:41:20
|
> We're already exporting count, export next as well. Why I want this will > be clear in a moment... Ok, but I don't agree : I do understand that you want to remove 'magic' calls from the ExtList, but actualy, the problem is that we are already doing magic calls in setcdr, so why would we need to add a primitive to Enum for that ? But that's not the main problem... The problem is that WE SHOULD NOT export next since : 1) its semantic it is not really defined, and Enum.next does not make sense since 99.9999% of the time you're applying the same function to all elements of the Enum. 2) I don't want beginners start programming using while Enum.has_more e do let x = Enum.next .... done because it's really a BAD WAY ( Java like ) of working with enumerations (and it's involving a call to count each time ! ) 3) There is big problems of exception scoping !! that's the major fact why I hided Enum.next : for example an user could do Enum.map with a function that is using Enum.next, and then call for example Enum.iter on it... if the user-defined map function raises No_more_elements ( because the user didn't check properly for it, or because he simply wants to catch the exception at an upper lever ) then this exception will be catched by Enum.iter which will simply ignore it and stop.... Serious problem here for debugging big piece of codes ! So that's why I did wrote some comment about No_more_elements : (* raised by 'next' functions, does NOT goes outside the API *) so the user can NEVER make it raised ( only by doing raise Enum.No_more_elements by hand in to_enum implementations ). Sorry not to have talked about theses points before, but please revert the changes since I'm feeling really about this addin' :) Nicolas Cannasse |