Pool data structure

[nehzatali]

Hi @carrotIndustries,

First off thank you for making Horizon open source!

I was interested in a post implementation analysis of Horizon's data structure used in Pool – particularly the Entity, Unit and Symbol abstraction.

Wondering if you would make the same choices again and would be great if you could please elaborate the pros and cons of the decision given the hindsight.

Many thanks in advance!
Ali,

[tkornack]

The advantages are clearly stated in the documentation, and you'll likely come to appreciate the design if you actually use Horizon.

Your question seems pointed at some perceived issue or disadvantage that isn't articulated. Maybe you could elaborate.

[nehzatali]

Thanks for responding @tkornack!

Not at all. I just watched the FOSDEM 2018 presentation and wanted to see if there had been learnings since then. The approach is very different to how other EDA software do it and hearing Lukas' and (for that matter the community's) latests opinion on the matter would definitely be beneficial and educational.

[carrotIndustries]

I think the pool structure in general has held up pretty well. Some things that I should have put some more thought into:

• Angles are stored with 65536 = 360°, making it impossible to exactly represent 30°
• In some places code seems to be inconsistent about the order of transformations, in particular if mirror should come before or after rotate
• Text placement is a huge mess, but works sufficiently well after several tweaks
• Code-style wise it'd have been better to consistently name all members m_