{"id":16086951,"url":"https://github.com/olekscode/classblueprintexperiment","last_synced_at":"2026-01-18T19:06:46.026Z","repository":{"id":88081301,"uuid":"496006334","full_name":"olekscode/ClassBlueprintExperiment","owner":"olekscode","description":null,"archived":false,"fork":false,"pushed_at":"2022-05-24T22:40:59.000Z","size":354,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-02-11T11:41:48.824Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/olekscode.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-05-24T22:28:07.000Z","updated_at":"2022-05-24T22:45:44.000Z","dependencies_parsed_at":"2023-06-26T00:14:14.593Z","dependency_job_id":null,"html_url":"https://github.com/olekscode/ClassBlueprintExperiment","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/olekscode%2FClassBlueprintExperiment","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/olekscode%2FClassBlueprintExperiment/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/olekscode%2FClassBlueprintExperiment/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/olekscode%2FClassBlueprintExperiment/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/olekscode","download_url":"https://codeload.github.com/olekscode/ClassBlueprintExperiment/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247353676,"owners_count":20925325,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-09T13:26:22.939Z","updated_at":"2026-01-18T19:06:45.992Z","avatar_url":"https://github.com/olekscode.png","language":null,"readme":"# Observations on PolyMath\n\n## How to Install\n\n```st\nMetacello new\n    repository: 'github://PolyMathOrg/PolyMath';\n    baseline: 'PolyMath';\n    load.\n```\n\n## PMVector\n\n![](img/PMVector.png)\n\n- Most methods are tested, except the following ones:\n\t- **External:** adaptToComplex:andSend:, adaptToQuaternion:andSend:, accumulateNegated:, productWithMatrix:, and scaleBy:\n\t- **Internal:** checkDimensionalCompatibility: and productWithVector:\n\t- **Class side:** randomSize:maxNumber:\n\n- False positive: PMVector\u003e\u003echeckDimensionalCompatibility: is grey, so it should be a constant method. But it is not. It is a boolean method that returns true in its last statement.\n- False positive: None of the dead methods in this class are actually dead. They are just part of API, not used by PolyMath but meant to be used by its clients.\n\n## PMVectorTest\n\n![](img/PMVectorTest.png)\n\n- As expected, all methods are tests\n- False positive (maybe): some methods are marked as polymorphic, but they are just methods wit common names. E.g., testAsArray. I am not sure if test methods can be polymorphic... Perhaps, this is only because of the naming convention that we use in Pharo: asArray is polymorphic -- it is a common name and every class that implements it can be converted to an array - that's the polymorphic behavior. But testAsArray is not supposed to be called, it's only named this way because it tests the asArray method. If I rename it to test1, nothing will change.\n\n## PMMatrix\n\n![](img/PMMatrix.png)\n\n- There are two large methods qrFactorization and qrFactorizationWithPivoting which should not even be in PMMatrix. I would move them to a separate package. And then refactor them to make them smaller\n- choleskyDecomposition is another big method that should be moved to a separate package and refactored\n- PMMatrix\u003e\u003esplit has a red border, so I guess this means that it has high cyclomatic complexity. But it has no if statements. Only Array with: with with: and several collect: loops.\n- adaptToNumber:andSend: is not a dead method. It is a hook that is widely used by Pharo collections. This is another example of false positives for dead methods: abstract hooks.\n- example method is too big and shows too many things at a time. Perhaps, we could split it into several example methods.\n- Many methods are not tested. Some of those tests are important. For example eigen (terrible name), join:, rowsCollect:, columnsCollect:\n\n## PMMatrixTest\n\n![](img/PMMatrixTest.png)\n\n- All good, many tests\n\n## BaselineOfPolyMath\n\n![](img/BaselineOfPolyMath.png)\n\n- baseline is one huuuge method. Perhaps, we should split it into multiple smaller ones.\n\n## PMMultivariateNormalDistribution\n\n![](img/PMMultivariateNormalDistribution.png)\n\n- Almost all methods are marked as megamorphic. Why? Because there are many distribution classes and they all have the same API. Take a look at kurtosis for example. It is implemented by all distribution classes. But I am not sure if this is enough to call a method megamorphic. This is a just a typical case of a polymorphic method. A megamorphic method could be printOn: for example or asString -- methods that are implemented by hundreds of different classes from different projects that don't even share a common superclass (except Object).\n- Everything is tested except the initialize method (of course it is... because I wrote this class :D )\n\n## PMMultivariateNormalDistributionTest\n\n![](img/PMMultivariateNormalDistributionTest.png)\n\n- All good here: four test methods, one setUp, three attributes\n- setUp is megamorphic... meh... maybe... to me it just seems like a normal inheritance with a polymorphic method\n\n## PMQuaternion\n\n![](img/PMQuaternion.png)\n\n- this is some big class that I don't understand\n- it has some bad method names like j and k\n- and bad attribute names: qi, qj, qk, qr\n- I am not sure if guard closes should be considered when calculating cyclomatic complexity. I mean yes, they affect the number of branches but this is not something very interesting on a visualization. Because many methods just have 2-3 ifTrue: expressions at the beginning to check the conditions and raise exception. Does it make the method complex? Should the complexity be reduced? No, it's a good practice.","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Folekscode%2Fclassblueprintexperiment","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Folekscode%2Fclassblueprintexperiment","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Folekscode%2Fclassblueprintexperiment/lists"}