For example, MailBox class has a non-static method FindFirstMailBox() that takes no parameters and returns an int. I don't know of a single OO paradigm that would have a "find" method have a signature and encapsulation like this. It seems that the way to find an existing mailbox is to:
make a new mailbox (?!)
set its postoffice property to whatever existing postoffice you're trying to search
set its mailname to whatever you expect the mail name to be
call get, or find, or something on the new mailbox, to populate the details of any possibly matching existing mailboxes
Then how do we edit a property? Can I just set it directly? How do I save it? Does it save automatically and instantly? Do I have to call the EditMailbox(...) method that takes a boatload of non-optional arguments for stuff I DON'T want to edit? And what if I only want to change one of the settings of a mailbox.. ? Do I have to pass in the same value as is existing for all the other arguments? as in:
Code: Select all
theMailbox.EditMailbox(theMailbox.PostOfficeName, theMailbox.theMailboxName, theMailbox.SomeOtherExistingProperty, theMailbox.SomeOtherOtherExistingProperty, theMailbox.SomeOtherOtherOtherExistingProperty, "the new property I actually want to change", theMailbox.SomeOtherOtherOtherOtherOtherExistingProperty...)That's mental. Who would hire a coder who'd write like that?
All these questions that the documentation simply fails to answer
If a PostOffice is a collection of mailboxes, it should be the one to find, add and delete mailboxes. You don't search a collection of objects by instantiating a new instance of that object, associating it with the collection, then telling it to find the rest of itself!
-
Incidentally, your API documentation doesn't say which DLL to load to get access to these functions - in the "store" section it tells us the relevant DLL is "The .NET Assembly hosting these functions is called MEStore.DLL. The namespace of the Store class is MailEnable.Store. " but the equivalent of this helpful and critical nugget of information is missing from the chapter that talks about the MailEnable.Administration namespace
Attempting to interact with MailEnable programmatically has been one of the biggest sources of frustration I've encountered in recent times. Would you please at least fix your documentation, if not go the whole hog and fix up the API so it's logical? Right now it's preferable to use a textfile database driver to write to the TAB files directly than use the API, and that should never be the case..
