Re: implicit-context v0.0.1
On Friday, 29 September 2023 at 08:33:56 UTC, Imperatorn wrote: On Thursday, 28 September 2023 at 23:28:02 UTC, Guillaume Piolat wrote: Hi, Ever had a bit of feature-envy about Odin's "context" feature [1]? It is something used to pass "contextual" parameters, like a logger, an allocator, to callees. It is akin to Scala's "implicit parameters", or Jai contexts [2]. [...] Interesting, what are the benefits of using this instead of global variables? Context is dynamically generated/destroyed. I developed this Idea in 2009 with c#. We named this "functional context" (15 years ago)... I found out later something similar with AOP (Aspects Oriented Programming) when working with Spring in java Lets see an example ```d long create(PersonDto person) => withTransaction( (auto cnx){ // Perform person creation stuff long personId = cnx.execute( "insert into people ... returning id", [...] ).first!long("id"); return personId; }); long create(CustomerDto customer) => withTransaction( (auto cnx){ long personId = create( customer.person ); long customerId = cnx.execute( "insert into customers ... returning id", [personId, ... ] ).first!long("id"); return customerId; }); void main(){ withContext((){ CustomerDto customer = { code:"P001", person:{name:"Peter", nif:"3442543211F"}}; long customerId = create( customer ); }) } ``` The "withTransaction" function, iternally, asks the context if there is an opened transaction. * If not found: * It creates one and registers it into the context. * calls the delegate * commits the transaction and removes it from the context * returns the delegate result. * If an exception is thrown by the delegate, then the transaction is rollbacked instead commited and the exception is passed through to the caller. * If found: * Calls the delegate transparently and returns it's result This use case of "implicit-context" works naturally in a "per thread context". Stackability is nice: (this example is not so real, but a "how to" example): ```d void createPersonAction() => withHttpResponse( res => withAuthentifiedUser( user => withHttpBody!Person( person => withLogger("createPersonAction", (logger) { logger.info("Something to be logged"); auto id = withTransaction( cnx => cnx.execute(...) ); res.send(id) ) }); ``` It shoud be more natural this way ... ```d void createPersonAction() => with( auto res = implicitHttpResponse()) with( auto user = implicitAuthentifiedUser()) with( auto person = implicitHttpBody!Person()) with( auto logger = implicitLogger("createPersonAction") ) { logger.info("Something to be logged"); with( auto cnx = implicitTransaction() ) { auto id = cnx.execute(...); res.send(id); // Bad place... there is an oppened transaction here!!! } }; ``` ... but remember than we need to manage "exceptions" dependant behaviours implicitly: **with(** is not an option for AOP. As you can see, this is not an "Object oriented dependency injection"... Each "withX" internally interacts with the context to find or create the resource and, additionally, performs some functional extra proccessing (before, after and exception). i.e.: withHttpResponse: * if res.send is called: this is the data to be serialized as a result (status 202) * if res.send is not called, then "404 not found" will be generated when delegate ends. * if an exception is raised by the delegate, it will be transformed in an "standard" http error As a ramarkable benefit: it is really simple to wrap with mockups when testing Problems? * It is "runtime" generated/consumed without compilation time verification (i.e.: you can call createPersonAction without an HttpRequest in the context )... but this is a dependency injection assumed problem. * You are in risk to move to "implicit context" too many things (remember that functions have parameters :-) ) It was only a possible use of "implicit context" :-) Best regards
Re: From the D Blog: Crafting Self-Evident Code in D
I think if `class` is a reference type, it should've been explicit: ```sh class C { ... } auto obj = new C(); void func(ref C obj) { ... } ``` I don't mind if it does not compile without the `ref`, but it should be on the table - WYSIWYG.
BeerConf Japan
hi, if you are in Tokyo right now, we are doing a small meetup this Sunday (2023-10-08) We are still planning the exact details where and when to go in the dlang-jp slack, probably evening at some cafe somewhere around Shibuya. I will post updates on exact locations here.
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 5 October 2023 at 08:46:50 UTC, Dom DiSc wrote: On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote: [...] he is has more interesting things to talk about than whether "enum { yes, no }" is a good idea or not. His point here was not that having an enum with values for yes and no is a bad idea. The bad idea is assigning yes the value 0. That's a much more subtle point, as here nowhere 0 is written. His point was that both are bad, but one in worse. And lets be honest, the problem is implicit casting of enums to int, and then to bool. Or the conflation of enums and manifest constants. If he wants to argue for self evident code then maybe that kind of thing needs looking at. Even the UFCS chain example is bad. Is... a.b.c() actually... "c(b(a))" or is it member function b() on object 'a' that returns an object with member function c(). It's not self evident is it? So yes UFCS makes the "pipeline" easier to read, but it actually makes the code more ambiguous if you dont know what each of the things is. So you need more context to understand it. That's what make this kind of mistakes so easy and I think it's well worth to explain it to less experienced programmers. If he was doing a talk to a bunch of inexperienced programmers then yes that stuff might be interesting, but he wasnt. You need to understand who your audience is, otherwise you risk wasting your and everyone elses time. It's not easy to make simple looking code. That has nothing to do with (coding-)style, it is all about not defining things a different way than it is usually done, so nobody mix it up. Sometimes it's very hard to find the correct order of things - often even experiments are necessary to determine what "usually" means. What he says is: Invest your time to find out what "usually" means, and that is not trivial, even if it sounds like it is. It requires a lot of experience to come to this conclusion. Investing time to make things look easy and obvious is well worth it, despite you're likely not payed (or in your case: honored) for it. While I agree with the overall gist I didn't find his examples very interesting or convincing. They were pretty much all made up to illustrate, outdated, or disingenuous (the first one with the intentionally obfuscated code). It would have been far better if he had actual real code examples he'd cleaned up.
Re: From the D Blog: Crafting Self-Evident Code in D
On Thursday, 5 October 2023 at 00:53:45 UTC, claptrap wrote: [...] he is has more interesting things to talk about than whether "enum { yes, no }" is a good idea or not. His point here was not that having an enum with values for yes and no is a bad idea. The bad idea is assigning yes the value 0. That's a much more subtle point, as here nowhere 0 is written. That's what make this kind of mistakes so easy and I think it's well worth to explain it to less experienced programmers. It's not easy to make simple looking code. That has nothing to do with (coding-)style, it is all about not defining things a different way than it is usually done, so nobody mix it up. Sometimes it's very hard to find the correct order of things - often even experiments are necessary to determine what "usually" means. What he says is: Invest your time to find out what "usually" means, and that is not trivial, even if it sounds like it is. It requires a lot of experience to come to this conclusion. Investing time to make things look easy and obvious is well worth it, despite you're likely not payed (or in your case: honored) for it.