On Wed, 21 Dec 2022 at 09:30, Cameron Simpson <cs@cskk.id.au> wrote:
On 19Dec2022 22:45, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano <steve@pearwood.info> wrote:
But this much (say with a better validator) gets you static type checking, syntax highlighting, and inherent documentation of intent.
Any half-way decent static type-checker will immediately fail as soon as you call a method on this html string, because it will know that the method returns a vanilla string, not a html string.
But what does it even mean to uppercase an HTML string? Unless you define that operation specifically, the most logical meaning is "convert it into a plain string, and uppercase that".
Yes, this was my thought. I've got a few subclasses of builtin types. They are not painless.
For HTML "uppercase" is a kind of ok notion because the tags are case insensitive.
Tag names are, but their attributes might not be, so even that might not be safe.
Notthe case with, say, XML - my personal nagging example is from KML (Google map markup dialect) where IIRC a "ScreenOverlay" and a "screenoverlay" both existing with different semantics. Ugh.
Ugh indeed. Why? Why? Why?
So indeed, I'd probably _want_ .upper to return a plain string and have special methods to do more targetted things as appropriate.
Agreed. ChrisA