From: Mathieu Bouchard <matju@...>
Date: 2001-02-21T01:52:43+09:00
Subject: [ruby-talk:11177] Re: MetaRuby 0.5

> matju what do you think about organizing the different
> functionalities of lists, queues, stacks and particularly 
> sets (the build in semantics is a bit arbitrary) into 
> different modules?

It depends on what benefit there would be to. I organized such methods
into categories (similar to smalltalk "methods for"). However I have used
a six-module architecture:

ListMixin #(common to Array and String)
ArrayMixin #(includes ArrayInterface, ListMixin)
ArrayInterface #(the basic operations that are left to implement)
ArrayInterfaceSafe #(assertion-checked version of the preceding)
CommonAssert #(used by ArrayInterfaceSafe, StringInterfaceSafe)
ArrayUsingArray #(dummy impl of ArrayInterfaceSafe, includes ArrayMixin)

As you see, methods are not divided according to individual purposes but
according to a larger scheme of small interface vs large interface /
interface vs implementation vs verification / shared with string vs
specific to array.

The "set operations" in Array are somewhat more restrictive than set
operations. See [ruby-talk:6756], [ruby-talk:6723]. Order of elements is
important (repeating elements do collapse, however).

I don't see the usefulness of putting lists/queues/stacks/sets
functionalities in different modules (that i'll have to include into
ArrayMixin to respect the builtin Array protocol) if there is nowhere they
can be reused.

The "set operations" could be somewhat reusable in another context (though
they could be optimized out of their restrictions in those contexts, and 
#uniq would become irrelevant, etc).



May I know what you have in mind in a detailed fashion?



> Your implementation of flatten seems to throw a "self -
> recursive flattening exception" when it encounters a 
> self recursive Array (the simplest  example is 
> x = []; x << x ) - maybe the build in semantics should 
> follow your implementation?

The builtin semantics follow my implementation.

Or rather:

My implementation follows the builtin semantics.

It's just that when you try to #flatten! an array that immediately
contains self-references, it skips them as a special case (i don't know
why Array#flatten! does this). However when you do #flatten, a dup is
performed first, then #flatten! is called on the copy, and so the
base-level self-references are not base-level anymore, and #flatten!
explodes.



matju