Apologies, first time, still learning and have no historical context - timing
is what it is.
Proposal type: Concept
Implementer: Unknown, fallback to me after slow learning
Presumed simple implementation as the pattern should already be in place:
Cast of (string) -> __toString() - already implemented
Cast of (bool) -> __toBool()
Cast of (int) -> __toInt()
Cast of (object) -> __toObject()
…and so on.
Alternative implementation using an interface:
\CastableTo{type}
Extreme implementation:
Make both of the previous available.
Known unknowns:
- Level of interest in something like this in the PHP community outside of one
upvote on a Stackoverflow question I submitted:
https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values
<https://stackoverflow.com/questions/62747837/php-7-tostring-or-other-interface-for-boolean-values>
- Whether this conversation or proposal has already occurred.
- The historical conversation leading to the creation of the __toString()
method (and stopping there).
- The current conversation around using magic methods in general and
specifically when defining a cast response.
- Enough details on PHP internal development to implement myself (this is the
first time in 20 years I felt I couldn’t comfortably accomplish what I wanted
to, thanks for that).
- What potential collisions could occur if someone (me) wanted to implement all
possibilities in a single class.
- Right now __toBool() would be of the most personal benefit - if proposal is
converted to an RFC, would it be better (faster/smoother) to do one RFC for all
the cast possibilities - or to have an RFC for each cast separately?
Thank you for the consideration, information, and feedback.
Cheers,
Josh
ps. Also, apologies again for walking into a new space on a mission, not my
normal approach.
pps. The primary project inspiring the proposal:
https://github.com/8fold/php-shoop <https://github.com/8fold/php-shoop>
