errata: An object like **dict *would, of course, be a nice high level option for less savvy users.
Em ter., 10 de fev. de 2026 às 21:45, Alexandre Torres Porres < [email protected]> escreveu: > Em ter., 10 de fev. de 2026 às 20:53, Dan Wilcox <[email protected]> > escreveu: > >> however using a name would suffice and matches existing behavior for >> object-as-datastore. >> > > I think I agree > > > >> The complexity comes if you want to support nested data, ie. if we have >> "key" : "value" is value just an atom or list internally or can it also be >> an array or another dict? >> > > I'm still getting acquainted with all this. Until the other day I never > really had the need to use something like [coll]. But anyway, isn't the > idea nesting a key feature for dictionaries? > > A plain and flat key => value thing is already achievable with [text]. > That's how I built my [messcoll] abstraction. > > >> It so, the it feels like we are reinventing JSON >> > > Yeah, and it's the idea in MAX, where dictionaries are claimed to be what > JSON objects are, and the objects can read and write JSON files. So I guess > it would come down to this particular feature, and with nesting of course. > > >> and is this not applicable to extending data structures in some way? >> >> For these kinds of things, I'd personally rather just wish for a core lua >> external as I feel things start to get away from the patching metaphor. In >> this case, I could script the objects behavior and the data store is >> contained within it. >> > > Well, I did mention that in the beginning of this discussion. So yeah, > supporting lua as a native scripting language would do the trick and also > allow more things. Actually, our bhack project uses lua tables as > dictionaries to do what BACH in MAX does with nested lists. > > Not sure about loading and exporting JSON files, how easy that'd be. I > never needed any of those. An object like did would, of course, be a nice > high level option for less savvy users. > > cheers > > >> >> enohp ym morf tnes >> ----------- >> Dan Wilcox >> danomatika.com >> robotcowboy.com >> >> >> On Feb 10, 2026, at 11:02 PM, Alexandre Torres Porres <[email protected]> >> wrote: >> >> >> Now that I am thinking about it, I see that [text] is kinda like that. We >> don't have a "text" message type, and it is not exposed in the Pd >> ecosystem, right? In a sense, same for "arrays". MAX, in the same way, >> doesn't expose the data type and can use named objects to share data. It >> can output a pointer, but that is coded as regular symbol. >> >> The ceammc approach adds complexity with new data types for nothing as I >> see it now. There are other ways to manage it. Now that I am going for an >> external that handles it, I'm totally not doing the same and will try to >> make something like MAX. >> >> It now boils down to how we could add this to Vanilla and what it means >> in practice. It could also be just like in MAX and we could pass pointers >> as symbols... or is it a not too crazy idea do add a new data structure >> type and have pointers for it too? This is where I'm frying my brain now. >> It'd be an odd case out that we'd have a data type without having them >> exposed as data structures. >> >> One way or another, this can be exposed in the API for externals, it has >> nothing to do with Pd data types on the patch level, right? >> >> cheers >> >> Em ter., 10 de fev. de 2026 às 16:48, Alexandre Torres Porres < >> [email protected]> escreveu: >> >>> Em ter., 10 de fev. de 2026 às 15:13, Dan Wilcox <[email protected]> >>> escreveu: >>> >>>> If we prefer to stick to simple, C-inspired syntax, I'd recommend >>>> looking at Lua's approach with its table data structure. There is beauty in >>>> the minimalism IMO. I am not really of the opinion that Pd should expand to >>>> naturally include every data type to solve every problem in everyone's own >>>> way. For specific problems, that's where an external or scripting interface >>>> comes in. >>>> >>> >>> yeah, so, you think that if we could add these to Vanilla we'd need not >>> to add more data types, huh? I also wonder what is the advantage for an >>> external to create and deal with an extra data type. The might be some I >>> guess but I have no idea and my intuition is that it's best to just treat >>> these as Pd lists with some special syntax. >>> >>> >>>> >>>> enohp ym morf tnes >>>> ----------- >>>> Dan Wilcox >>>> danomatika.com >>>> robotcowboy.com >>>> >>>> >>>> > On Feb 10, 2026, at 5:55 PM, IOhannes m zmölnig via Pd-list < >>>> [email protected]> wrote: >>>> > >>>> > Am 10. Februar 2026 17:21:58 MEZ schrieb Alexandre Torres Porres < >>>> [email protected]>: >>>> >> While we're at it, I'd like to mention the ceammc library, that can >>>> be >>>> >> installed in Vanilla (or you can use it as part of the Pd-Ceammc >>>> fork) and >>>> > >>>> > >>>> > well yeah. >>>> > >>>> > there's also "pdcontainer" (from about 2004) by Georg Holzmann, that >>>> maps c++ std::containers (including dicts) to pd. >>>> > >>>> > >>>> > >>>> > >>>> > mfg.sfg.jfd >>>> > IOhannes >>>> > --- >>>> > [email protected] - the Pure Data mailinglist >>>> > >>>> https://lists.iem.at/hyperkitty/list/[email protected]/message/QRGLHRQDTYORJPNFFTMASFFPWDFOEYW5/ >>>> > >>>> > To unsubscribe send an email to [email protected] mailing >>>> list >>>> > UNSUBSCRIBE and account-management -> https://lists.iem.at/ >>>> > >>>> >>>> --- >>>> [email protected] - the Pure Data mailinglist >>>> >>>> https://lists.iem.at/hyperkitty/list/[email protected]/message/WALVCVGZFLKWQW4OMWK662Y2T4OM5US7/ >>>> >>>> To unsubscribe send an email to [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> https://lists.iem.at/ >>> >>>
--- [email protected] - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/[email protected]/message/XB4M7VVEBCSBQNHX3VYTH52LFPHFG747/ To unsubscribe send an email to [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
