On Tuesday, 29 September 2015 at 12:26:58 UTC, Robert M. Münch wrote:
> Not that I'm to deep into the code nor D but would it be possible to write it somehow like this:
>
> Mail email = new Mail;
>
> email.headers = [
> 	"Date" Clock...,
> 	"Sender" ...
> ]
>
> This would be a much more descriptive approach, which I think makes a lot of sense for such things. And it follows the "dont repeat yourself" pattern.

The Mail class is from vibe.d

I suppose the headers members could accept `string[string]` assignment.

On Tuesday, 29 September 2015 at 12:43:19 UTC, Daniel Kozak wrote:
> It would be nice to have all of yours stuff on code.dlang.org.

I'm slowly working on it. Got some working just yesterday:
http://code.dlang.org/packages/arsd-official

but the repo doesn't let you show subpackages, argh. dub sucks, code.dlang.org sucks.

On Tuesday, 29 September 2015 at 12:43:19 UTC, Daniel Kozak wrote:
> Adam D.Ruppe píše v Út 29. 09. 2015 v 12:05 +0000:
>> If you ever need something in D, ask me first.... there's a good chance I've written it!
>> 
>> https://github.com/adamdruppe/arsd/blob/master/email.d
>> 
>> ....there's also a good chance I haven't documented it too though...
>> 
>
> Thanks, I will look at it.
>
> I only look at code.dlang.org. It would be nice to have all of yours stuff on code.dlang.org.

While I use some of adam's code, it is often the last place I look - if I remember at all. In this case I didn't, and decided to write something myself.

Which is sad, since had I remembered to look in adam's repo, I probably wouldn't have written this library; and saved myself a day or two.

You really need to get your stuff out in the open adam.

On Tuesday, 29 September 2015 at 08:17:42 UTC, Sebastiaan Koppe wrote:
> On Tuesday, 29 September 2015 at 06:18:32 UTC, Suliman wrote:
>> Does it's work with anything except localhost?
>> Could you add example of sending email with gmail?
>
> It is in the settings variable. Look at vibe.mail.SMTPClientSettings. http://vibed.org/api/vibe.mail.smtp/SMTPClientSettings
>
> In my tests I used rackspace's mail servers.
>
> ```
> auto settings = new SMTPClientSettings("secure.emailsrvr.com",587);
> settings.authType = SMTPAuthType.login;
> settings.connectionType = SMTPConnectionType.startTLS;
> settings.tlsValidationMode = TLSPeerValidationMode.requireCert;
> settings.username = "info@example.com";
> settings.password = "123456789";
> ```
>
> Replace with whatever gmail has.
>
> The only problem I had was with `settings.tlsValidationMode`. It failed with the certificates so I had to set it to `requireCert`. But I wouldn't do that.

I am asking because I had troubles with vibed http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/25447/

On Tuesday, 29 September 2015 at 13:37:18 UTC, Suliman wrote:
> I am asking because I had troubles with vibed http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/25447/

It's still vibe.d doing the smtp stuff. You might want to look into adam's code, or http://code.dlang.org/packages/smtp

On Tuesday, 29 September 2015 at 13:10:55 UTC, Adam D. Ruppe wrote:
> I'm slowly working on it. Got some working just yesterday:
> http://code.dlang.org/packages/arsd-official

Good. But why put everything in one package?

A guy on npmjs.com goes the other extreme and he actually has a package (https://github.com/sindresorhus/negative-zero/blob/master/index.js) that consists of 1 line of code.

In the description you say "or better yet, ditch dub and do things the simple, reliable way of dmd *.d" How is that more reliable?

I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually. I don't see how that is more reliable.

> but the repo doesn't let you show subpackages, argh. dub sucks, code.dlang.org sucks.

I don't understand your negative stance against dub and code.dlang.org. I agree that both require some fine-tuning. Some areas more than others. However, the idea of having a package-manager is a good idea. If only to serve as documentation on the libs you package depends on.

On Tuesday, 29 September 2015 at 14:57:13 UTC, Sebastiaan Koppe wrote:
> Good. But why put everything in one package?

dub forces me to do it that way. It isn't my preference, but reorganizing all my files and creating twenty or thirty different github repos to house them is unacceptable.

The unit of encapsulation in D is the module. If a module does two wildly different and independent things, you would break it up. Similarly, and I think this is often neglected, if two modules are intertwined and one cannot work without the other, they are really one unit and should be merged.

The merged module will present a cleaner interface and be easier to maintain since it can handle its own private implementation without worry of exposing internals for its friend module nor having something change independently of it.

(I wish D would fix that bug where public and private symbols can conflict though. So annoying and breaks this beautiful encapsulation. You might notice simpledisplay.d has a function named toInternal for example. I'd like to name it to, but then it would break code that uses std.conv.to, despite that internal function being private! Ugh!)

That forms the basis of my general policy: make modules that stand alone and do a task as completely as necessary. I only split them up when there's a technical requirement and the split lowers overall complexity.

And, of course, when possible, I like to make those dependencies optional; they aren't required unless you actually use those specific features.



Modules in D do a pretty good job at this. They can contain most their own metadata, too: write ddoc inline, you can grep it for version options (and since D doesn't allow versions to cross module boundaries, it is as simple as a grep) and import dependencies, and you can even have some control over the linker with stuff like pragma(lib), showing system dependencies.


Modules also have a one-to-one correspondence to files, making them a natural thing to download, move around, etc. Other programs know how to handle files so you can version them and such too.


D's modules work! Why does dub reject this model?

> A guy on npmjs.com goes the other extreme and he actually has a package (https://github.com/sindresorhus/negative-zero/blob/master/index.js) that consists of 1 line of code.

Disgusting. Think of all the overhead involved in that package, not just for the author, but now for everybody who use it... and everyone who uses something that uses it, and so on and so forth - right down to the end user!

There needs to be a balance struck between "don't repeat yourself" and avoiding dependencies.

It is generally considered a bad idea to do the whole system together at once. (though Docker and VMWare appliances and such do actually try to do that and have found some success in the market) Making changes to that means a lot of extra work that is easy to do wrong. (The duplication itself btw isn't a big problem to me, computers are good at doing the same thing over and over again; it is an easily automated problem, at least until something goes wrong.)

In code, we factor common functionality into functions that can be used from multiple places instead of copy/pasting the bodies everywhere.

It is similarly a bad idea to have a deep web of external dependencies. This also makes maintenance harder - where is the problem? Where do you make the change? How long will it take to get upstreamed? Do you understand what is going on anymore; will changing that dependency break some unrelated project somewhere else?

In code, we try to write our functions such that they do not use global variables. We like pure functions whenever we can. We like to use const or immutable to limit the scope of confusing changes. We like to use private to limit the function's interface.


Negative zero should be a constant (and probably a private one at that, that'd be a bizarre implementation detail to expose to an API user). Here, it is instead a public global mutable function pointer.


> In the description you say "or better yet, ditch dub and do things the simple, reliable way of dmd *.d" How is that more reliable?

It works the same way every time you do it and exposes all the options dmd has without needing wrapper json options which may or may not actually be there, or documented, or keep working the same way next time you try.

> I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually.

That means you don't have to put up with me randomly breaking your code! You don't have to wait for me to publish a bug fix. You aren't locked in to the way I did things and are free to customize it as you wish.

It is very easy to update it too, even if you do customize it (git will handle the conflicts, if any) - you can always do a git pull from me, then test and push back up to your copy (or, not even bother with the push and just keep the development dependencies private or ask your users to retrieve it themselves... it is just a file download, very easy to do).

> However, the idea of having a package-manager is a good idea. If only to serve as documentation on the libs you package depends on.

dscanner --imports *.d | sort | uniq

Always up-to-date!

Though, dscanner and dub.json both fail to get across all the nuance possible with the D module system. For example, running that on dom.d yields:

arsd.characterencodings
arsd.database
arsd.jsvar


Yet, dom.d is also standalone!

characterencodings is only needed if you call one of the character conversion functions; it is a lazy local import inside a template.

database is the same, it is only used if you actually call the fillForm function. (Which is the only reason I permit that btw, dom and database should NOT depend on one another and I might just copy/paste that function out someday).

jsvar is only used with a rare -version switch that I never finished anyway. I should probably just delete those lines.


But, how do you express the half-dependency of characterencodings in a dub.json dependencies list? Perhaps a configuration could do it.... or the character converting functions could be pulled out into a third package on which you depend to get them.... what a pain compared to just "don't call this function and you never need it but if you want it it is right there"!


Here's how I documented it in dom.d:


/**
        BTW: this file optionally depends on arsd.characterencodings, to help it correctly read files from the internet. You should be able to get characterencodings.d from the same place you got this file.

        If you want it to stand alone, just always use the `parseUtf8` function
*/

That explains it better than dub.json has the capability to.




I'm not completely against the idea of a package manager or even against dub itself. I just see very little value add from it and quite a bit of complication and associated questions about it on the support forums.

On Tuesday, 29 September 2015 at 12:26:58 UTC, Robert M. Münch wrote:
> On 2015-09-29 03:53:44 +0000, Sebastiaan Koppe said:
>

>
> Not that I'm to deep into the code nor D but would it be possible to write it somehow like this:
>
> Mail email = new Mail;
>
> email.headers = [
> 	"Date" Clock...,
> 	"Sender" ...
> ]
>
> This would be a much more descriptive approach, which I think makes a lot of sense for such things. And it follows the "dont repeat yourself" pattern.


Nice observation

On Tuesday, 29 September 2015 at 13:10:55 UTC, Adam D. Ruppe wrote:
> On Tuesday, 29 September 2015 at 12:43:19 UTC, Daniel Kozak wrote:
>> It would be nice to have all of yours stuff on code.dlang.org.
>
> I'm slowly working on it. Got some working just yesterday:
> http://code.dlang.org/packages/arsd-official
>
> but the repo doesn't let you show subpackages, argh. dub sucks, code.dlang.org sucks.


+1

When am I going to see your dub?

On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote:
> On Tuesday, 29 September 2015 at 14:57:13 UTC, Sebastiaan Koppe wrote:
>> [...]
>
> dub forces me to do it that way. It isn't my preference, but reorganizing all my files and creating twenty or thirty different github repos to house them is unacceptable.
>
> [...]

That is why npm sucks, but very helpful.