(10-05-2016, 04:24 AM)sv3tli0 Wrote: (10-05-2016, 02:48 AM)Narf Wrote: You don't quite get what I'm saying - replacing is pointless. It will solve your problem, but will make others unhappy.
If I only want email, I don't want needless abstractions forced upon me.
CI\Email must remain stand-alone. The point of adapters is to act as mediators, not concrete implementations.
I understood you right the first time.
My suggestion is based on the current trends at the web apps.
In the past "Send Message to user" meant in almost 100% of the cases - send Email. But today its not the same.
Its most likely that there will be 1 small "needless abstractions" but I don't think that it will be so big deal to blacklist the idea.
I'm not blacklisting the idea, but the way you think it should be implemented.
By saying "replace", it is implied that:
- There's no longer a stand-alone email library
- You can
only send emails through the said Messenger library
- If you want to use a different email library implementation, the existing example would encourage you to write a completely new "driver"
It's not only a needless abstraction for those that don't want it, but these three conditions are also inherent limitations. All for the sake of following a current trend.
If instead you have Messenger\EmailAdapter forwarding calls to Email\Message, you can do both, with no limitations and this is in fact more abstract.
(10-05-2016, 04:24 AM)sv3tli0 Wrote: Sending an email is usually not so fast process, and some abstraction won't deal much delay..
Delays aren't the concern.
(10-05-2016, 04:24 AM)sv3tli0 Wrote: The benefit will be big for those who are sending messages not only as emails (and this group is not small and its growing) .
It will be 1-2 lines of code for sending messages to any kind of 3rd party app (Gmail as mail, FB as notification,some GSM as SMS)
I think that we should think out of the box, not only about the most regular and simplest case.
Well, that's the thing - you have a good idea, but you want to shoehorn it into the same single-simplest-case approach, just redefining what the scope of "single simplest" is.
In other words, you've had a thought while you were outside the box, but then jumped into that very box before pondering it.
