[03:08:01] I noticed the following after studying the code of the "Flinfo" app: [03:08:42] 1. https://gitlab.com/flinfo/flinfo/blob/master/flinfo/code/FlinfoIn.php is the base class [03:10:07] It contains a number of functions and abstract functions [03:12:18] The implementation of all the abstract functions are defined in the derived class "FlinfoFlickr" which I studied. [03:13:31] https://gitlab.com/flinfo/flinfo/blob/master/flinfo/code/FlinfoFlickr.php [03:14:05] 2. The other functions were invoked inside functions defined in the derived class "FlinfoFlickr" [03:22:09] Apparently it seems that "Each class shall have only one instance" [03:22:22] i.e., singletons [03:22:42] But that will defeat the purpose of OOP itself. [03:23:05] Did I miss something? [03:43:16] well, it's ph [03:43:18] *php [03:44:40] but as far as I see yeah each call to the php will create an instance, initialized with the request parameters https://gitlab.com/flinfo/flinfo/blob/master/flinfo/code/FlinfoFlickr.php#L74 [03:44:59] so on each call they are 'singletons'. [03:45:33] but in python flask it is a long-running process [03:47:01] if instances are instantiated with different request parameters, they aren't really 'singletons' [03:48:44] and no... flinfo could be rewritten to be so much prettier if it were in python, imo [04:07:37] hi [04:07:40] I was afk [04:09:19] it's okay [04:09:47] so how is OOP working here in Flinfo? [04:10:01] I'm not 100% sure [04:10:17] but afaict it creates objects for each request [04:11:20] Yeah. Aren't we going to do the same in g2c? [04:11:48] well, afaict from your code it's an opject per glam [04:11:52] *object [04:11:59] not object per request [04:13:38] I was thinking that when the user clicks the submit button after providing the URL/(glam+id) that's one request [04:13:50] yes [04:13:50] and we instantiate [04:14:33] but it wouldn't make sense when every instance is instantiate with same parameters right? [04:15:14] with url change paramater also changes. [04:15:19] Isn't it? [04:15:39] *parameter [04:15:40] https://github.com/infobliss/sibutest2/blob/master/OOP/GenericGLAM.py#L5 not what I see here [04:17:46] so do we make a constructor in the derived glam classes? [04:18:14] so that with every new url we instantiate an object [04:18:27] like in FlinfoFlickr [04:18:37] I don't see why the base classes and derived classes should have different constructors [04:19:02] the idea is nearly the same for all glams [04:20:34] ok [04:20:50] I was thinking that both g2c and Flinfo are doing almost the same job. [04:21:15] flinfo is super old code [04:21:28] right [04:21:32] it provides only file descripton page [04:21:38] not the actual upload [04:21:59] flickr2commons use flinfo to generate the page though [04:22:05] afaik [04:22:16] once the file description page is extracted uplaoding is easy [04:22:27] *uploading [04:23:17] do you think that it was not wise to define constructors in both the base and derived classes in Flinfo? [04:23:47] it looks pointless to me [04:24:19] ok [04:24:51] I mean if you tell me in more detail why you think so I will get the insight :) [04:25:21] i.e. what that's the difference between all of the constructors? [04:25:28] *what's [04:25:35] in the glam classes [04:26:08] if they are basically the same why not just put everything in the base class's constructor [04:26:13] python != java [04:26:54] ok [04:27:17] so you are saying the constructors are essentially the same for all the glams [04:27:32] well, what would be the difference? [04:27:38] in your opinion? [04:28:17] nothing once we have the metadata mapping done, no difference [04:28:28] exactly [04:30:03] So is it not enough of a reason to use this inherent inheritance relation and thus use OOP? [04:30:16] ? [04:30:26] in other words? [04:30:54] One base class and all glams inherit it [04:31:09] yeah? [04:31:09] since they will all use the same constructor [04:31:22] yeah [04:31:39] tey can override if something really special is needed [04:31:54] *they [04:32:09] but right now I don't see the necessity [04:33:17] * infobliss is thinking [04:36:03] so the way we were doing earlier seems good. [04:36:33] a set of generic functions instead of a base class that all glams will invoke. [04:38:31] what do you think? [12:17:15] sorry, went away [12:17:31] why do you find generic functions better? [12:19:15] one thing you will have to consider is that, if given a url to the glam image, the constructor will have to validate against the url to find the id [12:19:38] the validation regex is dependent on the glam [12:19:59] but the validation logic is the same for nearly all glams [12:21:57] I will let you know when I see infobliss around here [12:21:57] @notify infobliss [12:22:48] python does not have 'generic programming' unless you OOP [14:16:28] infobliss: see logs [15:21:06] hi [15:21:21] * infobliss has finished reading the logs [15:21:35] k [15:55:04] came from dinner [15:55:19] k [15:58:19] * infobliss is thinking if OOP is a choice then how do we go about it. [15:58:45] my idea is each instance represent an image in the glam [15:59:01] make constructor accept the id [15:59:17] a @classmethod from_uri [15:59:34] seperate the logic into @properties [15:59:48] *'@property's [16:00:23] and construct the wikitext in base class or in somewhere else [16:01:04] as of now the wikitext is getting formed in the base class itself [16:01:31] sure, but the glam api integration will be in glam classes [16:03:24] make constructor accept the id <= do you mean the unique ID of the image? [16:03:32] yeah [16:03:48] or what would you think? [16:04:49] hmm [16:05:57] as of now the core thing the derived classes were doing was to do the metadata mapping for each image and form a dict [16:06:09] so now [16:06:24] even that will be done inside base class. [16:06:28] Am I right? [16:06:57] yeah, but each value of the dict should be preferably done in the glam clases [16:07:00] *classes [16:07:19] the dict could be compiled by the base [16:07:30] actually wait [16:08:20] https://docs.python.org/3/library/string.html#format-string-syntax [16:08:34] just call the properties in the format string itself is okay [16:08:53] ok [16:09:12] .format(info=) [16:13:16] could you give me the link of the example usage of '@property's somewhere(may be github)? [16:14:12] https://github.com/wikimedia/pywikibot-core/blob/master/pywikibot/page.py tons of them here [16:14:20] search @property [16:14:34] thank you [16:15:43] also if you want some insane code I could show you some code I've written for my past school :P [16:16:10] lol [16:16:22] awesome [16:17:16] https://github.com/SHSIDers/oclubs/blob/master/oclubs/objs/base.py <= absolutely ridiculous [16:18:32] see eg https://github.com/SHSIDers/oclubs/blob/master/oclubs/objs/formattedtext.py [16:19:54] ok