Walter and I are having a little friendly disagreement which is holding up the inclusion of the std.loader module into Phobos.

Basically, it goes like this:

Walter believes that every module should have a single, unambiguous API. He is happy for that to be either free functions, or classes, although he would probably admit to a preference for classes for most things.

I believe that what Walter believes is a good thing, except for the fact that I see that it limits the choices of developers. Some people want to use free functions, others a class-based approach, others to mix and match as they deem appropriate. (I'm in the last camp.)

I don't ascribe to the free function-only approach because object-orientation has a lot going for it. If people want that exclusively, then C is the language for them, methinks.

I don't ascribe to the class-only model for the converse reasons - i.e. sometimes free functions are more convenient/appropriate - in general, and for the specific reason that I don't believe that exceptions represent the "one true error-handling mechanism", and I don't want to be forced to use them when _I_ deem that it's not appropriate to my requirements. Sometimes I want to write small utilities and simply get a success/rail result from a function. I certainly want this facility with std.loader, as I plan to write version/COM-server trawling utilities and I don't see it as appropriate to be using exceptions (since exceptions are for exceptional circumstances, not for testing things, IMO at least).

Hence, the way I've written loader.d (and some other modules), is that there is a free function API, and a thin class (+ exceptions) wrapper over that API. This affords the flexibility to suit all tastes.

I won't bang on about the advantages of this approach further, as those that agree already agree, and it's my experience that those who want only a class-only approach cannot be persuaded to look at the virtues of the other side. (Walter asserts that the dual approach makes the code harder to maintain. I assert the contrary. After much debate, we're both still seeing it our own way. Must be one of those things, I guess ...)

What I'm interested in is getting a feeling for the general level of support for the following options.

Before I enumerate those options, let me make it clear that I don't believe this approach is valid for all modules, far from it. The std.windows.registry, std.mmfile and the std.perf (not yet included) modules are entirely class-based. The std.recls module has both, and I have written std.loader as both. It is this latter that is the sticking point, as Walter does not want to release it in such a guise.

 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

Cheers

Matthew

Matthew wrote:

>3. combined approach, in same module
>  
>
We're only hearing one side of the story but 3 is the obvious choice for me.  Some times it nicer to deal with classes others, free-functions.  You've gotta strike the right balance.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c7fhhj$2gtc$1@digitaldaemon.com>, Matthew says...
>

>Please let me know your thoughts
>

I'm pissed off now!

Please state clearly if our analises and conclusins are going to by included on a product that is the sole property of Synesis before asking for contributions.

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

Thanks.

Respectifully (how ever it's spelled)

Ant

Hi Matthew.

My coin into can.
> 3. combined approach, in same module
+1

Regards.

Hi Matthew.

My coin into can.
> 3. combined approach, in same module
+1

Regards.

Hi Matthew.

My coin into can.
> 3. combined approach, in same module
+1

Regards.

> 3. combined approach, in same module

I agree with that. Anyhow, I believe it can be made more specific:

The core of the concept of classes is, that they encapsulate data. A class that has only static members should really be considered a module instead. Purely object-oriented languages like Java don't have the concept of free functions, so you are forced to create such module-like classes. In D, it should be avoided, unless there is a good reason to do so.

So, up to this point we have one rule: use a class interface, if you encapsulate data, use a free-function-interface, if you don't.

The remaining question: if you have a class, which functions should be defined inside as members, which ones outside, as external free functions.

For this, one can give a simple ruleto start with: any function that has to access private internals of the class should be defined inside the class. (friend access is, of course, possible inside of modules, but should be avoided unless there is good reason to do so) any other functions, that access the class only via its public interface, should be considered to be moved out of the class as free functions.

Of course, there are plenty exceptions to these rules, but at least, these are a first guideline to stick to, unless you see a good reason to do it differently.

On Fri, 7 May 2004 18:31:51 +1000, Matthew wrote:

> Walter and I are having a little friendly disagreement which is holding up the inclusion of the std.loader module into Phobos.
> 
> Basically, it goes like this:

[SNIP]

>  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

Option 4 (as it can be seen as a superset of option 3).

A computer programing language is a toolkit. How the coder uses those tools is their decision. If they choose to use a hammer to drive a screw in, so be it on their heads. But remember that a screwdriver makes a very handy paint-tin opener too.

A *major* goal for a general-purpose computer language is to make the act of coding easier for people, according to their needs. The designers of such a language ought to facilitate this goal.

-- 
Derek
Melbourne, Australia

Matthew wrote:


> 3. combined approach, in same module
> 
> Cheers
> 
> Matthew

Matthew,

I like the combined approach.

But I have to say that Ant is right. Free software developers would be trapped with the Synesis Licence. This is very annoying to us. In fact, Synesis Licence, AFAIK, is incompatible with some widely used free licences (such as GPL).

I know you have the right to maintain your code with your licence, and I fully respect it. The problem is that Phobos is to much tied with Synesis code and it would bring trouble to free software projects that use D.

Cheers,

Bruno.

On Fri, 7 May 2004 09:19:35 +0000 (UTC), Ant wrote:

> In article <c7fhhj$2gtc$1@digitaldaemon.com>, Matthew says...
>>
> 
>>Please let me know your thoughts
>>
> 
> I'm pissed off now!
> 
> Please state clearly if our analises and conclusins are going to by included on a product that is the sole property of Synesis before asking for contributions.
> 
> What Synesis decides to do with that product is irrelevant for the fact the our work might be beeing donated to Synesis.
> 
> Thanks.
> 
> Respectifully (how ever it's spelled)

<soapbox>
There is a distinction between a software specification and the
implementation of that specification. It is (mostly) reasonable that the
sponsor of an implementation (not necessarily its author) have ownership of
the implementation.
However, any original ideas that are contained in a specification, are
always owned by the author of the idea until ownership is explicitly
assigned away by the author.

Thus I feel that discussions like these go in to maintaining the specification. It then up to the implementation team to convert the changes into real code.

To summarize, Synesis will continue to own the Digital Mars D compiler code but our original ideas that are incorporated into the D specification are not automatically owned by Synesis.

You are quite free to write your own D compiler and thus own that implementation.

</soapbox>

-- 
Derek
Melbourne, Australia