Talk:Inversion of control

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Inversion of control. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090615045650/http://docs.codehaus.org/display/PICO/IoC+Types to http://docs.codehaus.org/display/PICO/IoC+Types

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:21, 15 November 2017 (UTC)

Lead paragraph

@Licriss: Can we come to some understanding about what needs fixing and how that should happen? “Calls into” is a normal idiom in programming, distinct from “calls”. When one says “calls”, one means to invoke a function. When one says “calls into”, one implies that there is a body of code with entry points, and the caller makes use of those entry points (which might be a function from a table, for example). The call may get routed opaquely into some part of the code being called that the calling code has no notion of. Any particular instance of “calling into” is a “call”, but in aggregate, they are “calling into”. Strebe (talk) 22:05, 14 August 2023 (UTC)

@Strebe: Overall this article is unnecessarily verbose and jargon heavy, I was hoping for simple agreeable changes bit by bit as I get time but obviously failed at that.

Used in this sense "calls into" might be used by some but "calls" alone in reference to library code is also fine and has usage even in technical documents. You can call functions but you can also call other code, libraries and APIs, the benefit removing "into" here is it is also common in non-jargon grammar e.g. "I'm going to call my friend in France", "I'm going to call France", but most wouldn't say "I'm going to call into France"

We could simply say "uses libraries" for the first part though which would be both simpler and less contentious and maybe "makes calls to" for the second, which is also legitimate in both the common and jargon senses

Side note do you have an objection to changing "the code that expresses the purpose of the program" to just "the custom code"? Licriss (talk) 21:11, 23 August 2023 (UTC)

I wonder if we come out of different cultures of English idioms in programming. “Call a library” actually sounds wrong to me, which is interesting, because we do say “call France”. I don’t think anyone would be confused by removing “into”, although I also don’t think anyone would be confused by leaving it. “The custom code” is pithy and probably generally understandable, so I am fine with it, but this article has a history of squabbles over that explanation, and I think it used to be “custom code”. Strebe (talk) 00:59, 24 August 2023 (UTC)

@Strebe I can see it was "domain specific" and before that mentioned "compile time" vs "runtime" profiling, which would be understood by a much narrower audience than its current state.

I was tempted to put that the custom code "calls out" to the libraries in procedural and with inversion the libraries call into the custom code, for its illustrative effect, but I think the main idea is that the library controls the custom code, although this phrasing seems too casual and probably not clearer either i.e. "custom code uses generic code from external libraries, but with inversion the libraries are given control of the custom code"

I really think this comparison deserves a diagram but I'm not sure what would be an appropriate format for this page Licriss (talk) 20:27, 3 September 2023 (UTC)

Usage of technical jargon as libraries and frameworks.

I re-read this article from the perspective of a non-technical person, If y'all could contribute a summary highlighting the essential points while maintaining the technical language, but also boiling down the concepts for anybody to read that would be great. Lamaoaj (talk) 15:29, 4 July 2024 (UTC)

History of the term vs. history of the thing

Not the term, but the thing itself was widely used in early GUI software development if I remember correctly. Even GEOS on the lowly Commodore 64 in 1986 operated that way, at least partially, and I'd assume the same was true about the early Macintosh GUI. So I think the section on history is misleading by looking too much on the history of the term "inversion of control" and not enough on the thing itself. -- 2A02:3030:612:D8A0:7F27:E26A:BE57:B243 (talk) 07:31, 6 August 2024 (UTC)

This is a common problem. Due to lack of literature or lack of familiarity with print literature, a lot of articles are skewed toward modern sources. If you have reliable sources, feel free to improve the article. Strebe (talk) 18:11, 6 August 2024 (UTC)

Confusing

After a superficial read, I notice this article is poorly written. I mean, anyone who reads it doesn't acknowledge some essential things about Inversion of control, as it's relation with dependency inversion. Another big issue (and the most evident one) is lack of cohesion and coerence: there isn't information recyclement, that is, the little and poor information it has is repeated many and many times. My suggestion involves the creation of new, clear headings (History, instead of Background; Examples, instead of Examples of code; Clean Architecture; ...), simplification of introduction paragraphs, and introduction of missing fundamental information. Sorry if I'm being very rough, my objective isn't to attack you, but instead to improve this article about a very important software engineering topic. Pedro Felgueiras (talk) 16:09, 23 August 2024 (UTC)

You should always feel free to improve. Be forewarned that there has been a lot of editing around the issues you mention because apparently editors do not agree about the relationship between dependency inversion and inversion of control. Also, for some reason, there doesn’t seem to be a lot of good literature on the topics. Strebe (talk) 00:48, 24 August 2024 (UTC)