[PD] [pool] question

[Thomas Grill]

Hi David and all,

> In the documentation (pool.pd and elsewhere) you talk about 
> "directories"
> and such.  But when I send a "mkdir" message, a directory is NOT 
> created on
> my hard drive.  I'm assuming then that I'm misunderstanding the
> nomenclature.  I've never used the [coll] object in Max.
>

All the operations on the pool object are in-memory. "Directories" 
provide just a way to organize data in a hierarchical manner.

> Here's the question:
> Pool is really managing "arrays" or "dictionary" objects right?  I 
> mean KEY
> + VALUE pairs in the Visual Basic world are referred to as 
> dictionaries.
> Arrays are values organized by 'index' (or in this simile: 'keys' 
> which can
> be named).

"Dictionary" would be appropriate, yes.
In the moment a usage for indexed "arrays" is not efficient... pool is 
in its early stage and all searches are done linearly. In the future i 
plan to use some efficient algorithms that can handle sparse data 
equally well.

>
> So in another sense, Pool and it's ability to 'mkdir' etc. is 
> simulating the
> creation of database tables right?  Or perhaps another analogy might be
> "recordsets"?  I'm grasping a little here, but even in this early 
> version of
> [pool] I can already understand ways that I can simulate columns and 
> rows of
> records and even store information in different 'directories' as you 
> say
> (which seem a lot to me like 'tables').
>

Hmmm , i'm not good at database stuff, but i guess that's true, 
although rows and columns is no good analogy.
Matrix (or n-dimensional rectangular) data is not (yet?) handled well.


> I understand that all the data is held in memory until such time as I 
> want
> to commit the data to a file on my drive via the "save" method.  When 
> I do
> this, it's sort of like saving the database tables in a .dat file 
> right?

Yes.... hopefully one of the next versions will bring XML support

>
> I realize that [pool] is merely in its first version (and is already
> awesome!) but I wonder if there are plans in the future to:
> a) allow the values to be returned by index (a la Visual Basic 
> dictionaries)
> in cases where we might not know the KEY name...but we now it's index.
> b) allow control of a cursor (a la recordsets) so that operations like
> "movenext" or "movefirst" might be used?

Yes, that will definitely be included. I have yet to see how that can 
be done efficiently since there is no internal indexing in pool.

> p.s.: I know I know I know...give me an inch and want a mile right!?
> I suppose I'm just really excited about this object.  It's already 
> useful in
> a million ways.

Well, that's just ok! One always needs a bit of stimulation...

best greetings,
Thomas