Consider deprecating the options arrays about message HOT 6 CLOSED

One option I thought of for the full text would be to add a __toString() method to the message entity, and leave getText() to return the array of outputs.

from message.

Can you give an example here , I'm not sure I follow.

The toString is a nice idea :)

from message.

I could find very few uses of the default getText() behavior in tests or in dependent contrib (message_notify). Rather, most actual usage passes in the ['text' => TRUE] setting.

The idea here is if folks still need the string output, then the __toString() method should suffice, and code can rely on getText() always returning an array.

I also realize that we can remove the language parameter from getText by adding a setLanguage method to the interface. That would allow __toString() to work with languages.

from message.

Rather, most actual usage passes in the ['text' => TRUE] setting.

Indeed, as far as I remember, this ['text' => TRUE] is needed in D7 to indicate if we want to sanitzie on not the text.

my (slight) problem with the change, is that getText() now returns an array, which is a (slight) WTF given it's name :)

There are several places where current methods return either a string or an array based on values in an options array.

I'm not sure about this?

from message.

By several, I think I just meant the two getText() methods on the Message and MessageType entities.

from message.

I've continued this work to add setLanguage(), so the __toString() method will properly work for all languages. I've also included some token fixes here as the code was too close to the other refactoring for a separate PR.

See #60

from message.