.Net Foundation Design Reviews, 12 Jun 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: .NET Design Review: JSON

Description

Today, we're reviewing one open issue with JSON:

* https://github.com/dotnet/corefx/issues/36639

A

So no we should be live as far as I can tell at least there's somebody who complains and shed that they can hear us I assumed this all works out. So yesterday we reviewed this and I. Think there's notes at the very end of this thing. If I didn't screw it up well, minimizing certainly does not help my case I press the wrong button. Yes, I do press the wrong button. That's why so, but it's basically the very high-level, very wrong notes that we discussed yesterday.

A

So basically the the key thing is, you know the attributes for the callbacks.

A

The question is whether we absolutely have to have them now whether we can do them later, then, the general design of whether they should be attributes or not, and the converters he basically talked a lot about it, but I don't think we made a lot of decisions, which is why I set up the meeting today so effectively the the biggest issue I think with what the converters was effectively, how we can make it so that it's relatively simple to handle multiple times so multiple types dealing with the fact that we want to basic at at the point where you know you don't box when you have beta types.

A

So if you do everything by object, then that would cause some boxing, but at the same time we also want to be able to. You know, write code in a very streamlined fashion, where, when you have effectively an object model, you can just write very simple. If statements to say if this type do this at this type, do that which is much harder.

A

If you have a design where you have to basically either have custom attributes that you derive for more custom borders, that you have to extend or every single time- and we talked a little bit about the pros and cons were and yesterday we had another meeting after the fact for two two and a half hours. So we talked about that as well, and it's not that straightforward to cook up a design that can square these few things in a straightforward fashion.

A

So one of the questions that we have for crystal effectively before he jumps off the call was: could you provide us with some sample code of the you know, a set of concrete types that you think you want to be? You know handling in your converters, so we can actually use it as a concrete example, because if you actually care about boxing or not boxing about your types, then doing this.

A

If statement is not a straightforward, my thing because you basically have to be generic, you have to basically compare the generic type and then you have to do a lot of casting by object to actually get the value in and out.

B

So I can I can probably provide some times. Maybe not today. I'm super swamped, but I was talking. I was I, am in with us on yesterday and kind of to first. What I would like to say is I already had this discussion with you know. Steve this feature is not meant to I mean the steriliser is not meant to work for our team. In this release.

B

We were not planning on it, so whatever I say, take it with a grain of salt I, don't understand your schedules, you're all your trade offs, all your scenarios, all your customers, but from perspective of my team. Basically, what we want is we want to have full control over the shape of the types that are being serialized, including you to watch for us to apply any attributes. We basically want the types to look like any other type in the BCL that is not JSON serializable.

B

Just nice types will implementing whatever interfaces we want not having to implement any interfaces that the serialize, Erwin's and so on, and so on. Second requirement is we want it to be fast?

B

A

I, just muted, all crystal you have to unmute yourself.

B

Oh I'm I'm your announcer, so second second requirement. This needs to be fast. If it I mean it doesn't have to be, you know down to the metal fast, but if it's unreasonably slow, then we would rather use the Dom or the reader writer and basically write the serialization code by hand.

B

It correct because, as I said, we would basically create times that.

C

Have our shapes and we.

B

Don't want to, you know, put any parameter parameters, I mean attributes on the types and then we want to use the serializer and I think it would mean that we can control some things with the options, but most of the stuff would be done basically by the converter.

B

In the past we talked it's not even a comparator, maybe you know the feature for us is I inherit from the JSON serializer and I overwrite, some methods that that do whatever the converter would want to do. We wouldn't mind it either. So, anyway, those are the scenarios. I can send you some. You know model types that we need to serialize and deserialize, but I mean you can imagine they are usually from you know: 1 2, 3 kind of levels, deep hierarchies, so maybe one outer type that has some property.

B

There is an object that has a collection that stores you know, 20 small struts.

B

A

Know, do you have any baited vibes or is the all a majority of what you're doing is classic so.

B

Majorities classes, but there are the problem: is that usually, when there is a collection of items and the items are kind of relatively small, we would make them struts and put them in an array which makes it much cheaper and then create. Basically, a collection of heap objects, so majority of classes, but they, but we have some strats and they tend to be things that we would put in a collection which makes it. You know they are rare, but there are many of them. So.

D

So what I'm hearing from what I'm hearing from Christophe then? Because one of one of my first questions is, do we really need the generic or could it just be typed as object, and so what I'm hearing from Christophe is that he does need to work with Struck's but they're generally in collections, so it might be okay, it might be okay to target the convertor at the collection type rather than the struct type itself. Well, as long.

B

As the collection usually would be an array of full, so if we, if we support that I agree with you, yeah.

D

The reason why I bring it up and I looked at James as sort of the authority, but I, don't I, don't see a lot of customers writing struts for for adjacent data it just it's not something I've seen it's not something that you come up a lot. The case that I'm primarily concerned about when we talk about boxing and converters is in ohms, and it's not it's not clear to me the degree to which it's a requirement that whatever we do for enums would necessarily play by the rules that customers have to play by right.

D

Like it's. Not it's not clear to me that something built in like the enum from enum, as string converter, has to play by the same rules. I think it's ideal I think it's optimal I think it helps us validate the design, but if the only reason why we're talking about generics is because of the enum converter- and we think that there's no customer scenario for it- maybe it's best to simplify the design. So I broke the enum converter based.

E

On this proposal, without any boxing.

D

James, can you talk a little bit about this and Jason net to people use value types his boxing come up as a concern. Does your does your enum is string, converter and doing boxing.

F

So all all converters and jettisoned on it to boxing pretty much Jason's on it. It always works with object. So every everything does boxing. So converters aren't special and that regard so popular use. Cases of a converter with an enum would be I mean popular users of a converter. Worth strikes would be enumerations and also date times people wanting to customize whether they ride a date time as an ISO string some other formats.

F

Maybe they wanted to write it out as text since sex since UNIX epoch, so any in arms and date times are probably the main case, but anyone can come all right come along and overwrite any any type I have I have seen rarely people override how doubles and this moles are written. Sometimes people want to write those out as a string just because JavaScript always handles those as in precise types.

F

So sometimes it's easier to write a decimal as a string and then process it in JavaScript to a couple of integer types rather than try and squash very precise decimal into a imprecise, javascript ID.

A

I would be careful, though, to use that as a as a justification for are not having to optimize boxing, because the one of the primary goals we go for is performance and two-point right. So if, if there, if there occur frequently enough in particular, payloads like the SDK, for example, that might not be viable, so I mean I I'm.

A

Okay, with saying we make it harder for Crystal to write that, and it's not like a you know the fault line thing that somebody else would have to do to let say through their own like polymorphic types, but I also feel like I. Don't think that is sufficient data to say the design doesn't have to support that. Okay, but I think we would agree the view that we need to follow the design. That is simple for the vast majority of cases and the vast majority of our customers will not have to deal with drugs.

A

I would agree with that too. Okay,.

D

So, which should we proceed them with reviewing? What's here and sort of talking to her at then, because it looks like this is evolved from what was here originally yeah.

A

I do buy your argument, though, that if we just handle collections, maybe that's good enough alright. So, for example, if stuff can just intercept the connection and then effectively parse the video types as a as a full loop, which means they don't have to go to boxing. That might be acceptable too, because yeah. If, if the concern is you, you avoid a location, but you don't completely have to eliminate them, then yeah, maybe collections are good enough for it.

G

H

Also, a little concerned that, if what Christophe wants is to not decorate this night, that all that what he really wants is some sort of like proxy sideloading feature and not the conservators at all and have two completely different feature. And we should make sure that we're not complaining. The two means.

B

A small danger and I I've been kind of it. It's been my worry during those reviews that if we want to design a great feature for the address decay scenario, but we kind of should, like you know, focus on it get the scenarios and it seemed like we didn't have time to do it in 3.0.

B

So now my main kind of feedback that I gave during the yesterday review was: can we somehow design the features that you guys need for now such that, then they will compose well with the features that maybe we'll read later, because there's an issue of composition when you have callbacks and we have lots of virtuous and converters- you know in the future, there's always a question which one wins when you know so many of them are being so many of those knobs are being specified so.

F

The the purpose of converters and to avoid attributes, although you could you could use it like that, I've always seen converters as an escape hatch to deserialize er YNN sterilizer. So it's quite common for someone to start serializing a type hierarchy, and then they just have some type which the sterilizer just can't produce good results from.

F

So, for example, they might have X element sitting on their on their type and if you try and point a sterilizer at X element and try and serialize it using its names and values, you're going to produce garbage so a converter as a way to completely take control of how serialization happens so that, if someone's coming along and realizing their type- and they run into this one situation rather than having to throw the entire all the work.

F

They've done so far away with the sterilizer, they can just implement a converter, have a converter to manually serialize that one type and then keep keep going. But if I, if I understand.

D

What Christoph is saying, I think he's actually saying something a little bit stronger than just we're not going to use the attributes. It's that his types are not going to be pocos they're not going to be things. What will sterilize or D sterilize in some orderly way like there is types in the Azure SDK are going to be designed for their other usages, rather than being designed around serialization, correct, correct and.

B

The main kind of difference between paco types- and these times is that we want many of the properties on these types to not be publicly suitable.

B

So basically you know when, when these types come from, like lager definitions of you know azure services, and there are some properties that are read-only now we need to deserialize the payload into these types. So we want to make the properties you know get only and have internal setter and then in the converter we, you know, the converter would have access to internal ID ice and we would set those properties.

F

At least worth chastened on it, when you place a a Jason property attribute on a property, you can tell the steriliser you'll you're. Okay with that setting internal properties like that's something you could set up and the callback api. I don't know if we've reviewed that yet, but there might be someone that you could use to to do that.

B

Yeah, if we could provide the information kind of out-of-band, basically, instead of writing a converter, there's some callback- and we say here- are the property, some of them I internal, but go ahead and set them. That would be ideal. But that gets to the point that I kind of made just a moment ago, which is it seems like we- should design the features specifically for these scenarios, and we don't have time because, as you observed, there are so many different approaches that we could take for the these scenarios. You know converters have these trade-offs.

B

You could have some callback ability to you know say: hey, please work with my internal api's, I, don't know what's the best design at this point.

H

Alright guys I have to drop off for a few minutes, I'll be back when I can.

A

So heavy at least then have some bullet points that we can just say: what scenarios do we think we can product cast this API set forth? What we all say, I, don't think we can fund the entire area right, I think that's a it's a statement that was made very clearly to me yesterday that we need to have support for on rotors in general. So the question was just what what scenario said? Do we feel comfortable with designing an API for I.

F

Think it's it's about. The escape hatch I talked about it's about someone being able to write to inject procedural code for reading and writing. Json inside the serialization loop.

G

Custom data types as it is a common feature right. So if you have a phone number type, for example, a struct and are a class- and you want to be able to use that in your vocal there's, no way to do that without this converter model or a converter model, you'd have to write it as a string and a string property and right now.

A

Yeah I get that I'm I, guess what I'm trying to get it it's like. Can we let me be more specific than just that, but because constant data types is very open-ended because otherwise you would have to say something like well. Do we support factories? Do we support immutable objects? Do we support effectively reading a mutating private state, somehow right and I?

A

Think that's the thing there and I think that's a general other question of like Wired enough and I think what we all lean towards is attributes would probably be nice for some people as in as a convenience, but we need to have a mechanism to a wire to converter above out having to do anything to the type itself. Yeah.

D

I would I would specify that I think that those are the base requirements. Yeah like you need it. You need a way to take, take control of the reading and writing of something, and you need a way to wire it up with an attribute, because it's the most convenient and obvious thing to do most of the time, and you need a way to wire it up globally, in the case that it's something you're going to be using all over the place and both of those things feel really good.

D

When I say globally, I mean it's in such settings, but I think that those are the base requirements and why we're we're Steve and Austin and Jeremy, and some of the others that were both in the first route of this design had trouble with this is the wiring up of stuff is difficult when you've got generics involved, because there's no there's no like common exchange type between all those closed generic or open generic versions of that type.

D

So I mean I'd like to I'd like us to start actually reviewing stuff and asking questions about whether or not it you know whether or not it's a good API design, whether or not has is problematic and those kind of things we.

G

Want to go to the samples I mean I, have samples of I.

D

Think I think the first question is: is do people like assuming that there's a JSON converter class, the two, the two methods that matter for Jason converter, try read and try right as far as what does the converter do and how does it work the other stuff here everything else in this? These notes is all have to do with. How is the converter wired up so what I think so? This can.

B

Occur stuff, so that's true and I was thinking about it. Like you know, maybe we can just give up on the you know generic time give up on that boxing of value types. Maybe it's not such a big deal, and maybe we could use this.

B

You know object based converter now the thing that yesterday we discussed and I'm just saying that, because I need to run soon is that it seems like the converter, even the type last one is designed to deserialize hierarchies of types belonging to the same hierarchy yeah, and we have many scenarios where we would have lots of these types in the into object graph.

B

So let's say you know, maybe that 500, but let's say we would have 30 and I, really worry about performance of having a chain of 30 converters to deserialize an object graph, because basically the chain needs to kind of you know it needs to be managed. It's 20 converters, I, don't know what the heuristic or what the algorithm is to select, which one goes for the next you know tries to deserialize the next chunk of JSON. So.

D

The answer to that question is that converters are associated with with sites statically. So the first time you run through the converters and you say: can you convert this? Can you convert this type and then the answer to that question can be cached.

B

Yes, it is yes, so mate. The point was that if we wanted to kind of you know yesterday we discussed would it be possible to create one converter to get that connects tree. Deserializing utilize, many types not belonging to the same hierarchy anyway. So that's my need to write so Canterbury you can aggregate whatever you want.

E

B

We discussed it and it seems like the types of to.

E

Be to hierarchy.

B

And the reason to hurry this because darling I need run good I'm, looking forward to notes.

A

Yes, I think they're great thing we discussed yesterday for two hours after the meeting was given this design point that we just talked about about classes versus tracks. One option was well what would object? Look like they didn't catch that there's, not one that we sketched up. We said what, if we make the method itself, generic, not the type and then effectively allow it this way.

A

Basically, you you you return, can convert true for some types and then the caller effectively, the the the detail at that will basically call the try greed versus try ride with the correctly instantiate a generic type, and then basically, your implementation just has to who will switch over the type you were invoked for, both of which result in different ugliness right. Some of them is just yeah.

A

Okay, it's just casting what casting is relatively clean when you just deal with object instances, and the only thing you care about is you know getting into different video out. It's a bit more complicated when you, when you don't want to do this for generic reasons, then it explodes pretty badly but yeah. We could probably hide that behind effectively a custom class hierarchy, where we give you multiple converters that you would extend from and then one of the basic be the easy one.

A

The other one is the more the more advanced one, but the question that we had was, if you do, that there is some overhead involved in basically going through a uniform representation in this utilizer itself, where the question is whether the code unit itself is now resulting in a ton of copies on the straps, for example, where the box, it might not actually be the problem.

A

It might be that you know no no reading effectively super small, you know four byte bail, you know become politically expensive, potentially right or eight byte wagons or whatever, but because you keep copying them all over the place. So there are some issues around ed, where it's unclear, whether it's even viable to have a design. No matter how you, how you do that, and so maybe just one thing has to go I. Also, it's a decimal.

C

Chaos point: we had discussed the concept of automotive factory yeah, which will let you weigh one inverter than 100 times.

D

So I have a I, have a question. Kristof scenario: I didn't get that yeah I! Didn't you ask a question before you left for Christoph scenario? Doesn't that just work if you're, like converter type like it's, assuming that we do what's on the screen right now and I'm, not saying that it's perfect or that it's done right, but assuming that we do a design where the Jason converter has a t in the type? Isn't the type of Christoph's converter, like Jason converter of object and like we're.

E

Done what is that? Result is scenario well.

D

E

Can I yeah jump in here is I've, been writing these since for all day yesterday and today, I don't see why we can't just like in that particular case, you write a json converter that like because it creates the.

E

Where is it actually there's the get? Can? Oh, you changed to a binder, I'm, sorry I'm on an old one, nevermind like the Curt, the the one. The original plan was to actually have a crate converter on the json converter. Yes,.

C

Which is weird the only change here. Is they move that to Jason Tamara binder, which is that actually the factory but functionally it should be the same, but yeah.

E

Yeah, well, if it, if it was back on JSON converter, then the JSON converter itself, you just write that thing is bigger. You know, have that be the factory. Essentially, yes,.

A

Roll back I think the problem that Christopher's pointing out is that say you have to handle thirty primitive types right. The question now, if you have thirty converters- and you have thirty instances that return true from can convert for various types, then how expensive gets that, but also how noisy is it in his code chain? Because the thing what he still envisions is you have one converter, you call it the address decay, converter, there's no T involved.

A

You just have a method where you say: try read or try writing you to switch over the type and then do the casting right like and I think we can all agree that that generally works. If you can agree on the time being object because then you just cut right as soon as you say, I don't want to do that. Then. Basically, the only design that would work for Christophe is there is no T in the converter itself.

A

The T is in the method, so the method itself is generic and the cylinder framework, basically instantiates the method for the particular T that it passed. Who can convert it in there to turn to, and then you implementation of, try read of T and try right of T basically does the is T type equals type of blah then goes that co path right, but that that becomes extremely ugly cold because you basically cannot convert one generic type to another. You have to go by object and it's it's not super straightforward code to Ryan.

A

We convince ourselves that curve is probably not too bad, but you know, given that you know our parameters involved. It's not very clear like how bad that actually ends up being this.

I

Isn't reasonable the framework SDK application would want to register every single one of the primitive types with a converter either its own converter.

A

Or some global converter, you mean to avoid the the chain that you have to go through. You can just index of the type and you get the converter, no.

I

No I guess my I guess. The overall question is like it is in common that that custom types need to be serialized in such a dramatically different fashion than what the serializer already supports, that a converter even needs to be created in the first place. Yes,.

J

If you've got custom names casing, if you want to support infinity or not number, if you want to support a particular format of gooood or date/time or like the list goes on and on even for what we consider to be corporately.

I

Moreover, lots.

D

Of people have classes that are not pocos and involve like involved serialization that gets in sets data that the user, like a consumer of that class, otherwise and.net, doesn't have access to. We use use it for this and raiser in the compiler and NBS the.

A

Biggest concern that crystal fed is, he wants an immutable object. Well, I'm.

D

Concerned I mean to christophe sort of meta point about us twisting the design to meet his requirements. I still am having a little bit of trouble understanding how what's here doesn't meet his requirements so.

J

It's not exactly clear if you want to have like, so this will work if you three jason converter as type object, and I think that's, the key point is: if it works, you have to treat this object and maybe that's efficient or maybe it has potential perf bugs that we don't know about yet or.

A

You just literally has, and as your type one converter, that extends Jason converter of whatever its type name is. It basically has to have 30 classes.

J

A

The Ryan's point, but if the cold side caches, why do we care? It just means that his code is now in 30 classes rather than in one method. That is really long, which I can see not being the most elegant solution for in this case. But if you actually go through the like, if he really cares about not boxing, then his hole is not going to be pretty if everything is in one method either precisely.

A

E

Enum converter isn't terribly pretty because I made it my box right yeah. It's.

D

E

D

Really important to understand that can converters can convert is designed to be something that the serial their calls once per once per type for convertibles sure it's not intended to be of her peruse overhead or anything like that and like you're, not going to have a giant list of converters registered by the framework by default or anything like that. So I think I think drilling into can convert and the scalability of having many converters is a bit of a red herring like I.

D

Think I, think we've kind of all feel good about that detail of the design. I also want to mention what happens if you D invent can convert, because the first version of this did not have can convert and you run into you run into a bunch of problems. If you don't have some way for the user or the developer, who wrote the converter to programmatically inspect the type and make their own decision so.

A

One question I have is like what in the FK own world? Why is it not that if you vendor said the converter, you say for which.

D

Type, it is so the reason. So the reasons why are you might want to register a converter for a category of types like say all the enums which in vote, which includes types that you can't name you can only inspect with programmatic logic or something like F sharps, discriminated unions or say an open generic James.

F

Has numerous samples.

J

F

If F sharps discriminated union, for example, I'm pretty sure, there's no there's no like discriminated Union based type, the way I detect it as I look for an attribute on the AMA type I'm a generated tie so ultimately.

D

Ultimately, you need some kind of programmatic logic.

E

So for the email one, we actually use the activator to go and create the T, so that's appropriate for that type of enum. So it's activator crate instance, and we do that in the actual 19 class.

G

Can we just go through the four examples? I have really quick I mean like two minutes on each.

C

G

I'll just walk through this really quick here, so the Semien converter is just you know, true/false unknown, and they want to have custom jason for that. So in this case a simple just basically derived from jason converter and pass in your your name, your email and we can skip over the read and the write for now. That's just a boilerplate reader/writer code.

G

So basically just yes cordon.

G

And here's a test for the so here when you add it, um you know in this case, there's no generics, nothing just do it up, and you know it works as you would expect.

C

And you're, adding it or on the options and the alternative would be the attribute. Here's added to the diet, yeah and.

G

I have a sample later for that yeah, so the polymorphic pokel converter um yeah scroll down for that. This is um interesting one here we don't support polymorphic tea serialization by default. Somebody can do this if they want so here's a simple object model um in this case there's an enum type discriminator just as an inner class for now, and if you look at the can convert it's this is you know? One of the important things about can convert here is yeah.

G

Like rhinos saying this is programmatics um having a simple you could, probably you know: do it some other way, but it's basically saying if your person then I can convert you.

G

So that would include you know, customer and employee and the read will look at the type discriminator and create the right object and apply the right values for that, and then the right does the same thing and you know, writes out the type discriminator I'm kind of like like the read and write methods are pretty boilerplate like I said before so I, don't think we have to dig into those.

G

um So if you just want to scroll down to the test here again, we we just new up a person, converter or the same way we did with the enum and everything works as it as you'd. Think and.

C

G

C

Tomorrow to play for this case, what it won't think is I'll.

G

Do that this next sample here? Okay, let's do that? Okay, so this next sample here with an attribute okay, I created a new type or a point class here for now skip skip the converter.

G

This turnout is pretty self-explanatory, but here's an attribute since since this particular converter accepts an offset coordinate offset and if you want to use an attribute to be able to specify that this attribute takes set offset and in the get converter method on the attribute here. Just simply news up to on point converter will ask for that and pass asking in that coordinate offset.

G

So the class here there's a sample class. It has a point on the bottom of the screen here and that, that's just saying, add 10 to the point. So if you look at the test, it's just adding 10 to the 1 and the 2 that were passed in to get you know 11 and 12. So this is an example that that you know if your. If your converter has additional arguments on like, for example, a hypothetical email converter would have treated string, maybe a low. You know in sand and strings something like that.

G

You could have you know. Like JR James mentioned you could have a date/time converter that would have hell out formatting and things like that right into different structure. Ok, ok, yeah! Your.

C

C

G

Here the list converter, um what state so this is. This is a tricky one where you have to do this behind your model. um I think this is gonna, be rare for people to do this, but if you screw up a little bit more, so we get that top line.

G

Okay, so here here you derive from this binder class. This is the factory class there's some naming TBD on this. We also discuss having a different type hierarchy, but this is the guy that that says. Ok, um you know you're gonna pass me type later and in a good converter and I'm gonna create the real generic type for you, but this.

C

G

The type that people add to the options you don't ever see these other generic types, they're just cash white and a hidden by the framework right. So here it's just saying: hey, if you can convert says um if your list of T and T is inter long, then I support you and then get convertor down below says. You know the ugly activator Creed instance code to treat that the real Jason converter of T, which is on below. So this is the actual disc converter. What's open generic so.

C

With this binder model and the gate converter method is that word put resolved Christopherson area of having one converter type registered the hands are handling my prototypes like they would implement. Jason converter binder only.

G

For generics, otherwise, you can just use type of object like.

C

G

Earlier this is.

C

Logic, specific I might have one conversion well.

A

I think in this case, the way you would do this is, you may have multiple things that are built by this miner model, but they could not handle, like you know, effectively disjoint classes right. So, for example, you can say you have one converter for, but this particular class hierarchy. You have another class hierarchy of a different converter. Then we have a set of primitive ties. We just have one of them right. So then.

C

Logically, in his converter, mine derivative well.

A

You would sort of have to have dedicated instances for particular T's, where the T is destruct. The teaser.

B

J

You can't do a generic tool that can.

A

Do so much netu I think that doesn't work.

J

If typeof t equals type of expected, then call into a specialized priori method that took the concrete T that you just checked it yet.

C

So there were that.

J

None coordinator would I live in the same method in the same class.

C

J

Would just be a private method, yeah.

C

So it will not live on an interpretation of Jason Tamara binder, no idea where it would live in the list. Converter vices.

C

The list of words can can cover nothing. How are you, sir.

J

So they you you would you would have a my type converter of tea and then you would have the same thing where you've got priory of tea. But if you wanted to specialize what you did for me, you would say if typeof t equals type of it, then prior e-reader type options out in value and that's another method. It's a private method on the same class that handles in specifically and centralized at that point, can you do the same thing for you and you've been this? My.

C

Cover of t is what's being registered when you register the binder right. So that's my question. So what is the binders get converted into written? Look like okay, you scroll up in binder intimidation. It's.

J

Activated for you, yeah.

C

So when Christoph's cool look at similar to the quadrivium right now for these particular types, yeah.

J

If you wanted to have one yeah so.

C

This a be discussed just cover a binder that Lisa.

I

Forces in a what he, what the other stuff would probably want to do. I had applying this to just have, because his list of types is finite and on that front he would probably just have a static dictionary and then did not static dictionary. Instead of using the function he chose, it'll it'll just be lower yeah.

C

And I went to find meaning that he would have to implement that converter. Yes,.

I

And can work on.

C

Yeah his own custom, Jason cameraman.

I

Correct adjust, it wouldn't look like reflection, basically,.

C

What that's like Aaron.

I

Look at is: is this the right time to go over like what the code inside these methods looks like what we expect someone to write? Do you want to have that conversation later.

A

Yeah I mean what particular consider you have they do. You think we're.

G

Almost done here, I mean just scroll down a little bit.

I

My comments on yeah.

D

I had some spicy facts that I wanted to add about that.

I

D

Well, but I will I will hold them until after.

G

You registered this this generic converter, so you know options and you had you know the none generic converter on for a while I had I had a different model where you were noop up directly: the generic version of the converter and passing a placeholder on like a like object and that kind of worked but I know it doesn't handle all scenarios. So that's why there's two classes here, one for the binder and one for that.

A

I just need everybody, because there was feedback.

G

The binder this converter is a binder their plates.

J

A binder I think it's confusing to have a binder. That is also a converter, like that doesn't seem to make sense from the typography. Well.

G

I mean from the users perspective: this is this converter.

G

um If they have, uh if they have one that, doesn't you know, use generics or whatever it looks the same, they just knew it up and I that reason, I think I know we had this discussion yesterday, a little bit, but I didn't realize at the time that we need a common base class, because we want one list to contain all other converters, whether these the special binder one or just a normal one, because um order is important and we don't want to have two different lists and try to figure out ordering between them.

G

D

There's some easy ways to clean this up: to make it make more sense. So I I hear I, hear tan I, hear I, hear Tanner's feedback and I have some ideas about that.

G

Okay, so I think I'm done here going through the temples, so I.

J

Think I had one quick question, so you said that internally you casually Converter it that says, can't convert what happens if it says it supports a type but for whatever reason, reading or writing type fails and so try reader try, write, returns, false.

G

Nothing happens, except an exception is thrown so.

J

We don't say, move to the next pipe that might be able to convert it.

F

No, that would that would never work, so one important thing to keep in mind with these converters as they're working with Jason reader and Jason writer. Those are forward only api's. So if you're, if you write to jason writer and then you decide halfway through the converter, isn't working for you, you can't really undo that right.

F

So these converters don't cooperate like a converter, could call another converter or a kekulé was serialized or materializer could invoke another converter in a nested fashion, but you would never have two converters running at the same time on the same Jason on to produce the same type. Generally, only one converter is executing at a time I.

D

Would also say: tuners Tanner's question is not at all about an exotic. It's not at all about an exotic scenario like plan failure is definitely an option. This is you would return false. Unlike invalid data or something like battery, you could return false for invalid data so like this is a thing that will happen and it's part of the design do.

I

We actually want to work on the false, rather than force, the converter itself, to throw a useful exception and.

J

Then I sketch it in rabbits because.

I

Returning false kind of hides what went wrong this eliezer effectively on for you, but it doesn't no one knows, is this: I have.

G

The open issues section provides some mechanism um support that if you try to throw your adjacent exception, unfortunately, you won't get the path inserted, because the reader and writer don't have the path on. That's.

I

Okay, but like even knowing the line number that failed would be useful because know.

E

I

Know no I heard a low number of c-sharp code that failed like if the actual converter itself, through the exception, because otherwise, if it returns Falls literally, the only thing we know is something somewhere in processing. This value went wrong. We.

C

Have talked about this in a previous meetings that we want to now the converter, to throw yeah or veto on to Commerce behalf yeah III.

J

Think it makes sense for to force the converter to throw and then we catch and wrap it, because it's an exceptional case, anyways and I think you saying try implies that there might be a chance of recovery, and so just if you make the user firm, we wrap it and you've been properly useful information back up the.

C

Worry was now that, because I feel like a baby right, you can add to this is really known. What does you want to have a track catch on in honestly that isn't gold? It says it's not bad. What you did you just yeah come on. Did you I mean.

D

I think it's I think it's also ok if we were to like catch and we throw catch, and we throw Jason exception with additional context, but to to Austin's point that that is a concern. That is something that we'd like to avoid is. We would like to avoid turning IO exception into Jason exception, because the expectations for handling Jason exception are that there was invalid data, not that reading the data failed right or not that reading from the stream failed. Why.

J

Can't we have a Jason serializers or exception, which inherits will Jason exception. That explicitly indicates hey. This was a serialization exception and the serializer could have provided more info in the inner, except, which is how I think most people would expect that they have been propagated up.

D

Sure we already, we already have the we already have that design, but with one tight, so jason exception can be constructed with the kind of information that the serializer has or it can be constructed with the kind of information that the writer has so the distinction, the distinction I, think, doesn't really matter a whole ton at this point, I think that the general idea of asking the user to throw an exception seems seems good as long as we think that it's not unclear to people that there's there's a specific type of exception that we want them to throw like.

D

We don't want them to throw in valid operation or IO or something we want them to throw a specific exception type to indicate failure due to bad data. Yeah.

I

And with my comments, I'm not really trying to be prescriptive per se. Really what I'm trying to get at is the it in a scenario where a method returns false like because all of the return be-because control pro gets funneled into a single location, it's impossible to tell what actually led to that returning false, which means you can never ever show a useful error message to the user. All you know is something somewhere am I wrong deal with.

G

Okay, just to clarify, though the actual message will both show the Jason path and the line number and the offset I mean so you at least from the Jason perspective. You know exactly word failed. You won't.

J

G

Burger guy called, or anything like that right.

J

The key point is it's completely fine to get Jason information, but this area like if I'm debugging, my code, I, don't want to have to guess at where it failed or anything else. I want to be able to get a clear exception. That says, like hey, the serializer failed and here's the additional information that the converter provided. Positional.

C

Order or what about going to fit.

J

Right because because otherwise I'm going to be guessing, I'm going to be going and saying catch, these specific types of exceptions- and it just makes debugging pain but.

I

Maybe the wrong converter: don't call yeah. How do you.

C

Even do bug that yeah so with the resolution that we we pick whatever except I'm, it may be, let us say, is Jason acceptor for now and the street especially handles that exception and the guidance is the user idea, intimately the converter close, that for to the exception and all of the acceptors we let you continue to not catch, maybe I'm.

J

Still I still think it'd be better just to catch exceptions in general Imran. This serializer failed because an exception was thrown an unhandled exception was thrown till you wrap it. That's what inner exception is for it's for saying. I cap I encountered an unhandled exception where I didn't expect it. So here's my failure mode and he was the failure mode that caused that that.

E

Is is Ryan's stated, there's things that are like there's difference between the JSON being bad and just like not being able to get the data period right.

J

But that's what having distinct exception types is for. That's why you have a base Jayson exception and then a serializer Jayson exception. That clearly distinguishes like this is bad Jason, Nate I versus this is something failed in serializer versus something else that.

E

Doesn't tell you the other party great, so we don't want to catch system. I/O exception that here and wrap them.

J

I mean I realize her failed because of I. Oh well,.

I

What's the downside to your wrapping them.

D

Right downside the downside to wrapping them is the fact that we have adjacent exception. It all becomes useless because now, if you handle Jason an exception because you're interested in doing something with the error about the bad data, you have to now look at the inter exception and try to try to like implement complicated logic, to figure that out so like.

C

Changing the contract of the serializer.

D

To say that it sometimes wraps io exceptions is really bad from an error handling point of view, because you're always you're now always interested in the inter exception and whether or not there is one and there's three different types of io exceptions to get thrown. Yeah so say.

E

For advisors and a rapidly.

D

Throw io io exceptions will will reset a lot of previous decisions. So why.

J

Can't you have Jason exception as the base and then serializer exception, which can wrap like this and then data like invalid jason exception, which indicates I encountered invalid Jason and that's why I'm sorry, then users earlier all caps, Jason users who care about invalid data, catch invalid data.

D

Yeah so I mean that would work just as well with those three types and without I mean.

J

It's a difference of whether or not you're catching any exception. Are you catching hey? Serialization failed, except right.

D

So and so the topic, the topic, like the decision point, seems to be because we have to do. We have to specify this behavior, whether or not whether or not we use, try, read or or read. We have to specify this behavior regardless right, because the writer will still throw except the reader and writer will still throw their exception.

C

D

We want the steriliser to provide the additional context where possible, so what we had going so far that I'm still happy with that I think works and fill the fills the requirements before and after this. This design change is that the serializer will catch Jason exception and will either wrap it in an additional JSON exception or create a new JSON exception, with with the additional context of the property path in the model like that satisfies all. The requirements like what's important is that the steriliser does not catch and we throw IO exception. I would.

A

Agree shouldn't that, because, honestly, like the the way I see it is like, if you have invalid Jason right, then one of the converters might decide to throw this exception because the Jason is bad. They don't, then anything that happens is effectively failed for that request, but effectively. At that point, your request is done. It waits to be 500 because something in your stuff is not kosher. Right. I.

J

Mean that's exactly how to ask for.

A

So it's a it's more.

J

For technical reasons, but I mean hey nearly.

C

Like we have to do it in.

A

Other areas like, for example, what's the thing called target exception thing is they're basically of reflection throws we do invoke, you know it's largely and we shouldn't have. We should have never done that. We should have just forwarded the underlying exception, because no effectively it's you're you're you're, basically making it way harder people to get access to the actual call stack to the actual data, because the exception you're getting is almost never the one you want I, don't care.

J

About target location in what you're doing and it's a question of do, does be as the serializer catch-all exceptions and wrap them, or do we tell every end-user they have to catch all exceptions and filter know.

A

That the consumer of the jason bible should only ever catch a catch, an exception of their care about the payload being. Anything else is.

I

About well dub dub, that's a floor and I was going to ask what do you put in the catwalk? Realistically, yes,.

A

I

A

Hdp response would be, for you gave me bad data versus I, crashed because I have a bus, so literally a four.

I

Hundred verses, five video response right.

A

Basically yeah: well, we.

I

Care deeply about yes, I! Don't realize that, but I mean.

I

D

That we're going for is writ broadly as a person who initiates adjacent operation. I want to know if that operation failed due to bed too bad data like if I'm writing a wind forms app and it fails due to a file not existing on disk there's. A different air handling scenario than the file is corrupt and I would provide a different error message to the user. So it sounds.

I

Like returning false from try, read actually means the it. What it's supposed to mean is the payload itself was bad. Now, if I myself encountered an error, so, for instance, you wouldn't want the implementation of try read itself to have a try captain inside the cache return right.

D

I

So that's a that's a very good point.

D

That's brought up here right like it's: it's not desirable to have converter authors, catch Jason exceptions and there we throw them or return false, like neither of those things is desirable yeah. So if we feel like the method, if we feel like untried these methods and saying you, you throw an exception to indicate bad data and by the way you throw adjacent exception to indicate bad data. So let's say that a required property is missing. You can throw Jason exception for that, like that seems good.

D

That seems to satisfy all the requirements yeah, but the guidance has to be through adjacent exception. Yeah.

I

Or or if you want to leave the current API shake you can make that same claim, you would say, return false give them only if the data was bad effectively for everything else. Their own exception I mean it's basically another way of saying what you said only instead of changing the exceptions like you return, false yeah.

D

So I guess what I guess what I want to understand from the other people that have you know, opinions about API is an experience with corvex api's like what is what is the best thing to do from a pure api design point of view between those two options: option 1 return false for bad data option to throw or throw JSON exception for bad data and you're, specifically thorough JSON exception is what you're recommended to do well,.

A

The downside of returning false is you, don't have a way to include information right, so if the implementation of try read is effectively an INT parse, that's probably ok right! If you try read, is reading this super complicated, structured object. Maybe that's not enough, because now you're like deep in the bowels of something you want to convey to the caller. You know I feel like at this point and it's not super useful. You just return false at that point. Right, yeah.

D

And they're not and they're, not purely binary choices, because you could throw a JSON exception in. If we go with try read you could still throw adjacent exception. That would be fine like that, would work fine. It doesn't break the design. It's just that saying. Putting try read their encourages you to do two things that seem non optimal, which is to destroy information when you do encounter an error by not reporting it and just returning false and also it seems to encourage you to do your own exception, handling, which we want people to avoid.

I

G

A teacher and writer samples I mean they're returning false everywhere. Right I mean that's the thing with parson Jason you're, not gonna, throw or include context for every little Chuck I, don't think.

G

H

So does the lessons the design where the converters are going to be put in series and you're gonna? Do the try read and then go to the next one? If it returns false, then it should just be read and throw partially, because, even though we have very clear guidance on what the tribe means, which is only return false for one kind of handling scenario and throw for everything else, a lot of people think it means never throws exception.

H

And so, if the model like it sounds like the right models just to be read and throw like I said, unless there's a collection and a series of like the first one to return, true wins, it should just be a void. So.

D

So Jeremy it sounds like what you're saying is that this is a case of is a case of like the sample is optimized for the API shape that we have there. And so, if we change this from try read to read, you could write the sample differently and it's just as good or even better.

H

Like try, the Tri API is my API czar, a thing that just a lot of people have trouble with they seem to. They seem to believe it because instead tryparse never throws less, assumes that try means don't throw and then, when they're calling it, they think it means it never throws and they have trouble with it.

H

So, if we're expecting someone to write one of these tries, we have to be careful about the assumptions that we want them to make and if the only thing that's going to call it as a serializer, it's just gonna say: if both throw then just be honest and let them throw it and they'll have to duck contact.

C

C

That question the question was that if we won't, if you have the user, throw let me happen, then the user is required to do because they are not able to proceed. I need to get the state from the user. One of the need failed and I threw for you under Caesar can never go for the what's.

I

Going to happen in practice, as mentioned earlier, is that people are going to write converters they're going to call into doc parse inside the converter, not try parts of the parse and the thing is just going to throw an organ exception and whoever's consuming at their try-catch jason serializer exception. The exception will just blow through that an agency be 500. The response, like that's, what's gonna happen in practice, regardless of what we say in this room like we can work around that right, which.

J

Is a which is why I was thinking it'd, be better to catch and wrap, because otherwise people writing what they think is normal code will end up not doing what they expect. You.

K

J

And so, in my opinion, even if they put some more onus on people catching and handling exceptions, it's the exception case. Who cares but behavior? Do you just can't I think.

C

Holding on this discussion, and because they have so many other things around the camera- that we should discuss revisiting, whether we should throw all the cash on acceptance is unnecessary. At this point yeah we should be attacking morphogenic anomaly, yeah.

I

And I am sympathetic to to what I was saying to about like the error, codes and I'm. Just thinking in practices, I'm gonna fall down, yeah.

A

I mean it's not something we can punt for later, though, like I mean that's kind of the design, it you kind of want to get right what we should write, so we should make a decision on where that is, and I'm, okay with punting that for now but exception handling is, is the thing we need to think about and I know.

C

I mean like that it has strong opinions, but the decision I am happy. That is guys just exception.

J

If we, if we didn't wrap, exceptions and I, think the next best thing would be don't return just require the user to throw Jason accept so and.

D

J

D

That's not the kind of headed here right yeah does.

E

Anybody want to make an argument.

D

They should still be try pattern, or these, like are we all kind of agreed? It seems like we have reached a consensus, but I want to confirm it.

A

D

Okay, so so your chance to speak up has been has been passed, so there.

E

Is no try yeah.

D

I'm not I'm, not in the room, so I can't see people's faces. Okay, okay,.

G

I think try is fine, because anybody writing is Jason code every single time they call into the reader or writer, okay, which is gonna, be for every single token.

G

Every single value, every array element whatever is gonna, have to throw and and if we we and that's just people are probably going to ignore exceptions of anything, because it's just too hard and too cumbersome to have to write a troll instead of return false and the other point did we have no way of getting the Jason path right now, so that would require another feature for people to throw a proper exception.

E

That was the the idea was I. Thought is that we would catch that, but only that yeah.

G

Okay, so I mean so we don't if we determine what to actual catch but, like I said just look at any kind of code that does.

C

Can we recover Steve, you have a check saying if the token type is string return false. Instead, the user could just remove that I got together and just call the rear door. Caching API that will end of towing. You know maybe I guess we already need those yeah I. Think.

F

The common case is you, you run out of data, so you call Reed and Reed returns, false and actually I, guess I guess with these converter types, you're you're reading ahead and that's the difference compared to Jason, don't yet, but at least with Jason Donette. After each time you call it Reed. You need to check whether it's false, then you throw an error.

F

So the common pattern I have as I just had a helper method called read on assert and it would call read and if it returned false, they met method would handle, calling throwing the error.

I

Jason, what does it throw? The current token pipe is not strong.

I

So that means we would load a min, develop operation, obstruction, bubble, logical color,.

I

If we're doing the naive approach with this calling reader dog yeah.

D

Yeah, that seems it.

H

D

H

We can always revisit that model right now and say that we think that adjacent exception of us for the wrong token type, but a valid operation seems to match the normal API feel better. It.

I

Tells you? Because the Jason itself is still good.

C

I

I mean that makes sense, given the API, but the other things that we've said like we don't let that determine into a 500. We wanted to turn into a 400 and invalid operation. Exception would blow it down the particle path. So.

A

How does this evasive work is the idea that the overall sterilizer basically is responsible for catching that exception, then getting more data.

C

Is what catches Jason reader at your Center? Nobody.

A

Says once I hit basically.

C

Happened: the path information because I have them no.

A

I meant like when you want, when you're out of data, and you only have 4k in the buffer. You need to read past that what happened.

C

A

What was the question so basically, the question is: if we decide that Erik is basically handled by, we just call an API on that. It rose from a performance standpoint that might be okay because errors are sufficiently rare. But if, if basically error handling also includes effectively when you're out of data, does that mean that basically, the cylinder that has the outer loop? That says you know you know, keep serializing and if I'm out of data, then you know get a bigger buffer, read more data and then see lies again. How does that work today?

A

You basic catch an exception and then just get more data and then basically call the converters again or what does ever know.

G

The serializer will handles the the serializer handles. Okay, assuming you don't have any converters it'll detect whether you run out of data, because the reader would say false on a read and then it just unwinds itself and doesn't read, and then you know kind of continues where it left off, right and and actually James made a good point kind of to earlier about Auto data, because we now guarantee um for these particular converters will not run out of data. A lot of the false statements that I have in these samples could just go away.

G

You know they could be a search or something I see so.

D

I'm not sure that everybody on the call totally understood that, like what the guarantee that the serializer provides for both really like for reading is that the serializer will have pre buffered till the end of the current like value. So if it's a single Jason value like a string, it will have pre buffered that string. If it's a object, it will have pre buffered the entirety of that object, and if it's an array, it will have pre buffered.

D

That array and the reason is because it's not really reasonable for user code to write an async Jason converter, which is what would be required like this design, would be 15 times more complicated if we were talking about a async converters. So when you write a converter, you have to guarantee that there is enough data available for you to complete reading. Whatever the current thing is.

I

That makes sense and.

G

Intrigue, we only have to do that in certain case in cases. um So it's a separate side discussion. We can have later whether we want to do that in every single case or not, and.

C

In the extreme did have enough data at all that we produce, because the seasons are one free buffering hit. That gives you the reasonable. Yes,.

G

Yeah I'm just taking a male form Jason um and you don't run out of data necessarily because the buffer is complete, but is malformed, and um you know you, you still have to check for your own um false when you don't have a stream. Currently I mean in the current prototype, because we do not read for performance, went unless you're in a stream.

I

But simply sending the JSON payload, you know, aged :, cheese emoji is valid, like it's totally valid Jason, it's just ideal. What you want to four hundred so.

C

Okay, so it active, you buy a good point of what should happen if you didn't have forth or if he has like the end. If not 20 disagree. Thank the against J decision. Where would the use report of money well.

I

That's actually one of the things I wanted to talk about if we were ready like what does it actually look like to write one of these things, so we try lead method that we were just looking at on the screen earlier career on list converter, our jurors, when I was looking out. I was wondering, like that's, that's, obviously, very verbose, because it's trying to handle a bunch of different things and my two questions are a. What would it look like to minimize that, if possible and B is it complete even as perverse as it is?

I

For example, what happens if a comment ends up in the middle of VRA? Will the converter actually boil off, because the converter needs to special case comments, because it's a tone, token type, so.

C

In the case of comments, it would be independent, read off like if they read it, but II bought the reasons for comment soon. Yes,.

I

But so you said it depends on something that's external to the converter, so that means a converter presumably needs to special Haysom, because the converter doesn't control the options being passed them, and so does that mean every single example that we ever write of a converter needs to potentially handle a comment. Absolutely everywhere, I mean.

G

If you love comments, that's fine! If you don't allow comments, that's fine! You can't assume that if you're, if you're peasant payload around you got random comments, scattered in your JSON that you know every single sterilizer eats your life is gonna. Be able to support that.

F

Who's writing the converter like. If we are writing the converter, we would need to handle all these situations if it's just some applique or or if Christopher's doing it. You'd need to be thorough and handle that situation. But if it's just someone writing a converter and Mary application, they.

F

Know that they have no comments or that they have that flag turned off or on didn't.

D

We also discussed this already, while we were doing the design and I thought that we landed in the place of I thought that we planted in the place of the seer eliezer by default, passing the option to the to the reader. That says, just don't tokenize comments like don't give them to me as tokens, so this here isn't that, where with mandamus so.

C

See you see that never allows right.

I

But the serializer by default will say no comments because it wants to be compliant with the Jason specification. But you could you could change the options to say either I want to allow comment and drop them as trivia, which is probably what ASP nuttin up and out your mothers will do and there's also the option to say. I want to allow comments and I want the reader to actually.

C

I

D

Yeah and I have to had the feeling that we had tried to resolve this topic already, but I'm glad you brought it up. Okay,.

I

So that means that we don't need to consider comments here. Then we.

E

But we have disallow, allow and skip yeah.

C

So allow is not allowed in Jesus. She has options. If you look at the association options properly, centered for comet handling allows.

C

I

Is the same document? Okay, so it's it's either skip or for them.

I

Are there any other things aside from comments that would affect what I just mentioned that such that the hy rediff method would need to special case things that they might not care about.

C

G

A lot of complexity that people have to write, I mean the leader null handling and, and things like are ignored, there's other global options. The you know case casing, for example, that people would have to deal with if they want to completely online easy.

I

For someone to write one of these methods, yes,.

E

For complicated ones, I think most people are going to go and use JSON document yeah, and then they have an optic model to work with and I think. That's relatively simple to actually write and.

G

We're not really honestly we're trying my my thinking is we're not trying to make this easy. Well.

E

I mean that that's I'm, saying is, that makes it relatively easy for the converter is like, then you just passed I mean that's what we do for getting JSON element out right now, as we use JSON document hmm parse, it don't do anything and they, the other people, would just take that and then break it apart. If.

G

You want an easy model: I think that would be a different type of converter and we would, you know, have callbacks on property names and- and you know, skip properties that have the ignore attribute on them, and things like that again. I think JSON talking that deals with what I mean I'm just saying it. We wanted to actually make, instead of trying to thinking about making this converter easier, to implement.

E

We can think about I'd say that's a mitigation, as we say like if you want you use JSON document. If you want complicated handling like for you know, objects and arrays yeah, that's what I'm saying you don't use that that would be, but we'd show an example of that as part of our stuff. We even use it internally, right so to say: hey look! Here's one of the here's one of the concrete examples of writing a converter.

E

You can then park pass it to the JSON document, get parsed and work through it as a logic model. It'll.

G

Work on the read currently, but, of course not not the right.

D

Okay, so I want to bring I wanna, I I know we wanted to move on from this, but I want to bring this back up because I guess I was I was wrong about this detail and now I'm kind of unsettled by it. The fact that writing a converter, that's really naive and calling like Rita string, is going to result in invalid operation, exception and result in result in an invalid operation, exception bubbling all the way up the stack.

D

How does the serializer, so the sterilizer doesn't encounter this problem, because the sterilizer checks every token before reading it is that the answer yeah.

G

We're dealing with super primitive converters. You only do dry yeah. Everything is tried within this.

D

One call so I'm, I guess: I'm I I had thought that those methods, through JSON exception so I, guess I, was wrong about that detail and I understand the motivation for having them throw in valid operation and I think it makes sense, but it does.

D

It does kind of break the air handling model that we talked about before, where, as Levi said, if you try to reduce some of these converter samples to like the most simple form like, let's simplify this code, like a user who doesn't know these API as well and was trying to just write like the simplest thing that completes the job or like the shortest thing that completes the job. It's going to result in error handling not working correctly well, so I am concerned about that and I'm interested.

D

If other people have ideas about what to do about it, so.

A

You're concerned that people basically catch, it was operation exception, but there might not be actually related to out of data I'm.

D

Concerned that people will throw in valid operation exception by dint of calling methods like readers string, we.

I

Go to one of the samples or argument exception, or maybe there's a mole ref accept.

D

A

A later than recommendation.

I

A

Those ones would be fine, you would just I'm.

D

Not concerned about no reference section, because.

C

I usually mean the bug and he's gonna read for taupe-y time construing and it responds. But let's see the user did not know about that. Then do it and just cause the reader got their string and they rely on the fact that it gets to guessing. We throw we throw and we are measuring in an operation exception and now that catch is not being caught by the sea Eliezer and just be provided to user.

H

We could always catch the invalid operation exception if we snip the call stack and see it was thrown by the Jason layer.

C

H

A

I just had a heart attack, you're cutting out Jeremy you're, cutting out I, think you're lost oopsie.

D

Jeremy now you have to go to the roof.

D

I'll start walking, we.

A

Don't do california-style left turns on on api's yeah I, don't know like that seems fishy I mean. Is there any chance you can throw different except that they're on.

C

That, like no class decision in my operation, makes perfect sense. It.

A

Does but thank you, but now, but I think I think the problem that we have is that, like the general and pattern is you have basically an outer loop that has to get data yeah and you want an outer loop to basically reliably handle between the actual buffers and the code in between may not be user code, but that's kind of the scenario that we have. That seems like a general pattern that is not just applicable here.

A

That is generally true yeah the thing having a dedicated exception that just means I need more data, makes more sense, I'm about to write anymore.

C

Dear this is about somebody reading get calling getstring when they will be automatized. Oh no, it's not of that I also pretty sure.

J

I, don't think we should be throwing about elaboration. You should be thrown as a something that inherits from Jason exemption.

C

J

C

Call like that, don't you make something. We don't do that everywhere, anywhere else we're the data value. You have complete data. The user is a stain guard again support users.

G

Calling it incorrectly, they should have checked it token, tell you yes,.

I

Well: okay, so if I'm glad someone actually said that yeah, because if our API is encouraged, misuse that implies that our API is wrong. Well, I mean so.

D

I think so, I think the answer I think the answer here is in the discussion about try read like Steve Steve has a point about this and we have to make a decision about which direction. We're gonna go here right.

D

So like looking at the sample which Steve wrote, which only reads a single token like it does it does it checks the token type and says: is it a string and it's it's a case of explicit error, handling right, like the user, had to do work here to provide this error handling code, whereas if we want the user to write naive code that will throw on purpose and have that throw an exception, that's handled for you and turned into something useful by the serializer.

D

Then you get implicit error handling like if, if reader don't get string throws JSON exception and I'm not saying that implicit is necessarily better I'm saying that we have to make a decision here between explicit and implicit, and if the decision is for explicit error handling, then making these things be. Try read and returning false seems better well, I would versus Jim posted error handling. It seems worse so.

A

I would generally agree with you I. Think, though, like the the thing, if you think about what you what we just talked about right, it seems reasonable to me to say if, if the model, as you go away from try B, we just go to read and I think it's reasonable to say that straightforward coded user would write.

A

Basically, the two common scenarios are that Jason is invalid. You made an assumption that you're on a token type string, but you're not or you're running out of data, should not require exclusive coding by the by the converter guy right. They.

C

Should you should.

A

Just be able to say.

C

Train so that would be the zero.

A

Yes, honestly, that idea, which which, but that doesn't prevent somebody else to be explicit, error handling. It just means the only thing we change is the exception type that is being thrown right yeah. It just means that if somebody wants to avoid the exception, they can do the Tocco type check up front or call some other API, but it doesn't change the fact that we did not get string if you're not standing on the string.

A

Is it's an invalid operation of your world, but I would say that invalid operation is not really meant to be caught. We are for call sex up, because at that point you wanna know what the operation was. I think that's the kind of thing where okay, the immediate handler needs to handle it or you die, and in this case we don't want to die. I think.

J

What's going to happen, is we're going to end up with a lot of NuGet packages where the contents of the prior read method is going to be a try? Implementation catch bro Jason exception, because people are going to want to debug it and they're going to want to catch a single exception, type and they're not going to want to have to be like? Oh I have to go and handle all these cases by writing. 500 extra lines of boilerplate code checking every type and handling comments and everything.

I

Else this is no one's gonna write the Troy couch, because people never test failure, cases and I was able to say you can do much better. They just don't do any try it I just call them. My.

A

5 yeah I, don't know, I I think that it makes sense to me to say the you and Jason payload is invalid is a different exception from a random you called stream read and that cost and developer action except.

C

It's neither of those two cases well.

A

Is invalid, in the sense that that you should you basically either you have a vehicle? You have a permanent bug in your try week. Metacritic never worked or your paper is incorrect for what the method accepted. It.

J

So it's one of the other. The Jason is lexically correct, but that's intact.

A

I

But because here's a problem right, if in some scenarios, like the scenarios that Ryan brought up earlier, it actually is important to differentiate your Jason is not semantically correct versus, like ie just did something bonkers is a library and I'm going down hi.

A

Exactly which, but you bet you're saying then the same thing that I have said like it just needs a different exception time, because basically we don't want the get string case to cause the same kind of error as oh, you divide it by zero or whatever else you did in your code, but, like anything, where's it back in your code, you should just die. Everything else should be handled for you, but.

I

What I'm afraid of is in practice a framework like MVC is literally just going to have tab a try-catch or like try cash everything around you serialization and, if anything, it all happens, 400 the response and the reason for that is like I as a regular application developer like I'm, not going to realize all of these semantics with try read exception types, what exception types get mapped to what you HTTP error codes, all I realize is like I, don't want to get my pager to go off at 2:00 in the morning, but.

A

Why would that be different? Basically, what I would expect is that there's one loop there. Basically you you handle two kinds of exceptions. Right, one of them is I'm out of data, so get more data. The other one is the gelatinization. Exception happens, in which case you return 400 and then anything else is a 500. You just do you just say yeah, because.

I

A

I

Earlier, like the payload will always be lexical port going for the same life, because that's what is.

A

Right, they give you if you say hello comments, for example, data, but one of the converters doesn't handle that that.

C

That's okay, I am taking you to eat ahead and under for buying the coders you already really than one read validated. The Jason is both valid and is innovative yeah.

I

Even that that was a question I asked earlier about. Does a converter need to know about all these different configuration switches that the reader might be operating in? The only one that came to mind was comments because stuff, like allowed trailing commas, is just dropped. Anybody when they obsessed, so you don't have to special show him in the room, but them because if you look at the samples here, like the the read array sample like there was no case token tight comma, it was just number read: go to the next one.

I

The next token is also number each one is its own standalone thing. Sure.

A

Other things you could write incorrect converter, co2.

C

Monitor it is both reader and writer, throw your option away right and then the model will be the same and adjacency Lizer continues to capture station exception right.

B

C

Or we don't change, the behavior of the existing API is, and the distance Iran is as a catch-all because otherwise it's very requiring users to especially through their jets.

A

It sounds to me like we really need to handle.

A

Kinds of hours differently right out of data, a generalized parsing exception and some other bucket to convert all right, I'm going to be able to decide which case you're in but just looking at the time which we can't do with. What's.

D

What's the out of data case I keep hearing about this, but when does that happen in a converter? Well,.

A

Basically, the converter gets a reader right to the converter. So let's say you are a you're in the middle of the payload. But well you don't have the rest of the payload. What you do you have to unwind the stack to get more data.

D

That's a guarantee that we provide with converters that you have enough data.

C

H

If you, if you read more than one value, which is a bug in the in your converter, because you should only read one value yeah, if you're given a start, object, you're guaranteed, you can get to the end object. If you're, given a start array, you're guaranteed you'll, get to the end of the array and I can give in the strangers guaranteed the whole thing there. There.

A

Must've missed that part. Okay, that makes sense. Okay,.

G

That guarantee cost performance in a stream. We're gonna, do it, but I'm proposing that we don't do that.

H

We need to do it because no one will ever get this API right if they need to handle the incomplete data state. Okay,.

G

So I mean it's just a note and you know we're deciding in this case right.

C

The first concern for of the serve we can continue to optimize, especially as the reader becomes faster and faster I. Don't think it's gonna show up it's not it's not significant I mean we basically.

G

Maybe it is significant I think you mean you have to double, read everything I'm.

C

Sure, there's a cost. Obviously the question is it doesn't matter in the gasps scheme of things or do double reading if Irina is twice as possible? Well,.

A

It also depends on what you do. Why there's only three options, but either you make sure you don't run out of data when you call the guy. The second thing is you throw an exception and then provide more data and then call read again: write more you're, basically forcing everybody to do the try, read pattern which I think you can achieve and will not work so see that the exception one enjoyed reading ahead before she, oh okay,.

G

Sorry, we talked um one of the explicit goals we had up front was performance and, as part of that goal, we explicitly said we will sacrifice um usability I, don't remember the exact term, it might have not been bought. Unquote, usability right, general feeling was that performance was paramount to usability um and now we're saying that it's not in this case. What.

A

I'm trying to say is that what else would you do because I think there's only two other options? One option is you basically say everybody has to do a try, read and then we turn the error code, in which case you also do a double read. If you run out of data, is you have to potentially unwind a few of those.

G

There's a difference, there's a difference here is that the only you can't run out of data if you're in a stream. Okay I mean we guarantee that so you can run out of data.

G

If you got a buffer that just Android in the middle I mean somebody passed you a string as a buffer and half the JSON was gone for whatever reason, because it's malformed, you will run out of data in that case, but then your your malformed in that case, but but it still requires the exact same check to say reader, get string our story on reader read. Did you return false? That means you don't have any more data that can still happen in an on screen case yeah. We can't get more.

D

E

G

G

But it's gonna also throw um what does that throw a meter. Reader re I mean just returns, false right.

C

Is true, I believe it's all just an exception. Yeah.

G

But if you call reader to read and there's no more data, it it'll just return false.

C

True and the stream and binary case you've all said it's not true, because you have no way of getting more data, so the toy that is okay,.

G

Okay, so so the reader will automatically throw in what what except there's a reader, throw I.

C

Believe it's a reader, okay,.

G

So um which will be caught by the serializer andrey thrown, so you don't have to check for the out of data. Yes,.

C

Yes, I need an exception. So that's what I'm saying like an extreme case where you don't have you can't have partial data, you have this capability to retry and get more data, which is why we don't throw find the Pyrenean strain case it'll. No, it's more input. Sync! So you pass. It is pal doc. True and if you happen to have no enough data, the reader will throw for you.

C

G

Long as the reader throws Jason exception on everything is I. Think normal I mean people would expect that.

C

H

We just be in the case where the reader, where is final, is false. Then the serializer should just call skip, and do that like to use the fact that it's a value type that it can make copied easily yeah it skipped throws. Then it throws there wasn't enough data, you couldn't do it and if it doesn't throws and everyone's guaranteed to successfully complete their object. Yes,.

C

And that's what is what correctly or.

L

I read ahead: does today oh yeah yep person.

E

For stream, that's the only one we have more data on. So that's what we did. Okay, we.

C

Skip and rewind I mean see you passed me by today. There's no point, we're saying: hey you renovate, unless ask for more, but we want more I was saying. If you cannot, stream is what is the other one call binary string? That's it! Oh, you mean, like we only sequence, yeah, whatever that's not a little bit here, because it's only for the lower level eater I see she either has to input my stream binary string.

C

G

That, okay, so effectively, um we don't read ahead, I'm proposing we don't read ahead, except for the stream case, because there's no way to unwind a call stack and reread so we have to read ahead and even on our case, we don't read ahead. If we get to that, we can get to the.

E

End right, yeah.

G

E

Cur in the final block, we stop right. So there's.

G

An optimization for that, if, if you run out of data in the spring or byte array case, um that would be user code that calls read or read or some framer coder before you know, we call the converter here. Yeah.

C

G

The proper exception will be thrown at that time. Yeah.

C

So what do we do about this case scenario here of guarding which is not guarding Fort Riley, for example, or even try right?

C

Do we say this? A user bug that disregarded themselves like what an unkind.

A

Shields it so, let's say, there's three cases where there are two kids where there is the stream slash by so it's the stream case and there's the by the way starts drinking is right in if it's, if it's by the way or a string- and you read the string when you're literally at the end- that's a like the payload is malformed.

A

That's the same as you expected the string when you go to bool or you expected a null and there's no, no, but that's just a malformed payload and it's the other case where there might be more stuff. So somebody has to advance the reader I'll be basically sore. I, basically get more stuff from the stream right and the next game. We are we saying that in the stream case, it will be transparent that this guy basically will never have the exception case. Or are we saying you user code has to handle that user.

C

A

C

A

Neck case I would say, get it so the only case we're get string would throw is when you're effectively at the end of the data- and there is no more data than I- would treat this exactly as any other string.

C

A

Because you caught it on the wrong token type, yeah, the other ones open, five or you literally at the end- is no nothing right.

C

In which case you know it's a that's.

A

That's it back for for the person that gave you the JSON. It's.

G

Read or read, if you want in here myself, yeah.

H

Get string won't throw because you ran out of data, the call to move would have thrown if you ran out of data if you you're looking at a token, the only reason get string will throw is the token type is not string Kornel. So.

A

That might be a different case inside of a converter if they read more than what to open right right.

H

So, if they're reading a complex object when they call move to get to the next part of it, that could throw the I ran out of data, but that call to move would have thrown and it would have thrown the Jason exception. It string only return, it returns a string or throws invalid operation, and that's it yeah. That's.

A

Payload is not form and I think. In that case we wanted to throw and not have before everybody to write the defaults go jason exception. We've expected some so.

C

Now that's a question like that. This is a quote: that user have I'm, saying the user to write the code on screen today, meaning that, if not the depth above, but if they don't have any property, the inner against ring is talking about operation and the see geyser does not catch that. Yes,.

A

And I think we said well, the.

H

Serializer catches, both invalid operation and Jayson exception, but not any other exception type, and we just document that it does those two things and everything else is: you know null refs arguments, exceptions, io exceptions. All of those are. This is not done by this platform itself. It is clearly your user code, we're not catching it we'll catch the occasional invalid operation exception that was really in the user code and we'll wrap them at the Jason's malformed. But it wasn't gonna work anyway, so it's better to be slightly wrong. In that case,.

G

Then make everybody have to do all the work. I think that makes sense. I mean yes, we need a list of exceptions. I know, format, exceptions, another one right.

A

Yeah I mean, ideally, we would yeah I mean you know, designers, we don't throw random exceptions, we base it through a consistent exception for all cases, I mean.

J

Couldn't you have a invalid Jason exception and an invalid.

J

Invalid Jason, for an exception, or something that way you can actually differentiate between user invalid operation and Jason invalid operation.

H

Okay, the the guideline is like we have exception types and you should use them and not reinvent them right. So the only reason we would want a Jayson and valid operation exception, so the serializer can catch it as distinct from the user, calling any other method themselves. That's really against our exception guidelines, that is a reader readers exception.

I

C

H

For the reader, its should the serializer catch the exceptions that the reader throws, because the serializer believes that the code users are going to write. Why can't.

E

A

Me Belem operation exception.

E

A

Would be deriving from invalid operation exception right can even that donkey can just catch you by looking at interception and people that don't they do care can differentiate them. Let's what we do in other places with like operation cancered exception that we have asked operation canceled exception and the general operation canceled exception,.

E

That sounds good at first blush, we.

J

Also have a note, because the invalid operation exception can be thrown in a wide variety of circumstances. It is important to read the exception message returned by the message: property. Basically, we throw this from too many places for it to actually be useful for differentiation, so you have to eat you string looking to be me. Meaningful I mean.

A

The thing about an operation exception, though, is it is a bug in your code like there is no sensible way to handle different bugs in your code differently, because each of them are effectively your process dies or your request dies like there's, no expectation that you can handle the catch language, which I think is one of the reasons why running out of data should not be in the same bucket as that running order of data is something you expect somebody else to actually act on and provide you more data versus you call the wrong API on the wrong token type you so.

A

Basically, your code is incorrect or your data is incorrect, but then, if your data is incorrect- and that is something you probably want to handle, the neck is also throwing about an operation. Exception is not necessarily the right behavior, either.

E

Well, I think deriving from that. We we know that that's probably the context here, so we're catching a JSON and valid operation exception and rabbit.

G

Okay, I mean first straw, man can we say we're gonna catch and read and read throws Jason exception. You know invalid operation or whatever else the reader throws and move on. I know. I know we have like 10-15 minutes left.

H

I, like the outline of that plan, and if we think that deriving and valid operation extension is a non public type, is the way to go. We can talk about that later, yep. It.

C

Does not become that exactly as Germany mentioned just having a great day, everybody.

A

Only father we will pay.

C

Api is discussed if a constructor of the base class, the Babel internal I, mean private mutiny.

C

We have discussed on our meeting yesterday. Oh yes way.

G

To let the talk, because.

C

What I wanna cover of this class is that the structure should be private, protected, yeah.

A

A

I would not make it protected if you expect people to derive from it. If you don't pick people to grab.

C

The gosh you've done so we expect people back on this day. You.

A

Don't make it internal or get protected and.

L

Then producing converter, yes yeah, but the Jarek one does to derive from it. Yes, the toy is protected. Yeah protected.

G

And chrome is protected and internal so I mean no. One else is kind of.

C

J

Is one provide right, everybody? That's then the problem ends up being. If you make it internal, you can't override, can convert the user can't override it, because it's internal, so they don't see it which one. So, if you make Jason convertor internal, no.

A

No, we just talked about the.

J

Constructor yeah.

I

All done people to derive from the style outside.

A

Of our library, which case either make it internal, which is effectively a way to say the only person that can drive from the disaster or you make it private protected, which basically means it's protected and internally, which means it just means within our own Cobras, a slightly more restrictive than internal, but like practically speaking its internal from the outside. Okay.

C

And then other questions was around just in converter, binder I'll be happy with that mean what do we do here? Yeah.

A

I would like to see Ryan's proposal because I would agree with you. It seems a bit weird.

C

D

So my concerns were around how they get registered and how they look like on options so for for Jason we can. We can move on to the next, so good, Jason convertor, binder in this case, is really kind of acting as I understand. It's really kind of acting as a factory or finders right or for converters.

D

What is what does get convert or return because it returns true like how do you actually win.

G

No I mean there's no try I, don't know how that bull got there. It should just be returning amazing cover yeah.

D

So it returns a converter or an old right. Yes, okay, this seems fine. Did we want the API yeah.

B

J

Seems like the try pattern is better for that. That way, we don't have to make it knowable and support no ability and everything like that. You sort through that. We need to make it out. No sir. This is a bit of a class because yeah.

A

J

Got patterns to handle that person well.

A

This ain't just mech another way to say that you return it now. Liberal converter right I mean yeah how.

H

It's all has to be knowable, because if it returns false, if I.

J

Make it return, we an ammeter that says not null win true, so we can just man, so users don't have to bang we're in their own code that wouldn't it was just compared to null and move on like.

A

I mean either way either check the a for you compared to not write what.

J

I know when we store it, we have to do a check and then I don't.

H

Think this is worth the try, because, first of all, our guideline with a try is, if you have a try, you should have an on try that throws if it was going to return false, which we don't want so just returned all.

C

It seems weird to do anything: oh yeah, yeah, so murder that it charges in the murder and.

D

So, in terms of in terms of the the collection on the serializer settings, let me scroll up like five lines of code. My idea with this is basically if we make a custom instead of I list on the on the settings object.

D

If we make a custom collection type, that's derived from collection of Jason converter, then you just add a method like call this call this collection, like binders or converter binders, and instead of being of type Jason converter, it's of type Jason, converter, binder and then just add a method as an accelerator to register converter of T and associated as the binder for that T. What.

C

Do you see now the binder is in everyone's, everyone has to be with the butter, then, rather really good people not.

G

Though it it's, it's a converter and people just knew if the converter, they don't know if it's a binder, I care. That's.

D

Why you have the accelerator so, like you add a so, the collection is a collection of its I collection or I list or it's um you know it's a derived class right. It's derived from collection T, but you add a method like so it's like imagine that it says: Jason, binder, collection, binders and you've had a method like register, converter or ad converter. That takes a JSON converter of T instance and then behind the scenes that creates a binder for you that operates on that T.

D

So you don't have to write a binder unless you're doing this more like specialized kind of stuff.

D

As how does the binder get plugged in, like we haven't said, we haven't, said how the binder gets plugged in in this clothes.

G

Looked at look at the example for that uses the binder for the list of team. Yes,.

J

He had the binder inherit from Jason converter itself, which I don't think, makes sense, which.

D

G

I don't know but scroll on to the list of T, though um scenario.

C

J

He was calling ad converter and passing behind in the sample. I didn't see.

C

Binder in there I take a look at.

J

C

One here, yeah.

C

G

Okay, it's derived from this converter binder right.

J

Right, so how are you implementing can convert? Because the binder didn't have a can convert meant.

C

G

Derives from Jason converter right.

J

And so that's what I was saying was confusing well.

G

Because I also said that this list that we have that Ryan was just talking about it- contains a base class of Jason converter, which is these are gonna, be a binder or the real Jason converter of T. The user doesn't care when they're adding these. They don't distinguish because they look the same. They don't see generics in the type or anything like that and we need a single list. So order can be changed and our my personal list of none but.

C

Your example is an abstract class, the variable a so very sadistic Roberto come again I'm. Actually following.

G

In this example, no.

C

Indeed, you propose this: a cummerbund is an abstract class that doesn't implement and it doesn't drive my it.

G

Implements get converter, I mean it declares, get converter, which is overridden here.

C

But RIT is the tank of württemberg the.

G

Base class of that.

K

J

What the API proposal doesn't have, it is a base class go.

G

Back up to the top I mean it's: it's the. Unless I have a title and convert exists on the base class, Jason converter.

C

G

Drives from Jason.

C

Which one is that people there before them? A very top.

C

So, if he'd like that to the binder to be waiting, okay, this is your binder class. How does google it it's.

G

C

G

Why some decent converter? Oh.

J

Okay, okay, I, see and I was saying, I think that's confusing to have a binder, which is also a converter, which does no conversion itself and has the type of check. Even though the get converter method returns null of the types not supported so you're like duplicating logic, and it's not clear how that should be implemented or anything right.

C

So there it is, we don't hit limit that Jessica murder on the binder or the genic of our body does not derive from just a conversion. Instead, we have the register method. That I am your solicitor on a custom collection.

D

Yep, so that so that puts binders sort of at the core of the registration paradigm and gives you a convenience API to register an instance of a converter using using a default implementation of binder. That is just going to use your like, can convert method.

J

Right so so you we would have a default binder instance. That's internal! That would have a field that contains a converter and a gate. Converter would just return the converter, yep.

D

Yeah and it would call it we call can't convert and if can't convert return true, it would return that instance, so it sort of wraps it up. The naming becomes a little bit less clear yeah, because you would look at that property and you would say I want to find converters and then there isn't something called converters. That's the one part of this plan that I don't like, which maybe we can fix yeah, but it seems like we could provide both of these scenarios really easily without doing your things with a type hierarchy.

D

Okay, can you walking, through.

G

That against I mean for the exact methods here, because um yeah so.

D

We remove the inheritance of JSON converter binder from Jason converter, so Jason converter binder no longer inherits from kasnia murder. We removed that. Then we go up to Jason serializer settings and instead of a list of JSON converter, we have a custom collection that derives from collection of JSON converter binder. So, instead of what's there currently, you have Jason converter binder collection binders as a as a public property, then on the implementation of JSON converter, binder collection, you add a method like call an ad converter or register converter or whatever you want.

D

That accepts a that accepts a jason converter instance, and so that method then adds to the collection for you a like default implementation of JSON converter binder. That does does like the default thing calls can convert on the jason converter and if it succeeds, returns that converter. So you basically for the simple case you get a binder for free and it supports both cases, but the collection and registration metric method is actually binder. Centric global with the collection, initializers.

D

I, don't think that that would be doable with collection, initializers and.

G

The only reason to have binders is for collections really well.

K

Or if you want to support.

J

Multiple types with one converter know.

G

Are you derived from Jason converter of team and you specify base class.

J

Well, I mean like if you wanted to support non-hierarchical as a set of non hierarchical types and still get the generic rather than boxing. You would end up omitting a binder to do that, which is crystal scenario: yeah. Okay,.

G

I mean if we want to treat that as a first class scenario, um then yeah, but in the end you of it, you end up just creating the same number of converters. You just have one binder.

K

G

I, don't really know if that helps.

E

I personally, I don't mind the awkwardness of it and I sort of liked it, but it was directly on JSON converter itself and then we have default implementations.

G

Not a 90 percent of converters will not use Jason converter binder I mean for examples. I have only that one did what they eat. They use the the list of team, but.

E

In either way like as long as it's I, like the single base class, just from the creation standpoint, I mean.

J

You can also have a collection, you can take Ryan's idea and have a collection, but have it be a collection of converters and you can have both an ad converter and a register binder method. And if you register a binder, then you internally have a nested.

J

So it becomes like, oh in or log of in, to walk the entire tree, but you can still do it where, like so I got.

A

These ordered crackly, so we're about to lose the room so like it seems like. We all agree that what the binder does offer feature-wise is what we want. It's just people would like to see this event more simplified, streamlined.

C

D

I agree, I, agree, I, think I think that we have the makings of something that solves the requirements and we need to make some small pivots or polished things a little bit. Yeah they're just.

G

For suggestion.

A

Yeah look so I would suggest we take that often I will copy and paste the notes in, and then we maybe do another round next week. If we, if you feel you have enough time to come up with a design like my the problem, is we need. We have like I, don't know a gazillion, more inaudible reviews that I have to like fill in at some point so going to be challenging to get everything done.

G

But the meeting, if you can't absolutely alrighty.

A

Then thank you for participation. All of you, it's a very block meeting here and if I look at the number of people that dialed in.

G

Ok, sorry, if you can stop recording and keep the meeting open for those I can stay on that us or not.

A

We'll have to leave the baby post most of be here yeah if I close the meeting, I think in the room, I think you guys can still hang out. I, don't think that longer followmolly, so bye-bye.