> 1. free functions only
> 2. class-interface only
> 3. combined approach, in same module
> 4. combined approach, in (for example) std.c.loader.d (for the free
functions)
> and std.loader.d (for the class)
> 5. Some other combined approach that I've not anticipated. Please suggest

Without seeing the actual declarations I vote for 1. If there is an obvious
"object" mental model then go with 2 - and assuming this module is for
loading DLLs and such I don't think an object model works very well. For
instance, if I hold onto a reference to a DLL object does it keep the dll
loaded in memory?
More is less:
http://www.amazon.com/exec/obidos/tg/detail/-/0060005688/102-3661341-2044918?v=glance

Matthew wrote:
>  The options as I see it are:
> 
> 1. free functions only
> 2. class-interface only
> 3. combined approach, in same module
> 4. combined approach, in (for example) std.c.loader.d (for the free functions)
> and std.loader.d (for the class)
> 5. Some other combined approach that I've not anticipated. Please suggest
> 
> Please let me know your thoughts

There's something to be said for unity, I think.  I say 1 or 2, depending on how OOPy the library wants to be.

If every API had two complete implementations, Phobos would quickly snowball into some freaky monstrosity reminiscent of Perl. :)

That being said, I don't think the world would come crashing down if both were there, provided that the semantics of one was clearly defined in terms of the other. (ie two interfaces for one API)

 -- andy

I'm for number 4 !

> 4. combined approach, in (for example) std.c.loader.d (for the free functions)
> and std.loader.d (for the class)

Matthew schrieb:
> 1. free functions only
> 2. class-interface only
> 3. combined approach, in same module
> 4. combined approach, in (for example) std.c.loader.d (for the free functions)
> and std.loader.d (for the class)
> 5. Some other combined approach that I've not anticipated. Please suggest

For this library, probably no. 1, else probably no. 2. There should be *one* obvious way to accomplish a task.

-eye

Matthew wrote:

>  The options as I see it are:
> 
> 1. free functions only
> 2. class-interface only
> 3. combined approach, in same module
> 4. combined approach, in (for example) std.c.loader.d (for the free functions)
> and std.loader.d (for the class)
> 5. Some other combined approach that I've not anticipated. Please suggest

My vote goes for #1. I'll happily use #2 without complaints though, if that's the way things fall. But the combined approach is wrong, IMO - adds uneeded clutter to Phobos. My feeling is that by using free functions, those who really must have a class can roll their own to wrap the free functions, while those who don't can just get on with it.

In article <ki1h4w8lihf7.7epxl2sd0ogo.dlg@40tude.net>, Derek says...
>
>
><soapbox>

You're right.
and
Seems nobody cares.
Probably is not as important as I thought.

Ant

Ant wrote:

> What Synesis decides to do with that product is irrelevant for the
> fact the our work might be beeing donated to Synesis.

Ant, I'm sorry, but why do yuo really care that much?  Do you feel that your suggestions in this area are worth - what, $50, $100 dollars?  So you're donating them to Synesis.  Pah... this is a problem because?

It's not like anyone's going to claim your suggestions were not written by you.  It's not like anyone's going to sell your suggestions.  It's not even like anyone is going to horde them.

If you don't want to offer your opinions or suggestions, hey - that's your call.  But blaming it on a license seems a bit wishy washy, because really what does it matter who owns your comment?

If it were even that my comment would suddenly be owned by Synesis, I would still comment.  If I thought I could give a comment to Microsoft that would improve things in a way, even if they would own my comment... I'd do it.  Who cares who owns it?  I mean, I'm a capitalist too, and I can and have sold just my opinion before, but this is really a bit much, isn't it?

-[Unknown]

On Fri, 7 May 2004 18:31:51 +1000, "Matthew" <matthew.hat@stlsoft.dot.org> wrote:

>5. Some other combined approach that I've not anticipated. Please suggest

I think I'd probably prefer to see the free functions implemented as static methods in the class. Of course, that's a 100% class-based approach, isn't it??? Well...not really.

And, I suppose they're not really free functions if they're implemented as static methods inside of a class, are they? Well....kind of.

Anyhow, that's what I'd like to see.

But, my runner-up vote is for a mixed approach, all in the same module.

--Benji Smith

Matthew wrote:

> Please let me know your thoughts
> 
> Cheers
> 
> Matthew

This is a difficult issue, because it involves both inconsistency and usability.

Consider this.... what if printf were a class member?  This code:

	if (number == 0)
		printf("The number is 0!");

Would then be changed to this in OOP style:

	if (number == 0)
	{
		wannabePrintf printer = new wannabePrintf;
		printer.data = "The number is 0!";
		printer.print();
	}
(I realize I'm overdoing it a bit, but it's just an example...)

Personally, I see this as what I call "OOP overusage".  In some cases, I see OOP used just so you can say, "I'm cool because I am using OOP for everything!"  But, in some cases this just makes the code more confusing and long....

I see the purpose of OOP to be that of maintainability and abstraction.  If functions are strongly linked and have nothing to do with other functions, they should be linked.  If, on the other hand, they have only meaning to do with each other, and have no shared variables, and no real reason to be OOP... I don't believe they should be.

But then, many will disagree with me.  To some, a drawn out example is much more desirable because, well, basically they like OOP.

Either way, while option #3 really sounds great the way you put it... making it so there are too many ways to do things seems like a bad idea.

Then again, PHP does it with mysqli - and people like that, and it's not going to make things all that confusing or inconsistent at all.

-[Unknown]

> The options as I see it are:
>
>1. free functions only
>2. class-interface only
>3. combined approach, in same module
>4. combined approach, in (for example) std.c.loader.d (for the free functions)
>and std.loader.d (for the class)
>5. Some other combined approach that I've not anticipated. Please suggest

My vote is for 2, with some suggestions to make free functions work (option 5)

My $0.02:

A class-only loader can still be made to work with 'free function' dll's, if the dll is simply thought to expose a reference to a 'default' interface of static functions alongside anything else that std.loader wants to add for D classes.

It would be good design since the functions are grouped as a unit, as they exist in the library, yet still maintains compatibility with existing dll/dso's.  This also avoids duplication of effort when writing an application that may need to use a multitude of different libraries with the same interface: its code you'd have to write anyway.

Also, its the most straight-forward approach since everything is grouped in one place, under a single architecture.