fixed Sphere._vertices used before populated

[chenkasirer]

Small fix in Sphere of issue causing Sphere.edges and Sphere.faces to fail if calls before first call to Sphere.vertices.

What type of change is this?

• Bug fix in a backwards-compatible manner.
• New feature in a backwards-compatible manner.
• Breaking change: bug fix or new feature that involve incompatible API changes.
• Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
• I ran all tests on my computer and it's all green (i.e. invoke test).
• I ran lint on my computer and there are no errors (i.e. invoke lint).
• I added new functions/classes and made them available on a second-level import, e.g. compas.datastructures.Mesh.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.29%. Comparing base (fb5bc8e) to head (1a3d641).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1407      +/-   ##
==========================================
+ Coverage   60.83%   61.29%   +0.45%     
==========================================
  Files         207      207              
  Lines       22270    22270              
==========================================
+ Hits        13549    13651     +102     
+ Misses       8721     8619     -102     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tomvanmele]

would be even better to relate these assertions to numbers derived from the discretisation params (u, v)

[tomvanmele]

this is happening because i (wrongly) imagined/assumed that faces or edges would be accessed after vertices, and i wanted to avoid recomputing the vertices over and over again, if not necessary.

intention was good, implementation bad :)

would be nice if we can find another way to handle this...

[chenkasirer]

Well I mean edges and faces are cached so the the compute methods should only be called once.. I assumed the vertices are not cached for the case resolution is changed, but since edges and faces are perhaps we should cache vertices as well?

We could maybe use a reset computed kind of decorator to invalidate caches..

[tomvanmele]

would be nice but i don't see an easy solution. we could monitor the shape's own properties but modifications can be made at a deeper level and then things become tricky. for example

cylinder = Cylinder(radius=1.0, height=1.0)

# all of the following would have to trigger a cache reset
cylinder.radius = ...
cylinder.height = ...
cylinder.resolution_u = ...
cylinder.resolution_v = ...
cylinder.frame = ...
cylinder.frame.point = ...
cylinder.frame.point.x = ...
...

not sure how we can elegantly track this.
the direct property changes are easy, but the nested/deeper ones are not so obvious to me.

[tomvanmele]

anyway perhaps that is not the point of this PR...

[tomvanmele]

LGTM

[chenkasirer]

not sure how we can elegantly track this. the direct property changes are easy, but the nested/deeper ones are not so obvious to me.

I see, indeed tricky.
honestly I don't think we need to guarantee consistency if someone manipulates deep attributes.
I guess the only thing we can do about that is make these shapes immutable by e.g. returning copies from getters but not sure if we want to do that.