Skip to content

Conversation

TimWolla
Copy link
Member

See individual commits.

…lers()`

There is no one time fits all solution to initialization of the object
handlers. A follow-up commit will use distinct `create_object` handlers for
each parser class.

Explicitly spelling out the handlers is a well-established pattern in php-src
and I don't see a reason to diverge from that with an intransparent helper
method.
…pon creation

This makes the objects much safer to use, since the `.parser` will always be
available and `.uri` will reliably be `NULL` instead of garbage.
The parser for a given object is already known from the object itself and
particularly must never change. Reassigning the value in `uri_unserialize()` is
just unsafe, especially since the existing `->uri` is freed with the destructor
of the reassigned parser.

Just rely on the `->parser` field being set to the correct value.
Similarly to the previous change to `uri_unserialize()`, the `->parser()` must
always match the object for the freeing to be safe.

Given that we expect to successfully parse URIs, we can eagerly initialize the
resulting URI object when using the `::parse()` methods and destruct it again
when parsing fails and `null` is returned instead. The destructor has
previously been made safe for this case by initializing the `->uri` field to
`NULL`.

The `base_url_object` must also match the object that is currently being
constructed. Verify this using assertions matching the `->ce` and the
`->parser`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants