Class name suggestions?

Love that idea. I’m using a range of XML based data classes and associated library classes, and had to give up undo right now - best I found was to store the prior value and send the prior and new value as xml denoting a change (store that as an undoable action).

Couple of things Haydxn added for me that I’d put in as feature requests was the ability to get and set values using a ‘path’ object, similar to Xpath. That could specify the object, to be looked up in an array, and the path to data within the object. He also made a library class, so a bunch of these tree/data items can be managed and accessed by type and ID.

Please also add a version number and a strong ID (like a database key) to the items, and consider a hook for every time the data changes (although a listener covers that mostly) so the data can be shared (I send changes with XML to remote machines).

I won’t burden you with any more name ideas. Mine would have been silly anyway.

Bruce

Your path suggestion sounds interesting, but I don’t quite get what you mean…? Is it a path for finding a sub-node in a tree based on the names of their parent nodes, like a file path?

As for ID and versioning, I can’t really see the point of baking them into the classes when you could just as easily just give your nodes “id” or “version” properties if you need to. But when I’ve got the first version out, maybe have a look at it and let me know if you still think it’d be a useful feature.

My current favourite for a name is ValueTree, which is a bit dull, but I just can’t find a better one, and it’s starting to drive me mad now!

Call it Larry.

The path stuff looks sort of like:

dataLibrary->setDataValue (itemID, XmlPath(T("/sounds/bass/@gain"), +2.0);

In fact, itemID can be more complex. The library is a class that holds, stores, saves etc. and funnels data settings.

How about in your class, something like:

TreeStartRefCountedPtr->setValue[Relative] (String pathToProperty, var value);

Sort of like all the other get/set in the library.

Here’s another request - please support attributes and main values, so we can go to and from XML as needed. Maybe just a falg in the value to say it’s to be saved as an attribute not a child?

Formalizing ID helped for me, as it’s all data, and it’s shared. It means that data in different machines can match up items - very like a database. Version numbering was for a similar reason. That can be added with a listener.

Not sure about IDs. They aren’t elsewhere in juce, afaicr, so maybe not, but if this is meant to be a global data class (which would be really, really great), then at least a distinct key field would be standard, and should help with reading and saving from file etc. Relying solely on placement in an XML file would be hinky, and removes the ability to sort the data and keep it sorted.

Hmm, thinking again, maybe that doesn’t map too well, unless every single element has an ID (that’s not what I meant). Probably you’re right. If you do have occasion to make a class that holds a flat list of ValueTrees, then each holding node should have a strong key, like in jucer if you made a list of ‘windows’ or ‘classes’ that live at the root of the document the user is working on.

What some systems do, I’m sure you know, is link dataSources similar to this to controls (like tables). Is that something you have in mind? Like linking to a table and property panel?

Bruce

PS - DataValueTree

Bruce

Hi Jules.

Well, I just dare to suggest a few names for the class.

SolidBunch or SolidTree (with SolidNodes)
LiveTree (with LiveNodes) - as it feeds back
MetaTree (with MetaNodes) - as it’s more complex than just a tree
MorphTree (with MorphNodes) or UniTree (with UniNodes) or FlexTree (with FlexNodes) - as it stores unified or flexible values

…or even recombine them like LiveMetaTree or MetaFlexTree or UniFlexTree or MetaProperty or something :roll:

Julian, please, stay sane. we’ll help! :smiley:

EasyNode

Bruce - I think you should take a look at my first draft and see what you make of it, as it’s doesn’t quite fit with some of your suggestions, but there are probably equivalent things I could add. I’m totally open to ideas on this one, and the first version of it might not be how it ends up looking.

I do quite like “LiveTree”, but have got “ValueTree” in my brain now…

Leaf ?

I did consider leaf for a while too… and “Fern”. But in the end, went for ValueTree. The code’s up there now if anyone wants it.

I guess my vote goes for EasyNode, DataNode or VarNode (or Element). I’m a big fan of metaphoric names, but I can’t think of anything that isn’t either too contrived or too generic!

(also a fan of short names- especially if it’s something that is to be as ubiquitous and oft-used as this! I can’t wait! :))

[quote=“haydxn”]I guess my vote goes for EasyNode, DataNode or VarNode (or Element). I’m a big fan of metaphoric names, but I can’t think of anything that isn’t either too contrived or too generic!

(also a fan of short names- especially if it’s something that is to be as ubiquitous and oft-used as this! I can’t wait! :))[/quote]

Sorry, way too late on the the name ideas! It’s called ValueTree, have fun! (Caveat - I’m still testing it, there are almost certainly bugs to fix!)

:smiley: that’ll teach me to read the forum on my iPhone :slight_smile: didn’t even notice the tiny page buttons and didn’t look at the dates :smiley:

hope to have a tinker soon, it’s been a while since i’ve had a chance to play with juce properly.

Yes I know that it is called ValueTree, but if the killer feature is the undo stuff, then the name doesn’t say that.

Maybe: HistoryTree or UndoableValueTree

/Okku

Well, the other killer feature is that it can take listeners… but UndoableListenableValueTree is a bit long!

I know it’s a little too late, but you do have a class named “ApplicationCommandManagerListener” & “DirectoryContentsDisplayComponent”. As long as name gives certain clues about what the class can do, I wouldn’t mind having long names.

Long names are good. Unless you need to type them very often, and then it can just make your code look a bit unwieldy!

I’ve been writing some code with ValueTrees now, and because its role is as a pervasive “building block” class, even that name feels a little long.

That is a trade-off. :frowning:

Can’t help it.

I’ve gotten spoiled with the ‘auto suggest’ features on modern editors (Visual Studio + Visual Assist rocks) and rarely have to type full names of anything anymore… :slight_smile:

It’s not just Visual Studio, even Xcode supports it. :slight_smile:

But it’s also true, huge class names stands out in the code but they are also helpful in understanding the code.

I’m trying to use the new class but i don’t understand why it doesn’t restore correctly from file.

I’m saving it like this:

ValueTree parent("parent");
        
ValueTree child("child");
child.setProperty(var::identifier(T("name")), var(T("huraken")), 0);

parent.addChild (child, 0, 0);

ScopedPointer<OutputStream> stream (myFile.createOutputStream());
parent.writeToStream (*stream);

And i’m restoring it like this:

ValueTree parent("parent");

ScopedPointer<InputStream> stream (myFile.createInputStream());
parent.readFromStream(*stream);

but when i restore it, i cannot see the child subtree… i’m doing something wrong ? probably i’ve overlooked something in the documentation…