LangWart: Method congestion from mutate multiplicty

[Rick Johnson]

On Sunday, February 10, 2013 6:36:20 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
> > On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
> >> Rick wrote:
> > [...]
> > Steven, the definition of flatten (as relates to sequences) is very, VERY
> > simple:
> > 
> >     Return a new sequence that is the result of reducing
> >     a nested sequence of sequences into a single depth
> >     sequence.
> 
> Very, VERY simple until you actually implement this function, and discover
> that it does too much e.g.

I would implement it as a method of sequence types, but i digress!

> flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])
> => [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']
> 
> So people who have *actually programmed*, instead of just talking about
> programming, have discovered that in practice you need to treat some
> sequences as primitives that don't get expanded.

Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything. 

However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!


I'm not convinced that flattening immutable types is a good idea anyway, because heck, they're designed to be immutable! I suppose if we are not flattening "in-place" it really would not matter though. Creating a new immutable object that is the result of reordering an existing immutable object's values is not mutation.