mothervolcano / polka-folks Goto Github PK

The method is beyond the scope of the class and what it does can be easily achieved by a helper function or utility class.

Objective:

Implement the ModelConfig interface in each of the three pioneer Archetype-based classes. The goal is to accommodate specific configuration needs for each Archetype and evaluate which implementation is the most suitable.

Background:

In our codebase, we have three Archetypes, which are the first to test the system. Each archetype import and configure a variety of Models (based on the Model base class). To ensure flexibility and maintainability a common interface is introduced, ModelConfig, to define the configuration needs for each Model in the context each Archetype.

Steps

1. Interface Definition:

• Define the ModelConfig interface, specifying the necessary properties and their types. Ensure it encompasses the generic configuration needs for Models.

2.Implementation for Each Archetype-Based Class:

• In each of the three Archetypes, implement the ModelConfig interface. Tailor the interface to accommodate specific requirements for that class. This may include adding or modifying properties within the interface.

3. Evaluation and Decision:

• Evaluate the three implementations of the ModelConfig interface.
• Determine which implementation best suits the goals of the project, taking into account flexibility, maintainability, and alignment with client-class requirements.

4. Consolidation of All Archetype-Based Classes:

• Once the final ModelConfig interface is selected, adjust all Archetype-based classes to conform to this chosen interface.

Remove Plotter as a dependency of the Polka class. Plotter should not be an object of Polka but rather a module used by Polka.

Figure out some possible solutions for alternating the orientation of the Attractors on a Spinal Field.

... to be filled in.

The current implementation of the Spine class in spine.ts relies heavily on the project function to handle different Spine creation scenarios, such as creation from 2 points, 1 point and a length property, or a fully defined path. This approach has led to complexity and tight coupling with an external library (e.g., Paper.js), making the code less maintainable and adaptable.

Refactor the Spine creation process to make it more modular, maintainable, and independent of external libraries. The goal is to have a well-structured codebase that can handle different Spine creation scenarios in a clear and library-agnostic way.

Separate the several creation scenarios and define them clearly.

• Abstract and delegate Path Creation: Move the creation of the path itself away from the class, abstracting it as much as possible to reduce dependency on external libraries.

• Remove or Replace project Function: Evaluate whether the project function is needed, and if not, remove it. If needed, break it down into separate functions or classes that handle different Spine creation scenarios.

• Type Definitions: could Typescript overloads be a good approach here? Learn more about them and how to apply them.

• Implement unit testing

NOTE: starting a new branch for this might be advisable.

Replace the switch statement below with the following logic:

1. Get the list of all options in passed models array.
2. Check the requested option against that list.

switch (action.type) { case "PUNK": selectedModel = models.find((model: Model) => model.option === "PUNK") || models[0]; break; case "BAROQUE": selectedModel = models.find((model: Model) => model.option === "BAROQUE") || models[0]; break; case "NERD": selectedModel = models.find((model: Model) => model.option === "NERD") || models[0]; break; default: throw new Error(ERROR: ${action.type} is not a valid archetype); }

Remember what it was intended for and if it is actually being used anywhere.

###Current State:

The implementation of the Orientation and Polarity properties in the Attractor classes (Orbital and Spine) is currently convoluted and inconsistent. The behavior and purpose of these properties are not well-defined, leading to confusion and potential issues in future development.

In the case of Orbitals, the concept of Orientation is well-defined. Consider a circle divided by a line that passes through the points at 1/4 and 3/4 of the path defining the OrbitalField. The attractors positioned before 1/4 and after 3/4 have a positive orientation value of 1, while the others have a value of -1. The Orientation affects the orientation of the circle, meaning that circles with an orientation of -1 are mirror images of the attractors with an Orientation of 1. This system exists to facilitate and control symmetry in the construction of paths.

###Problem Statement:

• Lack of Clarity: The concepts of orientation and polarity are not consistently defined across different types of Attractors (Orbital and Spine). This inconsistency makes the code harder to understand and maintain.

-Complex Implementation: The current implementation involves a chain of methods starting with arrangeAttractors, leading to complexity in calculating the position, orientation, and polarity of the attractors.

-Design Limitations: The current design does not easily accommodate future types of Attractors, limiting the extensibility of the system.

Note: An additional layer of complexity arises from the ability to add Spine attractors to OrbitalFields and vice versa (Orbitals to SpinalFields). This feature introduces further challenges in defining and implementing the 'Orientation' and 'Polarity' properties consistently across different types of Attractors. Careful consideration and design are required to ensure that these properties function as intended in all scenarios.

Goals

• Define Clear Concepts: Establish clear and consistent definitions for 'orientation' and 'polarity' that apply to all types of Attractors.

• Simplify and Centralize Implementation: Refactor the code to centralize the calculation and assignment of orientation and polarity within the base classes that all types of attractors extend.

... so that it can accommodate future types of Attractors without significant changes to the existing code.

Separate specification data from state logic

Implement an additional pair of methods in Model that can be used to pass paths/instructions between two models.

Such methods should be available during the mounting stage.

Separate specification data from state logic

The current flow within the Archetype classes, from model configuration to generation, is overly complex and segmented. This premature segmentation has led to code duplication and could potentially constrain the project's combinatorial capabilities in the long term.

This model appears to have been messed up after the recent updates to the core engine. Unlike most other models, which remain unaffected, the points are not being plotted as expected.

The model is tightly coupled with another model, adding to the complexity of the issue and making it difficult to understand what is going on even in debug mode.

However this has a low impact on the overall project, not only this model is not a high-priority component but also seems to be an exception.

TODO:

1. Isolate the HairCrest model for analysis.
2. Search the notebooks to find the original design specifications for this element.
3. Audit recent updates to the core engine to rule out the introduction of a latent, high-impact bug. This step is precautionary, as nearly all other models have remained unaffected by the recent changes.

##Current State:

The OrbitalField class requires the position parameter to be an HyperPoint, while the Spine class accepts a different type for the position.

##Expected Behavior:

The position parameter should have a consistent type across different classes that are meant to work together. This will ensure a uniform and predictable interface.

Ideally operations like this should either be implemented downstream of the inheritance chain or delegated to specialised modules.

1. Responsibility and scope of the class/module
2. Interoperability with other classes/modules
3. Public methods, arguments and returns