Would implementing a default cast("string") implementation for objects that lack one be a good idea, if they respond to _sprintf("%s")? It is somewhat magical. The same could theoretically apply to int/%d, but I have a feeling it might be more questionable. Even more, float/%f. Any thoughts?
Lessons learned from automatic _sprintf decoration have been largely positive, in my experience. (That might not imply anything about this proposal, though. It would, for instance, rarely throw errors about a missing cast implementation, in concert with the _sprintf decorator.)
Would implementing a default cast("string") implementation for objects that lack one be a good idea, if they respond to _sprintf("%s")? It is somewhat magical. The same could theoretically apply to int/%d, but I have a feeling it might be more questionable. Even more, float/%f. Any thoughts?
I cant figure out why it would be a good idea. Please elaborate.
I cant figure out why it would be a good idea. Please elaborate.
Mere laziness and DRY (don't repeat yourself). If I have a _sprintf that implements "give a string representation of" I find it sort of superfluous having to repeat the same code in a cast method too. But, as noted, for the (assumed existing) cases where objects not meant to be castable would silently be casted via _sprintf, it might be a horrible idea, losing the error-out-and-die feature.
Thought of that way, a non-existant _sprintf embracing and extending an existant cast method, is probably a lot better, safety-wise, than the other way around, as I thought it of first. In practice, though, I suspect that a lack of _sprintf but not cast, almost never happens.
I think I convinced myself the same. (Still wanted to probe whether it made any sense to others though.)
It did spur the more interesting side of the thread about value casts, though, which I had not anticipated.
pike-devel@lists.lysator.liu.se