.Net Foundation Design Reviews, 19 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: JSON DOM (1)

Description

Continued in https://youtu.be/JVKNdfFC4bI.

A

A

A

Hello friends uh welcome back to our ipr review. uh Today we are going to focus first on a writable, dom and dynamic support in json 4.96, and then this will be takes an hour and then we will do the remaining issues.

A

um I think if the doc opens already yeah steve, do you want to walk us through it because you wrote it right you're, not sharing, I'm not showing your screen again. Okay,.

B

Just a couple, um some history, I guess on it before we open up the shared dock. um Originally, we uh we wanted to support dynamic and um oral and it missed schedule. So we hunted it and we got a lot of feedback um from the community along the lines of um you know.

A

We really need this and.

B

I'm blocked because of not having support for dynamic, so.

C

B

Create a quick plug-in model that you could use all the way back to 3-0. That does support dynamic in a rough way um and.

D

B

That, then, I created this document. That is an attempt to formalize the requirements and then add it to 6-0. However, in in kind of in the meantime, this is described a little bit in the dock.

B

um There's some overlap with on prior work, including the prototype that we had in the four-wheel time frame, we're on writable, dom um and then also my prototype and then some some some other thinking around dynamic and on writable dom as well. But in general. This.

B

This doc then combined two things to combine the um the dynamic stuff and the proposed writable, dom the previous support or proposal that we had for writable dom in the four time frame, which wasn't prototype stage and went in our repo for a little bit and that was pulled out um did not have support for dynamic.

B

So if we had a dynamic um after that, we would have had yet another way to get a writable dom. So this proposal attempted to bring those um requirements together into one design, and this.

A

B

The api dock- um this is more of a discussion, um doc design dock, so I'm I'm still assuming there'll be another api doc. After this meeting.

A

Yeah, that makes sense, um so I guess this is more than the document- that's kind of capturing. What it is that we want to achieve then 4.6.

B

Are you sharing it.

A

I thought I did did I not.

D

um It says I mean team switched to a mode that suggests he's sharing, but it's not sharing anything.

A

Okay, then, let me just share my entire screen. Maybe that works better.

B

I can paste a link here too.

A

So now it says I'm sharing screen, so you should see the doc and uh the comments.

A

C

C

A

Does it work for everyone or is it just corey can see it right.

E

It just popped up for me. All right, then take it.

A

B

Okay, yeah, so the overview.

A

B

Kind of what I went over, we had a prototype and fireball.

B

Disappeared um so that first bullet says yeah the writable dom prototype, and I did mention that um dynamic support code example. This is the example I added for those that said they were blocked and it basically uses a custom converter to override um the behavior first system.object.

B

It works pretty good. I think, um then, the azure team also has um a prototype and I think a package you can download and use that has um yet another version of writable, dom it's more tuned for performance and.

C

We have been working.

B

With them- and they do want to take the the whole dynamic model c, sharp dynamic support and system link expressions dll. They want to take that and move it forward. So they're actually working on that and I'm trying to stay in the loop on that.

B

But that's kind of disconnected from this effort right now other than we're asking asking that team to review this here, a um 6-0 time frame, um it's kind of understood that any kind of new dynamic support, probably won't be there in time for 6-0, since it spans um c-sharp and um roslyn releases.

B

So um so these three things are all influencing the stock. um But again this was originally created for support for dynamic, which is a loosely typed model. um You know it look. It looks like it's strongly, typed, of course, but it's not and based upon some feedback um in this design. If you, if you go- and you know, click the link that leave my shirt, that you'll see that james um jameson, king and and um others have said that we need a more loosely type model than what I originally had.

B

So this has been updated to um minimize the number of casts. You need so it's a lot less strongly typed than the uh the writable dom prototype that we had in fibo.

B

So it's just kind of that mentality, I think, is something that we need to discuss, because when looking at the apis, they're focused around more of the dynamic scenarios and not a you know a rigid dom model that we have for um for jason um for the the uh existing dom support that we have, which is read only today with json document and json element. It's very rigid model, um very nice. If you know exactly what your scheme is not so nice, if you just want to write minimal code, okay, so yeah.

B

If you want to scroll down and talk about this dynamic section a little bit.

B

Okay, this is just discussing some plumbing um to get the dynamic support working if you're not familiar with the dynamic um I'll try to describe that a little bit here. There are implementations to support dynamic, including dynamic object and expandable object.

B

We looked at using both of those are either one of those for 6-0, but I list some reasons why we don't want those- and this is also true for the effort going on on by the azure team- that they couldn't use these classes for primarily for performance, but also because they tend to clutter up the api.

B

They have a lot of unnecessary methods for interface, um interface-based methods that you have to that will show up in that intellisense.

B

um So the low-level way to implement dynamic is to support. I dynamic meta object provider and that's what this prototype does and what this document assumes right now.

B

It also assumes that, because of linker support that we don't have to have a reference to system link, expressions dll where this interface lives and really all of the plumbing for dynamic lives.

B

So originally, in this prototype, I had a way that I had two assemblies um are an extra assembly that I added to support this dynamic support. However, talking to um those that work on, the linker was decided that that wasn't necessary and that the assembly reference we have to system link. Expressions would go away for not using this feature.

B

That's assuming a certain programming model to enable dynamic which we'll get to later. um Basically, the system link expressions deal is very large and scenarios such as blazer client. um They don't want to bring along this if they're, not using the um feature dynamic feature.

B

Okay, I can scroll down here a little bit. I talk about the system link, expressions on assembly and there are. There are two aspects to this here. um That are two different ways to think about. This is that we have an api, it works without dynamic, and then we have the same api that works with dynamic more under the hood. If that makes sense. So um even though we have a writable dom that uses dynamic, when you want to use dynamic, you can still use writable dom without dynamic, so dynamic support is enabled at runtime.

B

If you want it, if you don't want it, you still get the benefits of the writable, dom it's just can't you. It doesn't have the dynamic features that make sense. So that's what does enable dynamic type types method is for um it's assumed to be called, I'm not sure, what's static right here,.

A

So I'm going to understand, so the idea is that the user has to call this method somewhere in the code and then and that's the case. Then we know we can't link away. Systemic expressions is that is that the way to do it right.

B

Yeah- and I don't know why these are mark static, um just this classes methods. I think this is the type one.

A

I see and then it doesn't really matter when the like it doesn't matter how the method is called. It's just anywhere in the code doesn't mean that's under under an if statement.

B

Well, it does have to be called um before you use the options class just like today. um You can't change the options once you you know serialize or deserialize. It needs to be called. It should be called before that otherwise you're gonna get. I think some odd behavior.

A

So I guess what I'm asking is: does this thing do anything or is it just the marker for the linker.

B

It's mostly marker for the linker again.

A

B

Mean what it does do one um thing: it adds a custom converter to the options class.

A

B

So if you don't call this like, it won't.

A

Work, no matter whether the link can be moved or not,.

B

The the support for, um let me think about this for a second.

A

B

Support for system object, I do I I have to look at what I wrote. It's been a couple months here since I I think I've updated this, but I believe the current thinking is that this will add a custom converter for system.object that enables dynamic support um and it doesn't. It can't contain an if statement it has to work with the linker.

B

That's why there's no like uh bull property or anything like that. Instead, it's just a method like this, because um if you try to make it a bull, you know the linker.

F

Another option here is to use what we call feature switches, which is like more or less like at your your build time or your publish time, you can set up an option to say either turn on or turn off this feature whatever it is by default like if this is only for linkability, there's other options than public api.

F

It's basically what I'm saying.

A

Yeah, I guess it also depends whether you want to opt out or opt in right. So if you like, I think if it's an opt-in which the api kind of implies, then you link a switch, might be odd because you know if you're not using it.

A

Even if you don't use the linker, but if you don't call the method, dynamic types just wouldn't work at all right, and so, if you, if you want to make people, if you, if you want, if you don't want to pay the penalty for it by default, then an api makes sense. If, if we basically want the behavior, where dynamic types just work, unless you say for the linking, I really don't want this, then I think the link option would make more sense.

B

I mean if it's.

D

Adding a custom converter then steve my recollection is: this type is self-closing like once you do serialize the first time it it starts, throwing if you modify it so this does under your current thinking, have to be called before the first call to de-serialize. Otherwise, you'll get a the serial. The options are closed for changes exception and it wouldn't do anything.

B

Yeah and I didn't verify the existing code, it does add a custom converter for a system object so yeah, but yeah jeremy, you're right that it does.

B

It does have that behavior I mean you have to use it before you survive serialize, mainly because it's adding a custom converter and you can't add one after the fact after you start serializing, because we have internal caches and things that would you know, need to be cleaned up or refreshed.

C

It seems like you might run into weird dependencies making sure it's called before whoever needs it. First.

D

Well, the the proposal here is wrong. It's not static. It's instance on an options. Instance class.

C

Oh, so you would call this for every instance of the serializer options you wanted to use dynamic on.

B

It's very similar to all the other options that we have on on this class. um You know if you want to set a property name and policy or ignore null or anything like that. You just have to do it at the same time, you initialize this.

B

B

Okay, so far seems reasonable. Okay, so you want to scroll down to the next.

B

Page um so yeah simple code, yeah, it's not a static method, so sorry I'll just call the instance method and here's an example um of using the dynamic keyword with um json node, and you know if you're not familiar with dynamic. The dynamic keyword here uses it understands it, but but really um it's looking at this interfaces using this interface that I mentioned earlier um to address my prop here. My prop is, of course, not a property on json node, but it is present in the json.

B

That makes sense.

F

What happens if you don't call enable dynamic types like in this code sample, if you comment out that part.

B

um You'll get an exception because the type in return doesn't implement that interface.

F

On what line on the call to deserialize.

B

Yes or after after you, serialize returns and the c sure attempts to use an interface.

F

Also on the next line, when I try to get.

B

On the line that has dynamic, you will get the exception. It's just a matter of you know on assignment, I guess the deserialized will say fine. I can deserialize jason note, but then c sharp is going to try to cast it to this interface and if it doesn't implement that interface um c-sharp will throw an exception.

B

But you know this is interesting, because if you remove, if you place dynamic with json node, it will work fine because you're deserializing json, so you and that and that's the case of not using dynamic um and you then then you wouldn't need the first to lose the code either.

B

But this is just saying this is how you deal with dynamic at the highest level, the jason node um key parameter for deserialize in theory that could be object or it could be um even the dynamic.

A

B

And I talked about that in the next thing that says during the t and d serialized t it's just a matter of syntax. I think having json note here is one way to do it. You could say object or dynamic. um Probably object makes the most sense for the dynamic, if you put, if you use dynamic, as the t parameter is equivalent to object, um but anyway, this is just different syntax for the same same thing,.

A

So what happens so can I actually say json still as a dot dc lies off dynamic.

B

Yep yep and that's the same as using object. I run time um that that dynamic changes into object for the for generics right.

A

B

The difference between the two there.

A

So but like we handle this right, so if you say off object, you would still give you something that would support dynamic and basically is an instance of json node. I guess right.

E

B

You um say that again for the which, which option.

A

So, basically, if I say, json still has a dot dc lies of object or dcls of dynamic. I guess that is logically equivalent of saying json node. So basically, what we give you back is an instance of json node that then, by extension, supports dynamic so long here.

E

Enabled right, yes, exactly yeah! If you enabled um dynamic.

A

Types, so what what happens today, if I say using the dcls of object like it's? Presumably that also works. It just doesn't do anything meaningful.

B

No, it does because we have a custom converter today for object um that returns json element. So this without the you know the um call to enable dynamic types. What you'll get back is json element. If you.

A

Specify so that means, if you I see so so it's a bit more than just enabling dynamism, you're, also, basically saying well now I want a different behavior for visualization of object, because otherwise it would be a breaking change to give you back something to break.

B

A

Json, rather than json element.

A

B

Okay, you can scroll up the next section.

B

There's just more samples here um supporting non-dynamic to dynamic. By the way we did have a tiny, tiny review a couple three months ago and with jeremy um just to kind of go over. Some scenarios has changed since then, but one of the asks back then was if, if you created a non-dynamic json node and want dynamic support, it would be nice to um be able to do that. So this is just a little piece of trivia.

B

Maybe it's coming too early in the dark here to talk about this, but there is a proposal to add um to dynamic method, but let's just skip over that. For now. If you don't mind.

A

B

The reason why I want to skip over it is because of the steady class json extensions which I did not clean up in this last um commit. I should have removed that and just added it somewhere.

A

Else, the presumably json node is your representation for the mutable, dom right.

B

Yes, yep the base class for the writable. Dom types is abstract class.

A

And then dynamic, js, node and json object are basically just derived types that add the dynamic support to it. Right.

B

Right right and yeah, eventually we'll get to the api section that kind of talks about that, but yep, that's the um json node is the base class and then there's just a value. Json object and json collection that derived from that.

A

Yeah yeah, I guess my question was more like there is no inherent penalty for using the dom f towards dynamic right so like I can use the dom without paying for dynamic. In the same way, I can use the cls without paying for it.

B

Okay, um let's see this section.

B

um Talks about some scenarios for the writable dom one of the interesting things that we we ran into the sterilizer is like impedance mismatch between the json and the object mod. The clr object model, so you can have, for example, in json, a number um adjacent number and normally that would relate to a double or int or whatever. On the clr side.

B

However, there's a feature that said: hey, we want to be able to use strings and json as numbers quoted numbers we've been calling them, so that means adjacent string is not always a string on clr type. I mean it might be a number, that's always been kind of true for other things, like new values and and stuff. Like that, you know, a string on this represented can be represented.

B

I mean uh a string can be used to represent an enum and it can also now be used to represent a number. So it just adds um a different way to think about the object model here, because a json number may not be um it may be a string adjacent or maybe adjacent number.

B

So this design talks about that um shows examples of be able to convert between different representations of a number.

A

So that's interesting because I would naively assume that the dom is a representation of the json encoding right and so then to me the fact that the class supports quoted numbers is more like a policy on top of the dom. If you will so I would I mean I would have naively assumed. If you have, you know a property. You know key colon.

A

You know some quoted string. That happens to be 1.2, that you know if you parse it as the dorm, you basically get back adjacent string for that and then, while you, if you.

B

A

Support for quoted numbers, then whoever interprets the dom would have to do the heavy lifting to convert them. But you're, basically saying when I when I use the serializer and I enable quoted numbers, I would actually get back an instance of json number, not of json string.

A

B

I mean json number represents um a number and you can obtain that through a string or through you know, a primitive number type. I I think um scroll up a little bit, so we get the whole.

B

Examples: okay, so here yeah we have jason number classes, saying deserialize the number of the string and then it's asking for the double value. Another interesting thing with numbers in particular, is that the json for for something like a floating point, number or 1.2 I mean.

A

B

Doesn't have any any concept of a floating point versus um standard number? I mean it loves decimal points that sort of thing, but it doesn't know if it's a double or a float or a decimal.

B

So json number allows you to ask for it and.

A

B

Element, you know the existing json element allows you to do the same thing.

B

We just know it's a number and you have to know what it is, because it could overflow we could underflow and um that's why we don't assign median and json element, unlike newtonsoft, I think which, which we'll try to use a double by default when you deserialize the number, there's no default definitive type for that, and this is just going over some examples of that an nan, not a number is a string, and this is another case that we had to add um support for in the json serializer is here we have a number and a n.

B

You know positive infinity, negative infinity or two other values, but it's a string jason allows a string, it doesn't care, doesn't even know it's a number right, uh it's a strength json, but we treat it as a number, because um that's what you know floating points support. So it's really ties in. I think some of the other requirements that we already have that are not possible today, with uh like jason element. Probably would I don't think work very well with this jeremy?

B

Can correct me if I'm wrong, but I think you can convert a string to a number.

B

A

So one question I have is like your sample code is always using this. You laser. Do you think that the primary way you actually construct the dom is by calling d serialize rather than calling something like you know, jsonobject.parse or.

B

B

Well, I mean you, you could I mean, but this is assuming jason right.

A

Right, like I mean I'm just saying when I have a dom representation, I I wouldn't think of using the decelerator to construct.

B

It right yeah, yeah. The examples here are purposely very trivial, like yeah, this 1.2 is valid json, but it can also be you know, a literal value. You'd use something like a parse method, but yeah it's just. For example, only I mean imagine that being part of the larger json document.

A

Yeah, I don't know like I'm kind of torn, because, basically, if you, if you want to on one hand side, I can understand why you want the behavior that you say quoted. Numbers are passed differently based on civilization options but like if you, if you think of the dom as something that you parse independently.

A

It seems a bit weird to me that we have behavior where the parse tree differs based on. You know, civilization configuration effectively. That seems odd, like because to me I mean, maybe I'm just you know old-fashioned but like, if you think of, like you know, lex england, putting them parsing and then you know, steel eyes are like. I would think that you know lexington parsing is independent of rules like oh, we support quoted strings right.

A

I would, I would think, that's a later thing on top, rather than you know, resulting in a different, dom kind of thing, and so, if you, because now the question becomes, if I have something json element.wrong thing like jsonobject.jsonnode.parse, then in order for you to support this behavior, you now have to effectively design what are the options that can pass to the pass method, and that seems now well either duplicate effectively the json field, other options or you have to support them.

A

But then it's kind of weird, because there's a lot of things on the json options that have nothing to do with a dom right. So it just do you know what I mean like? It seems like it's just the wrong layer to do this kind of work.

B

I I think I think I understand what you're saying I I would say, kind of backing up here to the my original statement about being more loosely typed, I mean you can imagine that we don't have this decent number type. We just have json um value, for example,.

B

But yeah, let's keep going. I I I get that, um but the purpose of this is to it's kind of like what comes first dynamic or maybe a strongly more strongly. Typed program model this design, because it was originally created to support dynamic, assume, loose typing and casts when you need them, and it assumes.

F

B

What the types are just like when you use dynamic, you know you know, for example, a certain property is an integer. If, if it's not an integer, normally, when you use dynamic, I mean you can implement dynamic in many different ways, but normally the consumer of it knows what the given type is in the json um and it's not something that you inspect at runtime, you just hardcode it and that's the problem with dynamic in a way because you can write, you know beautiful code that looks and it compiles fine a runtime.

B

You know you can certainly get cast exceptions and you know missing property type stuff and that's just the nature of dynamic and.

A

I guess that's my mental model like I I would. I would have assumed that you know the what you get in the dom is the truthful representation of the encoding of the json document. So if someone uses the string, it's a json string if something uses the number it's adjacent number but then because of dynamic. I would personally expect that I can power.

A

You know I can cast a json string to a number or boolean and then that might succeed or fail depending on what the value ended up being right, but I would think if I actually inspect the object at one time, I would expect to find a json string. There were quotes that I would expect to see a json number if there weren't any quotes right independent of any options and.

B

I will say the design, I'm not even sure what the state.

F

It is right now I honestly.

A

B

Have to scroll.

A

B

Bit, um but there was some discussion about not even having jason number jason string and those types and, like I said, just, have a decent value type and don't disambiguate, I guess, with the type and just have a single bill. We still have to differentiate. I think between collections and values right, but as far as um numbers versus strings.

A

What did json.net do? I think they have different types for the thing they can appear right. They have, I think, json number and json string, json boolean right.

B

Yes, they do, they do have a common base class similar to this.

A

I mean personally, I think, in a dom that's what I would probably expect to see like, rather than switching over a kind. I would, I would assume I can just do you know costs, that's it. I mean in the tree representation that just feels more natural, but I don't have super strong opinions. I mean yeah, I can see when you actually support the casting. You end up, basically with jason number jason strangers and fully and effectively implementing the same thing, because well they all have to be converted to anybody right and then that might be.

A

That might be weird.

A

But you want to go with the api then or.

B

Yeah yeah yeah show adjacent note here and I can go over that. um Can you scroll down quick just to make sure we can see all the types here? So here's jason, node and then jason array jason object, jason value, okay, so scroll back up? Okay, so I so this was edited um the last time I got feedback and the example of love that would json number that's not valid. Sorry, I have to update this to replace the new um api.

B

So so this current proposal says there's just adjacent value and we'll get to that later. I think primarily because of the same items that we're just talking about is that it is kind of confusing to have these. You know string types versus google types um when they they can be represented, json or adjacent number that when they can be represented in json in as different values, so the base class is a node. um It does have reference to the options class, which is maybe not something expected.

B

However, the reason is there is because it does support custom converters, unlike the json element, json document stuff, which doesn't know anything about the serializer json node is intended to understand the serializer. So that means it's up to convert individual converters. You know including custom converters that you might register with the options class um to support what you get or what what values you get back when you call good value.

A

So could value that I mean is value always primitives, or can it be something like customer.

B

um It doesn't matter what what I mean: okay, they're json object down below, and I guess we'll get to that later, but json node is intended um to represent everything right now I mean um you know: jason ray jason object or json value, but json object is, is a built-in type and if you have a custom converter for that, just treat it as a value.

A

No, I mean like the value property directly on json or because you're saying it supports the serializer. So like does that mean if I access the value property of json node, do I only ever get back like a primitive like you know, an array of something or uh you know an indoor, bool or a string, or do I actually get back some high level? Dcls object like customer.

B

You'll get back the um the high level object. I I mean, I guess scroll.

D

Down a little bit, I think I have some examples.

B

Later about this, okay, so yeah, I think jason array and jason object. Both have indexers.

B

That or scroll up a little bit. Sorry, um where are the indexers okay, yeah, there's.

F

B

Two indexes here, one for jason node, I mean one for on the string and one for an integer and those are assumed to work with either json object and json array. This was added in the last pass, based upon feedback to minimize minimize casting, but the intent is that, most of the time you just work with jason node and you um you call it get value of t when you want to get specific type, and in that case you don't even really need to know um you don't necessarily care.

B

If it's an array or object, you you do care, but the syntax doesn't make that clear and again this might be kind of um too high level it's. This may be best to show examples, and I do have some examples later on this.

B

Okay, jason array and json object, I mean represent adjacent array or adjacent object. um Implement I list in my dictionary, similar to newtonsoft.

B

Json value used to be json string, json, boolean and json number. Now it's sealed. So that is um there's a little cleanup like I said it has to happen in this.

A

Dock, so basically json ranges, and obviously the value add of using those directly is because they're effectively hiding the indexers from the base right. So the first one basically gives me an in-based indexer that directly returns object rather than json, node, correct and then the second one. Logically the same it gives me an index that takes a string, gives me back an object rather than json node right.

B

Yeah I mean the array is indexed by an integer. An object is for index by string, which is the property name.

B

When you have a complicated syntax, where you're trying to access something like five levels down- and you have to say you know for element two- I need you know- return that okay, this property has a string. I need that. Okay, now there's another collection up for that property. For example, you have you know three levels down or something mixed between an object and a collection, and it allows you to do that on one line without the intermediate casts.

D

Yeah, I think a thing that's not being shown here, like jason, node, didn't have the ilist members and so there's actually a lot more members on this type than it's showing.

A

Unless they're supposed.

D

To be uh explicitly implemented, but you know, if you have a json array, you should be able to add some. You know, it'll have an ad of object and contains and other things that the node level doesn't have. So if you're building one you would want to build the array, so you can call add, add, add and then and then now you let it go away.

D

If you're reading one you probably I think the intention is you don't care so then you just use the indexer off the base class.

D

Did I get that right.

B

Yep that sounds right.

A

um So it's so I guess my question is if once I'm into like once I'm yeah once I cast to json array, how like it seems like when I'm not indexing into a json array, I get back object. So how do I get back? Something that I can actually walk.

B

Well, you do get json node document indexes, return, json, node and then.

A

B

Good value at the end of it.

A

And they're hidden effectively like I would have to download to get back the index. So that gives me a json node right well,.

B

A

B

Node itself has the indexers on them to return json again well, yeah, so.

D

F

Array explicitly.

D

Implement the indexer that returns object for a list of object, so it's only returning json node things.

B

Yes- and I could look at the code here- I can share some of it if you want, but um the current prototype is functional. In this I mean the uh is functional in the sense that implements the api here, and you can take a look at it. I guess after this side here and see what.

A

B

A

So when is the I list of object implementation visible, then I mean, I presume people would not explicitly cast the json array to my list of objects. Why is that? Is it just for the dynamic infrastructure, or is that something that people actually expected to be able to leverage.

B

The the indexers directly.

A

Yeah well like or anything that comes from the ilist implementation right, because if everything is explicitly implemented, then the only way I would get to them is by casting my json right directly to my list of objects, which seems unlikely. This.

B

This does not show all of the um methods that are implemented. I mean just shows I list the. If you look at the code, some of them are implemented explicitly to hide them, and some of them aren't I see, but you would have to cast a json array. You know in order to call those art our cast, I list or whatever, um but some are implemented explicitly some implicitly when we actually do the api review. You know they'll have to be called out, but for.

A

Example, a lot of the I.

B

Dictionary methods are not very commonly used and um we would, you know, want to hide some of those um just for confusion's sake, but in general you, you use the the indexers to go down to a certain level, and then you can either cast it to jason ray if you want, or you can call get value or try get value on adjacent node to get the value out during the read mode, and I I should have examples later, if not the uh the actual private branch has um a whole set of tests around this, that you can look at.

A

And so you dom is also mutable right, so the value is settable. So what happens when I set it to something outrageous.

A

B

Say I'm standing.

A

On a json number and I assign a string like I guess that works when the quoted numbers are on right, but if I set it to something like you know, imo is the best person in the world, then. Presumably that was an exception right.

B

B

It doesn't matter until it comes time to serialize it. I I believe um I'll have to look at that scenario later.

A

B

To see when they actually are, you know if you do get an error. When does that happen in the case of node, it's just a value, it'll get serialized, uh no matter what it is. If you set it, that's kind of. I think one of the reasons why it was just changed to a node are a common type and not.

B

And and not on each individual class, but there are. There are questions, for example, um like on a good value. If you don't match up the t with the current internal value, what you get back- and I do talk about that later- and it says r convert to t as necessary. For example, if.

B

You internally we're probably going to use json element because that already can work today very well to return abstraction top of adjacent value. So we used existing support. We already have and then, when you call get value of t, if.