[#10209] Market for XML Web stuff — Matt Sergeant <matt@...>

I'm trying to get a handle on what the size of the market for AxKit would be

15 messages 2001/02/01

[#10238] RFC: RubyVM (long) — Robert Feldt <feldt@...>

Hi,

20 messages 2001/02/01
[#10364] Re: RFC: RubyVM (long) — Mathieu Bouchard <matju@...> 2001/02/05

[#10708] Suggestion for threading model — Stephen White <spwhite@...>

I've been playing around with multi-threading. I notice that there are

11 messages 2001/02/11

[#10853] Re: RubyChangeRequest #U002: new proper name for Hash#indexes, Array#indexes — "Mike Wilson" <wmwilson01@...>

10 messages 2001/02/14

[#11037] to_s and << — "Brent Rowland" <tarod@...>

list = [1, 2.3, 'four', false]

15 messages 2001/02/18

[#11094] Re: Summary: RCR #U002 - proper new name fo r indexes — Aleksi Niemel<aleksi.niemela@...>

> On Mon, 19 Feb 2001, Yukihiro Matsumoto wrote:

12 messages 2001/02/19

[#11131] Re: Summary: RCR #U002 - proper new name fo r indexes — "Conrad Schneiker" <schneik@...>

Robert Feldt wrote:

10 messages 2001/02/19

[#11251] Programming Ruby is now online — Dave Thomas <Dave@...>

36 messages 2001/02/21

[#11469] XML-RPC and KDE — schuerig@... (Michael Schuerig)

23 messages 2001/02/24
[#11490] Re: XML-RPC and KDE — schuerig@... (Michael Schuerig) 2001/02/24

Michael Neumann <neumann@s-direktnet.de> wrote:

[#11491] Negative Reviews for Ruby and Programming Ruby — Jim Freeze <jim@...> 2001/02/24

Hi all:

[#11633] RCR: shortcut for instance variable initialization — Dave Thomas <Dave@...>

13 messages 2001/02/26

[#11652] RE: RCR: shortcut for instance variable initialization — Michael Davis <mdavis@...>

I like it!

14 messages 2001/02/27

[#11700] Starting Once Again — Ron Jeffries <ronjeffries@...>

OK, I'm starting again with Ruby. I'm just assuming that I've

31 messages 2001/02/27
[#11712] RE: Starting Once Again — "Aaron Hinni" <aaron@...> 2001/02/27

> 2. So far I think running under TextPad will be better than running

[#11726] Re: Starting Once Again — Aleksi Niemel<zak@...> 2001/02/28

On Wed, 28 Feb 2001, Aaron Hinni wrote:

[ruby-talk:11177] Re: MetaRuby 0.5

From: Mathieu Bouchard <matju@...>
Date: 2001-02-20 16:52:43 UTC
List: ruby-talk #11177
> 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

In This Thread