Mail::Field (and it's sub-classes) define several methods which return new objects. These can all be categorized as constructor.
Take a LIST of Mail::Field
objects (which should all be of the same
sub-class) and create a new object in that same class.
Takes as arguments the tag name, a Mail::Head
object
and optionally an index.
If the index argument is given then extract
will retrieve the given tag
from the Mail::Head
object and create a new Mail::Field
based object.
undef will be returned in the field does not exist.
If the index argument is not given the the result depends on the context
in which extract
is called. If called in a scalar context the result
will be as if extract
was called with an index value of zero. If called
in an array context then all tags will be retrieved and a list of
Mail::Field
objects will be returned.
Create an object in the class which defines the field specified by the TAG argument.
Mail::Field objects use autoloading to compile new functionality. Apparently, the mehod called is not implemented for the specific class of the field object.
This constructor is used internally with preprocessed field information. When called on an existing object, its original content will get replaced.
Parse a field line.
Change the settings (the content, but then smart) of this field.
Returns the field as a string.
Without arguments, the field is returned as stringify() does. Otherwise, the STRING is parsed with parse() to replace the object's content.
It is more clear to call either stringify() or parse() directly, because this method does not add additional processing.