00:00:06.291 --> 00:00:07.811 So as I say, stuff is a very one.
00:00:12.691 --> 00:00:15.481 OK, so a couple of key def.
00:00:16.351 --> 00:00:20.441 Basically, we have all that old stupid crap like colon set a
00:00:20.441 --> 00:00:24.195 string and key dev concept string in pair and key death
00:00:24.195 --> 00:00:25.871 blah blah blah blah blah.
00:00:27.081 --> 00:00:28.431 There are very annoying to work with.
00:00:28.841 --> 00:00:29.641 Nobody likes them.
00:00:30.161 --> 00:00:30.671 I like them.
00:00:30.681 --> 00:00:31.101 I wrote him.
00:00:32.471 --> 00:00:37.098 So somebody who, somebody who we should really hire back, came up
00:00:37.098 --> 00:00:39.131 with the idea that we should.
00:00:39.571 --> 00:00:42.676 They're just write one class that could do this thing
00:00:42.676 --> 00:00:45.551 automatically, and so we came up with this thing.
00:00:45.911 --> 00:00:47.371 You can give it an arbitrary tuple.
00:00:47.991 --> 00:00:52.359 It will at runtime generate a brand new method that handles
00:00:52.359 --> 00:00:56.799 calling all the different parse methods, or whatever else it
00:00:56.799 --> 00:01:01.239 needs to in order to take a string and then put it into that
00:01:01.239 --> 00:01:05.680 format plus an arbitrary number of fields using the Ethiopic
00:01:05.680 --> 00:01:10.484 section mark as a separator, and now the reason we didn't go with
00:01:10.484 --> 00:01:14.852 JSON and basically just to keep it, I guess simpler to work
00:01:14.852 --> 00:01:15.871 with. Overall.
00:01:16.221 --> 00:01:18.721 Obviously there's something side for Jason parsing, but that
00:01:18.721 --> 00:01:19.991 introduces a bunch of overhead.
00:01:20.361 --> 00:01:24.041 You have things like characters have to be escaped, et cetera.
00:01:24.921 --> 00:01:25.981 Uh yeah.
00:01:28.871 --> 00:01:33.691 So we, Justin with this, it's a simple just split meth thing.
00:01:34.091 --> 00:01:37.331 I am thinking about making this thing actually like configurable
00:01:37.331 --> 00:01:40.521 and sometime in the future it's like we need to define your Ed.
00:01:40.531 --> 00:01:42.351 You could just define what you're separating.
00:01:42.361 --> 00:01:42.941 We're gonna be.
00:01:43.531 --> 00:01:46.081 But for the time being, this thing is recognizable.
00:01:43.581 --> 00:01:43.811 Uh.
00:01:46.271 --> 00:01:47.281 It's printable.
00:01:47.661 --> 00:01:49.381 It's at least pastable.
00:01:49.991 --> 00:01:50.961 Maybe not necessarily.
00:01:50.971 --> 00:01:55.866 Typable that and you, uh, so currently there are three
00:01:55.866 --> 00:02:00.851 different ways that an element can be inside the tuple.
00:02:01.081 --> 00:02:03.751 It can be a string, in which case you know we just split it.
00:02:04.541 --> 00:02:06.996 We should probably later get some sort of check in there to
00:02:06.996 --> 00:02:08.591 make sure it doesn't have any picture.
00:02:08.631 --> 00:02:08.881 Yeah.
00:02:08.921 --> 00:02:10.041 Ethiopic section mark.
00:02:10.811 --> 00:02:14.967 But if we actually get somebody who really has that a real data,
00:02:14.967 --> 00:02:17.461 I will buy a chocolate hat and eat it.
00:02:18.381 --> 00:02:18.661 Yeah.
00:02:21.271 --> 00:02:24.411 Although we have friends and more countries, I thought so.
00:02:26.481 --> 00:02:31.437 If it's an enum, it will call the enum parser method just like
00:02:31.437 --> 00:02:36.078 the standard enum that parse, otherwise it will go through
00:02:36.078 --> 00:02:41.033 this fine parse logic here, so it will try to find some static
00:02:41.033 --> 00:02:44.101 function which is named parse returns.
00:02:44.111 --> 00:02:46.541 You know, whatever type is actually inside the tuple.
00:02:47.591 --> 00:02:51.934 Uh has one parameter, this parameter the string blah blah
00:02:51.934 --> 00:02:56.427 blah blah and then if it can find that it'll just call that
00:02:56.427 --> 00:02:57.401 the directly.
00:03:00.411 --> 00:03:03.198 So again, this thing is generated at runtime, so we can
00:03:03.198 --> 00:03:06.036 also edit this and I was thinking that's probably a good
00:03:06.036 --> 00:03:07.081 thing to go over now.
00:03:07.331 --> 00:03:11.481 If there's anything that we should add in as a standard like
00:03:11.481 --> 00:03:15.699 possibility for these, but these three alone cover 90% of use
00:03:15.699 --> 00:03:19.781 cases like typically you're gonna have like maybe a string,
00:03:19.781 --> 00:03:24.203 some sort of numeric thing which the parcel will cover, and then
00:03:24.203 --> 00:03:27.741 maybe an enum which the enum parcel will cover. So.
00:03:29.721 --> 00:03:36.110 Uh, and then for going back the other way, into formatting as as
00:03:36.110 --> 00:03:40.041 a string, we actually generate a thing.
00:03:40.051 --> 00:03:42.709 Right now, we might in the future, but for now, technically
00:03:42.709 --> 00:03:45.455 Itup will actually implement an interface that you can use to
00:03:45.455 --> 00:03:48.335 get an arbitrary element out of it as an object, and fortunately
00:03:48.335 --> 00:03:50.151 you can't actually use it to write back.
00:03:50.161 --> 00:03:55.289 I don't think which is stupid, but so we just do that and then
00:03:55.289 --> 00:03:57.731 yeah, just send that back out.
00:03:59.791 --> 00:04:04.666 Now what this change here in particular does it adds this any
00:04:04.666 --> 00:04:05.531 tough null.
00:04:05.901 --> 00:04:08.666 So in the standard of thing, and of course this will only work
00:04:08.666 --> 00:04:11.299 for elements of the tuple that are reference types, because
00:04:11.299 --> 00:04:13.801 they're the only things that can be implicitly knowable.
00:04:15.461 --> 00:04:18.451 It will go through there.
00:04:18.521 --> 00:04:22.259 Check to see if any of those reference types are nullable, or
00:04:22.259 --> 00:04:26.057 rather are nulled, and if they are null, the entire thing just
00:04:26.057 --> 00:04:26.841 becomes null.
00:04:27.131 --> 00:04:31.646 So that just mirrors the standard behavior of uh, like no
00:04:31.646 --> 00:04:35.071 elements of an LED key should ever be null.
00:04:36.011 --> 00:04:38.071 Uh, yeah.
00:04:38.941 --> 00:04:40.061 So that's really the change there.
00:04:41.711 --> 00:04:44.949 I think that that's probably mostly from controversial
00:04:44.949 --> 00:04:45.361 change.
00:04:46.661 --> 00:04:48.981 Like, I don't think this is gonna break anything for
00:04:48.981 --> 00:04:49.331 anybody.
00:04:50.591 --> 00:04:53.951 Figure we should so just go over it and then also like I said,
00:04:53.951 --> 00:04:57.364 just this thing in general, see if there's like any low hanging
00:04:57.364 --> 00:05:00.404 fruit that we should add probably especially with parser
00:05:00.404 --> 00:05:00.831 methods.
00:05:02.071 --> 00:05:06.739 Are there any types that anybody has used with Ed other than
00:05:06.739 --> 00:05:07.351 strings?
00:05:07.991 --> 00:05:14.141 Uh integer slash longs and you norms like anything beyond that.
00:05:15.481 --> 00:05:17.711 They've only, but I think that I'll already work.
00:05:15.731 --> 00:05:16.521 Nothing I lost.
00:05:18.941 --> 00:05:19.321 Which ones?
00:05:20.091 --> 00:05:24.001 Date only Epicor eagle is horrid.
00:05:23.711 --> 00:05:31.871 Umm, sorry, I didn't know that the bit only as a parse. Yep.
00:05:26.691 --> 00:05:26.791 You.
00:05:29.011 --> 00:05:32.671 It part of the transaction Key is the date field.
00:05:35.041 --> 00:05:36.471 It has a daily parse here.
00:05:36.541 --> 00:05:39.001 Now do.
00:05:40.531 --> 00:05:43.096 Oh boy, we're getting the culture info now though, because
00:05:43.096 --> 00:05:45.921 I think the two strings get a 2 string for your current culture.
00:05:46.511 --> 00:05:50.057 And then because then like obviously the purse could then
00:05:50.057 --> 00:05:53.971 purse back in different culture theoretically, but probably not
00:05:53.971 --> 00:05:54.521 an issue.
00:05:56.191 --> 00:06:01.561 So yes, they're only should should work as is right here.
00:06:02.971 --> 00:06:03.581 Hello.
00:06:03.651 --> 00:06:06.221 Let me check what's the default.
00:06:05.661 --> 00:06:08.061 When you just do this, could you do the standard?
00:06:08.781 --> 00:06:09.241 What is it?
00:06:09.251 --> 00:06:11.631 ISO 8601 or whatever it is.
00:06:13.641 --> 00:06:16.351 Without that, will need to do for the format.
00:06:16.361 --> 00:06:21.231 Right now I just want to see uh, but what?
00:06:21.241 --> 00:06:24.101 The standard format that actually uses is.
00:06:29.971 --> 00:06:31.321 So if I just two strings up in.
00:06:33.921 --> 00:06:34.451 Yuck.
00:06:36.641 --> 00:06:36.911 Why?
00:06:39.031 --> 00:06:41.041 And I'm betting that's based on the locale too.
00:06:42.061 --> 00:06:46.585 Yeah, that we may wanna see for able to E like make it detective
00:06:42.351 --> 00:06:42.591 Yeah.
00:06:46.585 --> 00:06:49.021 that can provide a culture or not.
00:06:50.231 --> 00:06:53.591 Uh, I think maybe Ohly.
00:06:50.991 --> 00:06:51.381 Order.
00:06:53.601 --> 00:06:53.731 Yeah.
00:06:53.741 --> 00:06:55.981 Let me see you.
00:06:57.631 --> 00:07:00.063 I don't think 2 string has an actual overload for a culture
00:07:00.063 --> 00:07:00.711 though, does it?
00:07:02.521 --> 00:07:02.721 Yeah.
00:07:03.261 --> 00:07:04.641 Or let's see.
00:07:05.611 --> 00:07:10.301 Well, I mean the generic objects just trying, yeah.
00:07:06.501 --> 00:07:08.291 I know it does on some types.
00:07:08.301 --> 00:07:12.741 Does string dot format allow you to specify culture at all?
00:07:15.311 --> 00:07:17.856 You know, it would be annoying to have to use string dot format
00:07:15.751 --> 00:07:20.301 Uh, check that I can use the pen format at least.
00:07:17.856 --> 00:07:18.731 or anything like that.
00:07:26.041 --> 00:07:26.481 You good?
00:07:30.561 --> 00:07:32.951 And gives a format provider, so that should actually work.
00:07:41.901 --> 00:07:45.444 Anybody ever actually wanted to use a particular culture in C
00:07:45.444 --> 00:07:47.501 sharp other than invariant culture?
00:07:48.601 --> 00:07:49.571 That's a great question.
00:07:49.151 --> 00:07:49.521 And then.
00:07:50.001 --> 00:07:50.691 Not they've ever seen.
00:07:56.381 --> 00:07:57.131 OK.
00:07:57.231 --> 00:07:58.411 Well, looks good.
00:07:58.421 --> 00:07:59.361 Then what's the problem here?
00:08:02.081 --> 00:08:02.291 About.
00:08:07.591 --> 00:08:07.791 OK.
00:08:09.731 --> 00:08:11.561 Wait, but.
00:08:16.271 --> 00:08:17.851 The wait, what?
00:08:16.421 --> 00:08:19.861 Oh yeah, forget C sharp cannot auto generate those types of
00:08:19.861 --> 00:08:20.721 things I think.
00:08:22.191 --> 00:08:23.341 You can.
00:08:23.411 --> 00:08:24.441 How does that gonna work, though?
00:08:24.451 --> 00:08:26.111 Because that's going to get evaluated first.
00:08:27.321 --> 00:08:28.641 That can't possibly work.
00:08:27.761 --> 00:08:31.271 So the append interpolated string handler.
00:08:31.941 --> 00:08:35.667 Essentially, you can use that to handle interpolated strings
00:08:35.667 --> 00:08:36.461 customizable.
00:08:36.421 --> 00:08:40.051 Hey, yeah, I've done that, huh?
00:08:40.421 --> 00:08:41.061 Yeah, there's all that.
00:08:42.461 --> 00:08:45.996 I'm going to stick with the other one because that just
00:08:45.996 --> 00:08:47.321 gives me the heavies.
00:08:47.451 --> 00:08:48.441 It feels wrong.
00:08:49.901 --> 00:08:50.811 Yeah, like it.
00:08:51.511 --> 00:08:54.951 It just breaks all assumptions of what's C sharp does.
00:08:57.681 --> 00:09:00.837 You don't want it to make a specific shrout just from the
00:08:57.981 --> 00:08:58.131 But.
00:09:00.837 --> 00:09:02.851 formatted string and then pass that.
00:09:02.641 --> 00:09:06.720 Well, I actually would like that if they use a different syntax
00:09:06.720 --> 00:09:09.971 like maybe percent strings or something like that.
00:09:09.981 --> 00:09:13.896 So like you do like this and then that's only ever going to
00:09:13.896 --> 00:09:16.571 be passed around the center of template.
00:09:18.041 --> 00:09:18.511 Doesn't.
00:09:18.351 --> 00:09:19.121 That would be kind of nice.
00:09:18.561 --> 00:09:22.145 Uh, I have found a library that would do that with loggers and
00:09:22.145 --> 00:09:22.941 stuff as well.
00:09:25.281 --> 00:09:28.143 There you can use interpolated strings but still get the
00:09:26.151 --> 00:09:26.531 Yeah.
00:09:28.143 --> 00:09:30.001 benefits of the the explicit syntax.
00:09:31.071 --> 00:09:34.562 I mean, I actually do use the interpolated string handler in
00:09:34.562 --> 00:09:35.191 Salesforce.
00:09:35.201 --> 00:09:35.741 I believe it was.
00:09:36.901 --> 00:09:39.434 It's like you can directly interpret it in whatever
00:09:39.434 --> 00:09:40.311 arguments want it.
00:09:40.321 --> 00:09:43.941 It'll properly format them for SQL or SQL, whatever that is.
00:09:47.261 --> 00:09:50.280 I've actually for a couple connectors wanted to do that to
00:09:47.581 --> 00:09:48.631 But yeah.
00:09:50.280 --> 00:09:52.531 where it could handle date times correctly.
00:09:52.681 --> 00:09:53.721 When you're like filtering.
00:09:55.931 --> 00:09:56.951 Yeah, we should probably just.
00:09:56.111 --> 00:09:58.751 Because each system has its own format half the time.
00:10:00.051 --> 00:10:00.781 Like in four.
00:10:00.861 --> 00:10:01.251 That's fine.
00:10:02.051 --> 00:10:05.360 But that would also require investing in the connectors a
00:10:05.360 --> 00:10:07.071 bit to make them nicer to use.
00:10:08.881 --> 00:10:09.811 I'm gonna stop you there.
00:10:12.851 --> 00:10:15.271 OK, so let's like where does culture for coming?
00:10:15.281 --> 00:10:17.011 Let's just double check what this thing is gonna give us.
00:10:18.151 --> 00:10:20.384 Was it NetSuite that each instance of NetSuite can have a
00:10:20.384 --> 00:10:21.231 different date format?
00:10:22.221 --> 00:10:22.341 Yes.
00:10:23.371 --> 00:10:27.691 Ohh yeah, if we have it as enough setting I've been.
00:10:23.531 --> 00:10:23.761 Yeah.
00:10:26.981 --> 00:10:27.191 Yep.
00:10:27.071 --> 00:10:30.295 And then you have systems like E9 where it's in the local time
00:10:30.295 --> 00:10:31.011 of the system.
00:10:32.221 --> 00:10:34.811 It's the same format always, but it's in the local time.
00:10:33.471 --> 00:10:40.043 I meanwhile, Unix timestamps are just sitting over there
00:10:40.043 --> 00:10:41.081 laughing.
00:10:57.131 --> 00:10:59.181 Also, Speaking of people are laughing.
00:11:00.171 --> 00:11:05.108 My college professor, who hated the dot dot dot dot dot dot dot
00:11:05.108 --> 00:11:06.111 of modern OP.
00:11:09.471 --> 00:11:09.711 Yeah.
00:11:10.301 --> 00:11:11.251 OK.
00:11:11.361 --> 00:11:12.921 So yeah.
00:11:16.221 --> 00:11:17.151 I don't know that's going to work.
00:11:18.441 --> 00:11:19.091 Yeah, Eric.
00:11:18.631 --> 00:11:21.977 So unfortunately, then that's probably just the default
00:11:21.977 --> 00:11:23.351 invariant culture then.
00:11:26.861 --> 00:11:27.801 For date only.
00:11:28.071 --> 00:11:28.211 But.
00:11:31.001 --> 00:11:32.591 That's not invariant at all.
00:11:32.851 --> 00:11:35.751 Like, aren't we basically the only country in the world?
00:11:35.761 --> 00:11:39.621 But does that, yeah, racism of confidential time?
00:11:38.481 --> 00:11:41.512 I mean, the main thing that's invariant is the fact it doesn't
00:11:41.512 --> 00:11:43.581 change, you know, between when you run it.
00:11:47.391 --> 00:11:47.921 Yeah, yeah.
00:11:47.931 --> 00:11:51.773 I mean, it just feels weird that I'm variant wouldn't be the
00:11:51.773 --> 00:11:52.781 global standard.
00:11:53.771 --> 00:11:57.649 And then if you do except make it print out specifically, then
00:11:54.181 --> 00:11:54.991 I'm yeah.
00:11:57.649 --> 00:12:01.650 you wanna parse it specifically as well, because then do we also
00:12:01.650 --> 00:12:03.251 want to handle date times.
00:12:02.581 --> 00:12:02.811 Yeah.
00:12:03.901 --> 00:12:06.151 I would hope that that's not part of the key.
00:12:04.181 --> 00:12:05.131 Ohh no.
00:12:06.181 --> 00:12:11.354 Well, I mean, I'm pretty sure I'm pretty sure date only will
00:12:06.301 --> 00:12:09.132 Let me see what Eagle has real quick because I think time only
00:12:09.132 --> 00:12:10.121 is part of it as well.
00:12:11.354 --> 00:12:16.188 probably parse unambiguously like I'm gonna put in year,
00:12:16.188 --> 00:12:17.121 month, day.
00:12:17.731 --> 00:12:19.821 And I don't write anything any and.
00:12:19.831 --> 00:12:21.691 And yeah, in any other way so.
00:12:57.211 --> 00:13:02.013 Yeah, the the key for the header of an invoice in Epicor Eagle
00:13:02.013 --> 00:13:06.967 includes the date, the time, the store, and then the transaction
00:13:05.641 --> 00:13:06.581 Probably first.
00:13:06.967 --> 00:13:07.501 number.
00:13:07.511 --> 00:13:09.901 Because why would you make the system sane?
00:13:11.201 --> 00:13:13.972 And of course, they have to be stored separately because like
00:13:13.972 --> 00:13:16.743 we don't want to be able to sort by all of those at once, and
00:13:16.743 --> 00:13:17.771 that would be terrible.
00:13:21.741 --> 00:13:25.329 Especially since the time is a string because it there are some
00:13:21.781 --> 00:13:21.931 They.
00:13:25.329 --> 00:13:27.291 that are just blank for no reason.
00:13:31.141 --> 00:13:31.731 Time me.
00:13:31.741 --> 00:13:32.491 Nothing to you.
00:13:33.531 --> 00:13:34.431 Yourself developer.
00:13:38.901 --> 00:13:39.401 I'm just kidding.