There are three ways in which the «BCC:» field is used.
In the first case, when a message containing a «BCC:» field is prepared to be sent, the «BCC:» line is removed even though all of the recipients (including those specified in the «BCC:» field) are sent a copy of the message.
In the second case, recipients specified in the «To:» and «CC:» lines each are sent a copy of the message with the «BCC:» line removed as above, but the recipients on the «BCC:» line get a separate copy of the message containing a «BCC:» line. (When there are multiple recipient addresses in the «BCC:» field, some implementations actually send a separate copy of the message to each recipient with a «BCC:» containing only the address of that particular recipient.)
Finally, since a «BCC:» field may contain no addresses, a «BCC:» field can be sent without any addresses indicating to the recipients that blind copies were sent to someone.
Which method to use with Bcc: fields is implementation dependent and may depend on both one's mail user agent (e.g. Outlook, Thunderbird) and mail submission agent (usually provided by one's ISP).
Вы кстати проверьтесь — он резидентный. Нас 2 раза накрывало после как-бы успешной вычистки.
А вообще после этого случая завязал с сохранением паролей вообще. После 10 раза ввода можно запомнить любую абракадбру, а при ежедневном использовании так вообще сниться будет %-)
У них могут быть сложности с выводом денег, если нет банковского счета в «нормальной» стране — они шлют чек, который надо обналичить, что не все могут. Со счетом в нормальном банке проблем с выводом нет. То, что они находятся в США, может быть как плюсом, так и минусом, зависит от Ваших тонкостей. У них достаточно строго с возвратами — могут вернуть платеж без разбирательств по первому требованию клиента. Опять же может быть как минусом, так и приемлемым фактором.
Понятно, что у оптимизации есть предел и цена. Скриптик на 10 строк мутить в ООП вообще нет смысла. Если проект серьезный и сложный, то архитектура — самое главное. Остальное — дело кодеров.
Ну, одно из преимуществ такого подхода — наличие контроля над этими переменными, теперь членами класса.
А какую проблему это не решает? Комка связей? Здесь, мне кажется, нужно именно убирать переменные, прямо не относящиеся к этому (корневому) классу туда, где им место. Ну, например, нужно ввести константу — размер буфера для чтения из сокета. Она как-бы глобальная и «удобно» настраивать все «на самом верху», но по сути константа относится непосредственно к сокету и должна принадлежать именно классу сокета (static естественно). В этом моя основная мысль организации архитектуры классов. Таким образом все, казалось бы глобальные, переменные/константы/настройки разбредутся по своим классам и в корневом останется только то, что относится к «сайту».
There are three ways in which the «BCC:» field is used.
In the first case, when a message containing a «BCC:» field is prepared to be sent, the «BCC:» line is removed even though all of the recipients (including those specified in the «BCC:» field) are sent a copy of the message.
In the second case, recipients specified in the «To:» and «CC:» lines each are sent a copy of the message with the «BCC:» line removed as above, but the recipients on the «BCC:» line get a separate copy of the message containing a «BCC:» line. (When there are multiple recipient addresses in the «BCC:» field, some implementations actually send a separate copy of the message to each recipient with a «BCC:» containing only the address of that particular recipient.)
Finally, since a «BCC:» field may contain no addresses, a «BCC:» field can be sent without any addresses indicating to the recipients that blind copies were sent to someone.
Which method to use with Bcc: fields is implementation dependent and may depend on both one's mail user agent (e.g. Outlook, Thunderbird) and mail submission agent (usually provided by one's ISP).