Re: [Oorexx-devel] Considering adding a new collection class.

[Sahananda (J. W. <sah...@wi...>]

Hi Rick,

this seems like a really good idea to me.

I often use the table class with string indexes as I don't need the extras
in the directory class, but when I do need them I really appreciate them.
 I particularly use the unknown method to create a caseless index or to
initialise data on first call (see my 2009 symposium presentation).

Jon


On 17 July 2014 11:42, Rick McGuire <obj...@gm...> wrote:

> I've been doing a bit of work on the collection classes this week, and
> just got to the directory class.  The directory is most frequently used as
> a collection class where the indexes are string items, but it also has the
> additional feature of the SETMETHOD() method, plus some additional methods
> that uppercase the string name and the UNKNOWN method that allows the
> "dir~name" syntax.
>
> Until I started reworking this code, I really didn't appreciate how much
> of a "tax" the possibility of "SETMETHOD" imposes on directory objects,
> even if you are not using the feature.  This gets involved in every
> operation and has particular overhead for things like allIndexes() (thus
> impacting DO OVER performance), and allItems().
>
> I'm thinking there is a need for a StringTable class that is closer to the
> other collection classes.  This will not have setMethod(), but I think the
> UNKNOWN method would still be a good idea.  With the restructuring of the
> hash collection code I've been doing, this would be a fairly trivial
> addition to implement...probably more work to write the test cases and docs
> than to write the code.
>
> One of the nice things about oo programming is the ability to switch to an
> implementation of a class that best suits your usage.  The directory class
> has enough additional overhead that this is one place where this choice
> would be appreciated.
>
> Note also, that this advantage will translate to the internal performance
> of the interpreter. Directories are heavily used inside the interpreter, so
> replacing a lot of these uses with a StringTable will also give a
> performance boost.  This alone will justify at least creating the internal
> class.  However, for some of those situations, the internal directory is
> "handed out" as return values, so the StringTable class would need to be
> one visible to ooRexx programmers as well.
>
> Rick
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>