Recipient management

[sagikazarmark]

Currently the Recipients are handled by ONE object. and can be identified by calling getType. Instead of this, one object/recipient type should be used (or at least considered), like this:

namespace Fuel\Email\Recipient;

class To extends Recipient { }

[sagikazarmark]

Should they be objects at all?

[WanWizard]

For me, don't create objects for the sake of it, a recipient is just a name and an email address. If they have to be objects, stdClass would do fine.

[sagikazarmark]

There are two main reasons I created an object:

• There is a __tostring method which creates the string form of the address. It seemed to be better here.
• This way the type of recipient (to, cc, bcc) is stored in the object, so there is no need to manage different lists, recipients are stored in one list.

I am still thinking about it: as you said, it is only an email address and a name.

[WanWizard]

The "string" form is a rendering of the email address, which technically depends on the selected transport. If you would use X.400 instead of SMTP, the address whould have a completely different form. So rendering should be done by the transport layer.

It is more important to make sure all info is present (in either an array, a stdClass or a custom object) to allow the transport layer to generate the correct address syntax. So you have fullname, address, recipient type, address type, and maybe other properties that are required or optional.

[sagikazarmark]

I am not sure if it is against a custom object solution or not. You are saying other properties, IMO it is easier to manage it with an object. The reason why I rarely use a stdClass is that it is hard to make sure it implements the required things (methods, properties).

I got it: should be generated by transport layer, I agree in that.

[sagikazarmark]

Changed it to return email when casted to string, any other generation/format process is moved to transport.

[WanWizard]

Thinking about this a bit more. If types are generic (i.e. an SMTP email address looks like "this", and an X.400 address looks like "that"), in other words, if these are standards, then you could encapsulate it in a custom object, or even have the object support both (which could be done through interfaces).

Then the class using recipients can just say: give me the address according to the X400 specs. Or the SMTP RFC. And the class should not need to know how to render, and what properties to use for that.

[sagikazarmark]

Sounds good.

The only reason against this solution is that there is an option for encoding headers, which again belongs to the transport layer. Encoding the whole formatted string is not an option, only the name, etc should be encoded, the email address not.