Base interfaces for bundle implementations

Hmm, I wonder if we can pull up the getItems() method to the base interface and let it return the current state in case of dynamic bundles. I think, if you look at a dynamic bundle to an fixed point in time, it should look like a static one. In the beginning return the defaults, inbetween selected ones and after the order was placed, the items are fixed anyway.

If I understand that correctly, the getPricingOverride() is a Flag. Would hasPriceOverride() than be a better name?

Me thinking loud: If we make the bundleItems purchasables entities, we get simpler bundles and more flexibel bundle items, right? But I'm not sure about the resolver thingies. Totally unfinished unfinished thought, but wanted to share this. Not sure I have time today evening for irc

Core Commerce Bundle Item interface(s):

BundleItemInterface extends PurchasableItemInterface {
  getEntity()
  getQuantity()
  getUnitPrice()
}

Core Commerce Bundle item entity:

<?php

Drupal\commerce_product_bundle\Entity;

class BundleItem implements BundleItemInterface {
  protected $entity;

  protected $qty;

  protected $unitPrice;

  __construct(PurchasableEntityInterface $entity, int $qty, Price $unit_price = null) {
    $this->entity = $entity;
    $this->qty = $qty;
    $this->unitPrice = $unit_price ?? $this->entity->getPrice();
  }

  getEntity()
  getQuantity()
  getUnitPrice()

  getPrice(){
    return $this->unit_price->multiply($this->getQuantity())
  }
  
  getStores(){
    return $this->entity->getStores()
  }

  getOrderItemTypeId(){
    return $this->entity->getOrderItemTypeId();
  }

  getOrderItemTitle(){
    return $this->entity->getOrderItemTitle();
  }

 
}

We can create BundleItems with no overriden price, if we need to or override the price in the bundle item. Our bundle Items could contain any sort of additional logic, like overriding the order item title.

The static bundle implemenation than seems somewhat simpler.

Example implementation (the "static bundle with sku and pricing+shipping override" use case):
Shouldn't the bundle implement PurchasableEntityInterface. Should we let the BaseBundle extend that interface?

<?php

Drupal\commerce_product_bundle_static\Entity\StaticBundle

class StaticProductVariationBundle implements StaticBundleInterface, BundleWithSKUInterface, ShippingOverrideInterface {

  /** @var \Drupal\commerce_product_bundle\Entity\BundleItemInterface[] $items */
  protected $items = [];
  
  /** @var array $configuration */
  protected $configuration;

  /** @var \Drupal\commerce\AvailabilityManagerInterface $availabilityManager */
  protected $availabilityManager;

  /** @var \Drupal\commerce_price\Price $basePrice */
  protected $basePrice;

  __construct($items, $availability_manager, $configuration) {
    $this->items = []
    $this->availabilityManager = $availability_manager;
    $this->configuration = $configuration;
    $this->basePrice = new Price($configuration['base_price'])
  }

  public function getShippingOverride() {
    return $this->configuration['override_shipping'];
  }

  public function getStores();
  public function getOrderItemTypeId();
  public function getOrderItemTitle();

  public function getPrice() {

      if(isset($this->basePrice)){
        return $this->getBase;
      }

      // Compute sum of all purchasable entities (bundle items) resolved prices
      $price = new \Price();
      foreach ($items as $item) {
        $item_price = $item->getPrice();
        $price->add($item_price);
      }
      return $price;
  }

}

If we do it this way, we could even reference a static bundle as an bundle item, right? Not sure though if that is of any help

Do we really need a baseprice in the sense of: Set a bundle baseprice and add the item prices? I've come across cases were someone asked for a fixed bundle price setting without worrying about the bundle item prices. Maybe there are use case where we never need to know about the bundle items prices. So if there is a baseprice, no need to compute anything. But if we need it for something, I'm totally fine with it. That is not the most important detail. The question is - should the bundle item return its price or should we really grab the referenced entity in the bundle?

I think that some taxresolver simple could grab the items (bundle->getItems()) - looping over them, get the referenced entity if it need to, but get the price from the bundle item, as that is the base for calculating the taxes on a per item base. If the tax calculation is based on the bundle total - its easy anyway.

We have some interfaces in code that differ somewhat. Instead of updating the fat issue here, lets discuss proposed changes in separat issues.