[09:09:55] <MirahezeRelay>	 <pskyechology> superb, they shouldn't disappear anywhere anymore then
[09:38:20] <MirahezeRelay>	 <originalauthority> I hate that interfaces and abstract classes require function parameters to be the same ugh
[09:48:57] <MirahezeRelay>	 <kockaadmiralac> You mean, they don't let you add optional parameters
[10:15:25] <MirahezeRelay>	 <originalauthority> No, I mean in some cases I need to do the same thing but a different way with different parameters all together passed to the function
[10:16:52] <MirahezeRelay>	 <originalauthority> Which I get defeats the point of an interface or abstract class to some degree, but there should be some kind of type that I can implement that says “you must implement these methods, we don’t care how you do it or what parameters you use/type, but you must return a string” for example
[10:17:09] <MirahezeRelay>	 <originalauthority> But for now I guess I’ll just work around it by not declaring those methods in the base class
[10:26:04] <MirahezeRelay>	 <kockaadmiralac> But accepting entirely different parameters in inherited methods kind of defeats the point of inheritance/interface implementation, whose promise to the user of the base class methods is that every inherited method has the same input/output shape
[10:30:46] <MirahezeRelay>	 <originalauthority> It does, you’re right
[10:30:55] <MirahezeRelay>	 <originalauthority> But in this instance it saved a lot of code duplication eg
[10:32:46] <MirahezeRelay>	 <originalauthority> [1/3] https://github.com/Universal-Omega/PortableInfobox/blob/0bb334ced8e2a71fe585fb49b23ea7d5b7192e4b/includes/Parsoid/ParsoidPortableInfoboxRenderService.php
[10:32:47] <MirahezeRelay>	 <originalauthority> [2/3] https://github.com/Universal-Omega/PortableInfobox/blob/0bb334ced8e2a71fe585fb49b23ea7d5b7192e4b/includes/Services/PortableInfoboxRenderService.php
[10:32:47] <MirahezeRelay>	 <originalauthority> [3/3] both these do eseentially the same thing but require different parameters because parsoid is dumb
[10:34:03] <MirahezeRelay>	 <originalauthority> I had originally just copied the entire file and changed the namespace but it was a lot of duplication when only 3 or 4 functions were actually different, so I created an Abstract base class, but that is now reliant on ensuring that the methods that arent in the base class (because they cant be) being added
[10:35:15] <MirahezeRelay>	 <originalauthority> Which is a necessary trade off but we loose some protection in ensuring that those methods are actually there - we’ll only know whether they’re there when we actually try to call them, rather than the interpreter straight up throwing an error that ClassX is not compat with the abstract
[10:37:26] <MirahezeRelay>	 <kockaadmiralac> renderMedia looks the exact same, why couldn't that be in the base class
[10:41:27] <MirahezeRelay>	 <originalauthority> That example linked is missing a commit or two which I havent pushed yet but essentially the render media bit for Parsoid needs an instance of the ParsoidExtensionAPI because for Parasoid we need to call $api->renderMedia to get the file url with the correct attributes
[10:42:49] <MirahezeRelay>	 <originalauthority> Or actually looking back now I can potentially do that earlier in the call stack so that renderMedia gets the correct stuff at the point its called
[10:42:54] <MirahezeRelay>	 <originalauthority> That might be better
[10:44:21] <MirahezeRelay>	 <originalauthority> (But in any case if anyone has any improvements they can suggest to this feel free 🙂 )
[10:44:45] <MirahezeRelay>	 <kockaadmiralac> So the issue here is that some of these methods need a ParsoidExtensionAPI passed in the Parsoid version but not in the legacy version?
[10:46:54] <MirahezeRelay>	 <originalauthority> Yep
[10:47:28] <MirahezeRelay>	 <originalauthority> I guess my other option is to add a ->getExtensionAPI call on there somewhere which might be better 🤔
[10:47:55] <MirahezeRelay>	 <kockaadmiralac> Couldn't the extension API be stored as an instance variable
[10:48:55] <MirahezeRelay>	 <kockaadmiralac> Or is ParsoidPortableInfoboxRenderService instantiated before you can access the extension API
[10:50:42] <MirahezeRelay>	 <originalauthority, replying to kockaadmiralac> That’s a good shout
[10:51:06] <MirahezeRelay>	 <originalauthority> Its available at the point its created so it should be possible which would be a lot better than the current implementation
[15:28:27] <MirahezeRelay>	 <rodejong> [1/2] IIRC we had a period where we didn't get logged out, for visiting new wikis?
[15:28:27] <MirahezeRelay>	 <rodejong> [2/2] It seems I am now again. Or am I mistaken?
[15:49:22] <MirahezeRelay>	 <cosmicalpha, replying to kockaadmiralac> I made a phan plugin to disallow all optional because I dislike them lol. I like things to be completely explicit which makes the code easier to read etc... especially when also using named parameters.
[15:50:58] <MirahezeRelay>	 <cosmicalpha> Its not on PI and probably won't for a long time, if ever, but I used it on some Miraheze extensions which I originally made it for anyway.
[16:03:11] <MirahezeRelay>	 <cosmicalpha> @originalauthority FYI https://github.com/Universal-Omega/PortableInfobox/commit/1a6c2d833be0afaa44d6d918f400351e97c7c4cc you could rebase your PR with that also.
[16:04:25] <MirahezeRelay>	 <originalauthority> do you get notifications every time the CI fails when I push? Its failing every time because I haven't gotten around to the tests lol
[16:04:57] <MirahezeRelay>	 <cosmicalpha, replying to originalauthority> I don't lol I just happened to look and noticed just now lol