gistfile1.weechatlog

10-08-25@10:16:24 (@t0m) class attributes are evil. Usually if you think you want them then your design is wrong. (Or at least you need to be veeery sure you know exactly what corener you're about to paint yourself into)
10-08-25@10:16:33 (@t0m) *corner
10-08-25@10:17:33 (@sartak) hitler used class attributes
10-08-25@10:19:55 (marcus) hitler used NEXT
10-08-25@10:26:17 (@osfameron) hitler wrote PHP
10-08-25@10:28:21 (Mithaldu) t0m: http://perlmonks.org/?node_id=856821
10-08-25@10:28:42 (Mithaldu) thinking about using them to return string-only stuff about the target/metric plugins
10-08-25@10:29:10 (Mithaldu) such as the column name a specific class of metrics would use in text tables
10-08-25@10:35:54 (@t0m) yeah, that sounds like a bad idea :)
10-08-25@10:36:00 (Mithaldu) what why
10-08-25@10:36:24 (@t0m) why can't / shouldn't that be instance data with a default?
10-08-25@10:36:27 (sjn) osfameron: don't forget that the first version of PHP was implemented in Perl ;-)
10-08-25@10:36:36 (Mithaldu) these metrics have no instances
10-08-25@10:36:40 (Mithaldu) ever
10-08-25@10:36:57 º¹º¹ Join» (daxim) (~daxim@81.16.153.112)
10-08-25@10:37:02 (Mithaldu) they're used entirely as classes and their functions called as class methods
10-08-25@10:37:29 (@t0m) erm, but nobody would ever want to run two different sets of metrics on two different sets of code, and output them in different ways?
10-08-25@10:37:34 (@t0m) No, wait, they would...
10-08-25@10:37:35 (Mithaldu) since, basically, each metric is just a package encapsulating a specific function, a few pieces of meta data and nothing else
10-08-25@10:38:14 (@t0m) And them being classes, with class data, means that nobody can ever change the metadata or use them differently 2 times in the same program.
10-08-25@10:38:15 (Mithaldu) i'm sorry, i don't quite follow
10-08-25@10:38:17 (@t0m) FAIL
10-08-25@10:38:39 (@t0m) Well, say you have a 'has too long methods' class.
10-08-25@10:38:53 (Mithaldu) nah
10-08-25@10:38:55 (@t0m) And the attribute is 'maximum method length before I complain'
10-08-25@10:38:57 (Mithaldu) it would be a
10-08-25@10:39:13 (Mithaldu) "count_too_long_methods" class
10-08-25@10:39:21 (@t0m) right, sure :)
10-08-25@10:39:21 (Mithaldu) oh
10-08-25@10:39:30 (@t0m) But I have old code, and new code.
10-08-25@10:39:41 (@t0m) I'd like to apply more lax policies to the old code than the new code.
10-08-25@10:40:08 (@t0m) I can't, without 1) Change global state. 2) Scan all old code. 3) Change global state. 4) Scan all new code.
10-08-25@10:40:10 (Mithaldu) oh!
10-08-25@10:40:22 (Mithaldu) here's how you'd do this:
10-08-25@10:40:22 (@t0m) you're making your clients have to have an order of operation, that sucks.
10-08-25@10:40:29 (Mithaldu) you set target statement subs
10-08-25@10:40:38 (Mithaldu) and metric size
10-08-25@10:40:50 (Mithaldu) and then you let the reporter module handle how it deals with those
10-08-25@10:41:10 (@t0m) erm? I don't see how that helps.
10-08-25@10:41:15 (Mithaldu) i'm keeping the metrics intentionally as simple and generic as possible to keep the complexity on that end low
10-08-25@10:41:24 (@t0m) Either way, that was a contrived example.
10-08-25@10:41:31 (Mithaldu) it's a good one
10-08-25@10:41:35 (@t0m) I think my point is still entirely valid :)
10-08-25@10:41:58 (Mithaldu) i think your point is valid as a theory, i am just not sure if i actually want to apply this
10-08-25@10:42:01 (@t0m) You have metadata in global state, which means I can't change it for 2 different cases in my code.
10-08-25@10:42:35 (@t0m) Mithaldu: I don't see how My::Class->new->method(@args) is worse than My::Class->method(@args)
10-08-25@10:42:53 (@t0m) and it can win you a lot, all of which are things you probably don't see a use for right now :)
10-08-25@10:43:07 (@t0m) But if you don't, you _are_ painting yourself into a corner.
10-08-25@10:43:27 (@t0m) Like I said to start with - be sure, really really sure that you like that corner, and the colour of paint you used.
10-08-25@10:43:39 (Mithaldu) yeah
10-08-25@10:43:42 (Mithaldu) i am thinking :)
10-08-25@10:43:46 (Mithaldu) there's another issue though
10-08-25@10:43:57 (Mithaldu) collection and reporting are two separate steps
10-08-25@10:44:21 (Mithaldu) and i'm not storing the state of each metric in the json
10-08-25@10:44:35 (Mithaldu) so the reporter would be unaware of changes done in collection
10-08-25@10:44:40 (Mithaldu) so i guess i'd need to add that
10-08-25@10:49:48 (Mithaldu) added as a tentative todo. i am really not sure whether parametrizing metrics is a good idea or whether that should be done by introducing more generic metrics