# BUG Report: ValueTree::getPropertyAsValue::refersToSameSourceAs

**URL:** <https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034>\
**Category:** General JUCE discussion\
**Created:** [April 15, 2022, 7:25pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034 "2022-04-15T19:25:56Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 15, 2022, 7:25pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/1 "2022-04-15T19:25:56Z")

</div>

Hi @juceteam

I found a bug using Value::refersToSameSourceAs with ValueTrees. Basically:

```auto
valueTree.getPropertyAsValue("someid").refersToSameSourceAs(valueTree.getPropertyAsValue("someid"));

```

returns `false` – which I think should not be the case. As far as I can see it can be easily fixed by added equality operations to ValueTreePropertyValueSource checking the valueTree and property members.

Thanks!

---

<div class="post-metadata">

**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\
**Post date:** [April 26, 2022, 1:54pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/2 "2022-04-26T13:54:07Z")

</div>

That’s consistent with the rest of the Value interface. Values only reference the same underlying object if you use the `referTo` method, or the copy constructor.

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 26, 2022, 2:23pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/3 "2022-04-26T14:23:47Z")

</div>

Hm, I’d argue that just by reading the code line I posted it’s pretty clear that the current implementation doesn’t make any sense.

> [@t0m](#):
>
> That’s consistent with the rest of the Value interface.

And making the proposed change doesn’t change anything about the consistency. In that sense, the problem isn’t in the implementation of Value, its in ValueTree::getPropertyAsValue. I think this method should somehow ensure that the refersToSameSourceAs returns true if it is the semantically the same source. I don’t see any up side on the way it is currently as it is highly unexpected.

---

<div class="post-metadata">

**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\
**Post date:** [April 26, 2022, 2:59pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/4 "2022-04-26T14:59:12Z")

</div>

This is the consistency that would be broken:

```auto
var x { "x" };
Value a1 { x };
Value a2 { x };
jassert (! a1.refersToSameSourceAs (a2));

ValueTree vt { "vt", { { "prop", "val" } }};
auto b1 = vt.getPropertyAsValue ("prop", nullptr);
auto b2 = vt.getPropertyAsValue ("prop", nullptr);
jassert (! b1.refersToSameSourceAs (b2));

```

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 26, 2022, 3:25pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/5 "2022-04-26T15:25:50Z")

</div>

I think this is kind of comparing apples to oranges:

```auto
  var x { "x" };
  Value a1 { x };
  Value a2 { x };
  XCAssertTrue (! a1.refersToSameSourceAs (a2));
  
  a1.setValue("y");
  XCAssertTrue(a1.getValue() == a2.getValue()); // fails

  ValueTree vt { "vt", { { "prop", "val" } }};
  auto b1 = vt.getPropertyAsValue ("prop", nullptr);
  auto b2 = vt.getPropertyAsValue ("prop", nullptr);
  XCAssertTrue (! b1.refersToSameSourceAs (b2));
  
  b1.setValue("diff val");
  XCAssertTrue(b1.getValue() == b2.getValue()); // passes

```

The first example is expected to refer to different “sources” as changing Value a1 does not propagate any kind of updates or changes to Value a2 (a2 is still “x”).

But as the “source” of the second example is the ValueTree changing the Value b1 also changes the Value of b2. And I think this is exactly the behaviour that should be reflected by refersToSameSourceAs. I (as a user) don’t really care how that works implementation wise (e.g. is it really the same ValueSource object).

---

<div class="post-metadata">

**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\
**Post date:** [April 27, 2022, 10:25am UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/6 "2022-04-27T10:25:18Z")

</div>

I still don’t think we should special-case the behaviour for ValueTree references. The implementation would also be horrible.

How are you using your ValueTree where this functionality is important?

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 27, 2022, 10:35am UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/7 "2022-04-27T10:35:43Z")

</div>

In general: I’m trying to listen on property changes with a variable id. Simplified, that would look like:

```auto
Value v = valueTree.getPropertyAsValue(variableIdentifier); // stored as a member var
v.addListener(this); // in ctor

```

After the value getting passed along a few times I have to check if I’m getting the correct value. I don’t see a possibility to check what specific property id I’m looking at through the Value interface.

> [@t0m](#):
>
> The implementation would also be horrible.

I think using a virtual function in ValueSource would be a perfectly fine choice. The default implementation would `return this == &other` and the ValueTreeSource can implemented it (after a dynamic\_cast check) with `property == other.property`

---

<div class="post-metadata">

**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\
**Post date:** [April 27, 2022, 10:44am UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/8 "2022-04-27T10:44:31Z")

</div>

Why not listen to the ValueTree itself, or a sub-tree containing just your property?

A virtual function that imposes dynamic casts on anyone that might subclass `ValueSource` is not a pleasant way to go.

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 27, 2022, 10:47am UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/9 "2022-04-27T10:47:29Z")

</div>

> [@t0m](#):
>
> Why not listen to the ValueTree itself, or a sub-tree containing just your property?

This decision was made because ValueTree lacks the possibility of passing a const version of it. Changing that is not an option for me. I can see how the dynamic\_cast is not ideal… But I think how the interface is designed currently, it just doesn’t make semantically sense (as posted in the code above).

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 30, 2022, 9:44am UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/10 "2022-04-30T09:44:53Z")

</div>

@t0m I’ve given it some thought and I think there would be an alternative to the dynamic\_cast I proposed earlier. When all Values from `getPropertyAsValue` would get the same instance to one `ValueTreePropertyValueSource` you would get away with one additional virtual function call. The ValueSource would be given a function to check if a different ValueSource is actually pointing the same internal source after checking that the pointers are the same. The default implementation would be to straight return `true` and the ValueTree implementation can override the call to return true if valueTree and propertyId match.

This _one and only_ `ValueTreePropertyValueSource` instance could live inside the ref-couted ValueTree `object`.

---

<div class="post-metadata">

**Author:** ![nicolasdanet](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/nicolasdanet/32/56_2.png) [@nicolasdanet](https://forum.juce.com/u/nicolasdanet)\
**Post date:** [April 30, 2022, 12:25pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/11 "2022-04-30T12:25:50Z")

</div>

Why not just wrap `Value` in a custom class that fit your need (that i didn’t really understand TBH)?  
I almost always decorate `juce::Value::Listener` and `juce::Value::ValueSource` to perfectly match my requirements. Sorry for hijacking your discussion.

---

<div class="post-metadata">

**Author:** ![Rincewind](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rincewind/32/10645_2.png) [@Rincewind](https://forum.juce.com/u/Rincewind)\
**Post date:** [April 30, 2022, 12:30pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/12 "2022-04-30T12:30:20Z")

</div>

Its ok, thanks for the suggestion! I was also thinking of doing that but I wouldn’t gain any benefit from doing so. `juce::Value` already provides me with exactly what I need, a setter, a getter and the possibility to listen for changes. The only upside would the type safety I guess.

But I think this all just covers the fact, that I’d like to be able to check if two values point to the same source and this is not possible even though there is a method of claiming to do that 🙂

---

<div class="post-metadata">

**Author:** ![nicolasdanet](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/nicolasdanet/32/56_2.png) [@nicolasdanet](https://forum.juce.com/u/nicolasdanet)\
**Post date:** [April 30, 2022, 12:37pm UTC](https://forum.juce.com/t/bug-report-valuetree-referstosamesourceas/51034/13 "2022-04-30T12:37:41Z")

</div>

> [@Rincewind](#):
>
> The only upside would the type safety I guess.

Personally i use templated wrappers to check that (at run-time sadly).  
And with time it appears that i add more features that make the raw juce::Value unappeal anymore.

Anyway i don’t have any opinion about you original question/suggestion. I guess that ValueTree is the kind of master piece that is hard to change without pain!