Mon Sep 29 23:25:54 CEST 2003
Chris Pressey wrote:
> Joachim Durchholz <joachim.durchholz@REDACTED> wrote:
>>Chris Pressey wrote:
>>>Joachim Durchholz <joachim.durchholz@REDACTED> wrote:
>>>>Personally, I think that opaque data types should also interact
>>>>with pattern matching, i.e. there should also be "deconstructors".
>>>>For example, the Dictionary type should have something like a [H|R]
>>>> "destructor" that gave me the first pair (H) and the rest of the
>>>>dictionary (R), so that I can pattern match as in [(Key,
>>>Well - maybe, but I don't see how it really fits in with the opacity
>>>- if you're not supposed to know anything about the structure of
>>>some value, then you probably shouldn't be taking it apart yourself, even
>>>in an abstract way.
>>The key is that the designer of the type defines in which ways it
>>should be taken apart.
>>For example, a Customer data type could have different "views":
>> Customer_by_address (Name, Nr, Street, Town, ...)
>> Customer_by_standing (Name, Nr, ABC)
>> Customer_by_history (Name, Nr, Transaction_List)
>>The nice thing here would be that it would be possible to extend the
>>Customer data type without having to rewrite all the code that does
>>pattern matching on Customer data, as long as the new data didn't show
>>up in the new views.
> Well, it's a very intriguing idea, but I'm still a bit trepidacious.
> The thing is, currently if you have code like
> function(A=[H|T]) -> ...
> you know for certain that A *is* a list. Now if other data types can
> match [H|T], A could be, well, anything.
> That's maybe not a practical problem though, and I definately like the
> general idea. I'll try to give it some thought.
Not a problem in practice - syntactically, a view would be the same as
(or similar to) a function, and one can and must use the same rules.
In other words: if [.|.] is a list "view", you can't use it for
something else; you'd probably use some other name for deconstructing a
dictionary (yes, the example chosen above was unfortunate).
[snip discussion on more-or-less idiotic backwards compatibility issues
- I'm sitting quite comfortably on both sides of the fence in this issue...]
More information about the erlang-questions