#askFedi#fediHelp Is the following pattern known and does it have a name?
I have a number of classes (call them C1, C2, etc) that all derive from the same class B. I have a superclass (template, actually) D that derives from C1, C2 etc. To have a single B, the standard solution is to go with virtual inheritance to close the diamond (so far, so good).
@oblomov most of the newer languages (eg. #RustLang or #GoLang) don’t support inheritance between classes/structs. They only support implementation of traits, which only define interface and not implementation. In general, using inheritance for implementation reuse is brittle and I like to avoid it.
@BentiGorlich It is indeed not implemented at all in kbin indeed. It never was. So if we implement this, then Mbin has another new bullet point for on the readme page ;P
@dwardoric seeing too deep nesting and the code running off the screen to the right kinda screams at you to try and simplify it earlier and to move things to other functions 🤔
@ragb it's easy to mix them. For understanding when and how to use them you need a deep understanding of what they are meant to be used for, which newbies won't know or understand earlier in their career.
It happened a lot having parameters that you want to align and variable declarations and other things, but then having the tab key not expanding automatically to spaces means that you will use it in the middle of code to try to align things accidentally and inherently things will end up mixed.
@taxorubio Yeah, especially important, if you write files in binary mode and don't lock the bit sizes. We had that problem also during the 64 bit migration
I was pointed out yesterday to scodec for #scala. It has some important things there that seem very useful and will likely use it.
It's just pretty sad that such a known, useful, stable library has most of the site with incomplete docs, broken links and incomplete released version numbers.
In general the official #scala API docs are very very lacking and generally suck.
Methods have barely any description on them. There are no examples in most methods to understand them. Important methods and collections lack explanation of their characteristics related to performance, runtime, O notations of each etc. Barely describe where each is more appropriate vs others, etc.
I've just seen a #programming pattern in #PHP where a method could return two lists of things. Instead of doing that, it takes as a parameter a callable, and passes the two lists to the callable. Instead of:
[$a, $b] = getLists($param);
// Act on both lists.
we have:
$callable = function($a, $b) {
// Act on both lists
}
actOnLists($param, $callable);
@joachim Imposing a higher-order function where it just complicates things without any gain would (if at all) be an anti-pattern.
But it might be that the implementation of actOnLists is lazy w.r.t. the lists, which would improve performance in an otherwise strict (= eager) language in case not the whole lists are needed.
(Assuming getLists isn't a mere lookup but would have to actually produce (build / compute) the lists and their content.)
@das_g Thanks for the analysis! actOnLists() isn't lazy, but it does need to make queries. Further complexity is that it actually retrieves more than one pair of lists. I imagine the higher-order function pattern was written here to avoid returning an array of arrays, or writing a value object class for just this one purpose. I'm not sure how much of a gain I consider that though, as I find the current pattern hard to get my head round.
Welcome to Mads Tech Services, where innovative web design, expert development, and SEO mastery come together to elevate your online presence. We deliver top-notch web development services and handle requests with expertise, ensuring your journey is smooth and hassle-free. Feel free to visit my website at https://ahmadouabed.wordpress.com/ for more information or reach out to us via email: ahmadouabed16@gmail.com for any questions you may have.
That is, I want the data structures to project back and forth between multiple type hierarchies.
As a result,
• One type system won't have to serve all purposes.
• Smaller, specific models can reuse terminology (not by include nor dependency).
• DSLs would be easier to write.
• Some services won't have to be broken out into separate code bases.
• All hope for perfection may finally be abandoned.
@octorine I like the idea of having an ecosystem of compatible static type checking tools.
I was thinking it would be typed, but mostly in terms of interfaces (or mixins, traits and similar concepts). In-memory binary data structures would not be explicitly described by the type system, and would be managed by the runtime. Such management would include reconfiguring the literal structures to be represented by compatible terms/types.