Using objects as keys

[NotionCommotion]

I created the following which incorrectly uses objects as keys in an array.  How should it really be done?  I first considered SplObjectStorage, but https://medium.com/@rtheunissen/efficient-data-structures-for-php-7-9dda7af674cd bashes SplObjectStorage, and recommends new PHP7 options.  I tried \ds\map, but don't have it currently installed.  I can install it, but before doing so want to make sure this is the right approach and whether I should be using Vector, Deque, Set, Stack, Queue, PriorityQueue, or Pair instead.

<?php
class Subobj{}
class MainObj
{
    private $subobj, $fnc;
    public function __construct(Subobj $subobj, $fnc){
        $this->subobj=$subobj;
        $this->fnc=$fnc;
    }
    public function getSubObj(){
        return $this->subobj;
    }
    public function getFnc(){
        return $this->fnc;
    }
}

class Collection
{
    private $stack=[];
    public function addObj(MainObj $mainObj){
        $subobj=$mainObj->getSubObj();
        $fnc=$mainObj->getFnc();
        if(isset($this->stack[$subobj])) {
            $this->stack[$subobj]=[$fnc];
        }
        elseif(!in_array($fnc, $this->stack[$subobj])) {
            //If easier, I can add duplicates and later remove them when I iterate over $this->stack
            $this->stack[$subobj][]=$fnc;
        }
    }
}

$subobj1=new \Subobj();
$subobj2=new \Subobj();

$collection=new Collection();

$collection->addObj(new MainObj($subobj1,'mean'));
$collection->addObj(new MainObj($subobj2,'mean'));
$collection->addObj(new MainObj($subobj1,'max'));
$collection->addObj(new MainObj($subobj1,'mean'));
$collection->addObj(new MainObj($subobj1,'min'));

//Desired outcome:
$collection->stack=[$subobj1=>['mean','max','min'], $subobj2=>['mean']];

// Or if easier, I can add duplicates and later remove them when I iterate over $this->stack
$collection->stack=[$subobj1=>['mean','max','mean','min'], $subobj2=>['mean']];

 

[requinix]

It looks like the "bashing" over SplObjectStorage is because it's not as efficient as Ds\Set. Did I miss something? Because comparing the two for performance is stupid as they do two different things.

If you want an object as an "array" key then use SplObjectStorage.

[NotionCommotion]

1 hour ago, requinix said:

It looks like the "bashing" over SplObjectStorage is because it's not as efficient as Ds\Set. Did I miss something? Because comparing the two for performance is stupid as they do two different things.

If you want an object as an "array" key then use SplObjectStorage.

My concern wasn't efficiency but that the SplObjectStorage isn't being maintained.

Doesn't map do the same thing as SplObjectStorage?  http://php.net/manual/en/class.ds-map.php

[requinix]

Yes, it looks like they serve equivalent purposes.

But SplObjectStorage isn't being maintained? Who said that? SPL is part of the core which means it will be maintained by the core devs. There might not be active development on it, but it is maintained.

[NotionCommotion]

27 minutes ago, requinix said:

Yes, it looks like they serve equivalent purposes.

But SplObjectStorage isn't being maintained? Who said that? SPL is part of the core which means it will be maintained by the core devs. There might not be active development on it, but it is maintained.

The original link I referenced.  Not saying they are right, only what I read.

Quote

 

“What about the SPL data structures?”
Unfortunately they are terrible. They did offer some benefits prior to PHP 7, but have since been neglected to the point of having no practical value.

“Why can’t we just fix and improve them?”
We could, but I believe their design and implementation is so poor that it would be better to replace them with something brand new.

“SPL data structures are horribly designed.” — Anthony Ferrara

 

 

[requinix]

Hmm. I'd put more stock into those statements if there were concrete reasons given too.

Ds\Map is part of an extension that has to be installed. SplObjectStorage is built-in. Consider the pros and cons of both, and beyond that it's not going to matter much.