@ramsey There's no reason to define interface for VO or data structure. They're not abstract on implementation level, unless you do something wrong like Active Record which mixes (exposed) data structure concept with it's processing.
@ramsey You're talking about UUID, aren't you? If so, then wouldn't call it VO even though it behaves like one due to encapsulation.
I've only skimmed through the repo. Too many classes for somone without domain expertise, so I can't connect all dots in my head to talk about refactoring. Customization seems pushed too far though - especially providing FeatureSet of all(?) objects used in factory looks weird to me.
Static constructors or a factory class? Which one you tend to prefer.
The factory method, as a pattern seems convenient for me as you can have a private constructor and guard different ways to construct an object with a different static method. However, factory method is meant for subclassing.
On the other hand, a factory, in some cases will leave unguarded the constructed object.
@thgs I use all of them for different purposes (sometimes combined).
Building HttpRequest for example:
Static constructor (transforming basic/primitive/default arguments), allows overriding server parameters,
Simple factory (cleaner code) in static constructor is dealing with all these ugly superglobals.
Recently I'm experimenting with nullable static constructors (private default) to avoid clunky exceptions in input VOs (separate static method listing validation errors) - so far so good.
@bobmagicii That's lazy code and I happen to used it yesterday in a test utility method. It was removing nodes from nested assoc array based on given list of paths (Iterate paths, iterate path segments and jump to next path if ref not found).
Production code wouldn't need it, because you'd have method removing single path with early return (skipping unset() after the inner loop).
@Crell Still worth trying to encapsulate representation instead of naming encapsulated capabilities. Too many "do-er" abstractions with technical jargon names (and functional decomposition that comes with it) for my taste.
For example, even sth nobody would question like: EventDispatcher::dispatch(event);
could've been simply: Subscribers::notify(event);
Been trying to get a HTML to PDF and DOCX thing going for a client...
Quite happy with HTML to PDF (using Puppeteer and Chrome).
The wheel falls off with the DOCX requirement - every solution we've tried so far (Aspose Words, Monolith CLI, Adobe) all have different issues with the output when converting from the PDF.
@regis That's taking advantage of being rich, but I wouldn't say it's the same as taking advantage of poor people that you buy stuff from. Unless I'm missing something here, I'd say quite the opposite.
@bobmagicii Whenever there's a context for non-object it should always be a Null object.
Primitive null is not a mistake itself, but it should be like virtual photon - use it to exchange information between adjacent particles, but don't let it travel.
@bobmagicii Everything is debateable if you have enough time. At this point I don't know how many clarifying questions I need to get it on topic.
For example:
What do you mean by "you get a null"? A client object? (that's not what I described as "traveling null") API user? (that would be more like empty body for 4xx response)
Why do you accept empty user if you don't want to respond to it?
What makes the difference between asking NullUser if he's registered and checking it for null?
Me: I HATE REDOING WORK @omerida: I hate being right, in this instance
Me: I always like being right, this is how our work relationship works so well @omerida: You’re not wrong
Replacing spaces with tabs, just saved 37MB. I don't think it's a worthy debate tabs vs spaces; but I will keep this in mind for particularly large documents.
I have used spaces for a long time. But VS-code refusing to re-format a >100MB document left me curious.
@m00min@lewiscowles1986 The only problem I have with tabs is that they become ambiguous when someone using tabs tries to align multiline statements.
Spaces become necessary in that case, but in order to keep flexibility tabs should be used only for "base indentation", and spaces for the alignment. What often happens is that spaces are used only at the end for adjustment, and for someone else different tab length kicks the code out of the screen.
All the people I interact with for my hobby of Magic: The Gathering are on Facebook. If I can’t talk to them via some kind of interop service if I delete my Facebook account, I will not be able to talk to them. I do not like Facebook. The people I want to talk to are there. DO YOU SEE THE PROBLEM?
New PHP RFC Proposal that combines Asymmetric Visibility with Property Accessors, now renamed as Property Hooks. It's an extremely useful feature for the language, but variations on this have failed to make the vote so many times previously
@MarkBaker It's not as useful as it seems IMO. To me it's just accessor methods that are sometimes faster to write while introducing lots of syntax and bad code potential. In other words tons of rules to solve minor inconvenience.
@alessandrolai I meant inconvenience of not having this feature. It doesn't solve any problem beside ability to use altered property values instead get/set methods (or through magic __get/__set).
Even if it aims to introduce syntax for asymmetric visibility, it's not an issue for currently used getters/setters.
@alessandrolai And for direct property access, the most common (and "healthy") asymmetric visibility use cases (public get; private set) could be covered by allowing modification of readonly in private scope & old immutability by encapsulation (which also removes the "clone problem").
One of my really big pet peeves is seeing a dependency injection container used as a service locator. Where constructors have a ContainerInterface argument and get services out of it.
Even worse, the container allows global access and is used as a giant global for your dependencies. Accessed anywhere you might wanna use something.
@cspray@kboyd I'm heavily against autowiring for 2 reasons:
IDE turns manual DI (factory) into clickable structures of execution paths.
What's more important: "when you have multiple implementations..." should not pose a problem, but a default solution. You often won't even get to a point of polymorphic composition (where OOP shows its strength) if people will do as reasonable thing as avoiding problems. These problems are then moved elsewhere and the simple solution remains undiscovered.
@ramsey Best season in terms of storyline for sure. Previous ones were deceptively procedural, teasing you with threads that seemed like they'd move plot in a certain direction, but at the end of the episode turned out to be irrelevant.
