Benji Smith wrote:

> 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.

I must say, this is a lovely idea.  Unless I'm mistaken, these could be aliased even to have exactly the affect of free functions, am I wrong?

-[Unknown]

In article <c7gmg4$189a$1@digitaldaemon.com>, Unknown W. Brackets says...
>	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....

Actually, it would be more like:

formatted_output::printf("the number is 0!");

I don't like this ... but it does have the advantage that the only symbol
that get dumped into the table is "formatted_output".  Remember, OOP is intended
to solve "large program" maintainability problems.  It's a weapon designed to go
after "mega-fauna" programming problems.  In a program with 100,000 functions,
this is a real boon.

If you are doing a lot of output, you could even do this:

class mod_printf {
static P(int x) {...}
static P(double x) {...}
static P(char[] x) {...}

// Print in hexadecimal
static X(int x) {...}    // 0x1234
static X(double x) {...} // not used much
static X(char[] x) {...} //"\AA \BC"
};

foo(int snum, char[] name)
{
with(mod_printf) {
P("Struct #"); X(snum); P("\n");
P("Name ");P(name);P(" in hex [");X(name);P("]\n");
}
}

Now, P() doesn't clutter the symbol table, but you can write concise code when
you want to.  (A non-static version could do faster, buffered, output.)

Kevin

On Fri, 07 May 2004 11:42:08 -0700, "Unknown W. Brackets" <unknown@at.simplemachines.dot.org> wrote:

>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?

its not a problem its a principle.

>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.

it is exactly that, we all accept (I assume) that D is owned by
Walter/Digital mars, and any money Walter makes from our sugestions is
just payment for giving us the D compiler for free.
however with Synesis it is not so clear, why loader.d for instance,
instead of improving the dynloader.d I posted feb 2003
http://www.digitalmars.com/drn-bin/wwwnews?D/11102
which was free for everyone to use and modify and give back to the
community without charge or restriction, Walter/synesis chose to give
similar functionality but with restriction.


>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?

I think he's very justified in blaming the license, he's put in a lot of effort for little/no reward only to find that someone (other than Walter) may be rewarded for his efforts.

>
>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]
that is you opinion, and your choice, do not expect everyone to wish to follow your example, which is uncorroborated.

Mike

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7fhhj$2gtc$1@digitaldaemon.com...
> Walter believes that every module should have a single, unambiguous API.

Yes.

> 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 feel that a class should be used where there is some 'state' to be set and preserved across the function calls, and that free functions should be used when the functionality is stateless. For example, std.regexp has state, and so is a class. std.file functions are all atomic, and so is a collection of free functions.

State is a problem that classes are an ideal solution for. Otherwise, your free functions wind up needing state pointers (i.e. 'this' for classes), and organizational control over the construction, destruction, invariants, resource management and exception safety is lost. Furthermore, if the state consists of static data, the free function must also deal with thread safety and synchronization of it.

I don't agree with the "everything must be in a class" approach, either, as a function that tests to see if a file exists is atomic and has no state. Why instantiate a class for it?

There's a place for both free functions and classes, but I strongly disagree with Matthew's point of view that each module should provide both to access the same functionality. I disagree because:

1) either the free function or the class version is going to be an
unfortunate kludge, for the aforementioned reasons.
2) dual interfaces mean double the documentation.
3) dual interfaces mean double the bugs.
4) dual interfaces mean twice as much code to maintain.
5) dual interfaces leads the programmer to wonder why there are two and
which he should use. He's got twice as much to learn, for no incremental
utility.
6) library bloat.

(Matthew points out that 3 and 4 may be mitigated by having the two versions be shells over a lower layer that does the implementation. I counter with another layer being just another source of bugs <g>.)

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c7g4tc$dak$1@digitaldaemon.com...
> > 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

It's an interesting dilemma.

I like the quote "In sum, this book stretches cause and effect in order to sell books to those who want to avoid responsibility for their own decisions", although only, I suppose, because it suits my position in the current debate.

In general I'm for orthogonality. For example, the STLSoft string classes don't follow std::basic_string<> and provide a gazillion kitchen sink methods that can be easily emulated with the standard algorithms.

I find it interesting to look at the scripting languages. Perl has many ways of doing things; IMO it's overly complex and arbitrary. Python has just one way of doing each thing; IMO it's a complete doddle to use, and is great. Ruby is kind of halfway between the two; IMO it's the best of the three.

Go figure!

"Mike Wynn" <one_mad_alien@hotmail.com> wrote in message news:fmon90dcch9sqi36uqnv33q6vj8s7hf5i7@4ax.com...
> Walter/Digital mars, and any money Walter makes from our sugestions is just payment for giving us the D compiler for free.

I haven't made any money whatsoever off of D itself <g>. The idea is to make money doing presentations on D and producing books, articles, training materials, etc.

> however with Synesis it is not so clear, why loader.d for instance,
> instead of improving the dynloader.d I posted feb 2003
> http://www.digitalmars.com/drn-bin/wwwnews?D/11102
> which was free for everyone to use and modify and give back to the
> community without charge or restriction, Walter/synesis chose to give
> similar functionality but with restriction.

Matthew has promised to change the license, but it's moot at the moment because we don't agree on the design of loader.d.

Be that as it may, there is an ongoing problem here of people posting code like yours - it gets lost in the blizzard of postings. We must do better. I propose one of the two:

1) make a newsgroup digitalmars.D.sourcecode for contributions.
2) add it to the D wiki.

"Andy Friesen" <andy@ikagames.com> wrote in message news:c7g80s$iap$1@digitaldaemon.com...
> 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.

To be sure, in most cases I agree. But I think that enforced unity in all cases is against the spirit of C (http://www.comeaucomputing.com/faqs/genfaq.html#betterCgeneral) - which is a good spirit! - and is too reminiscent of the way of Java, which is, IMO, too much of a nannying approach.

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

Absolutely true. I only believe that this joint approach is appropriate in a minority of cases. For example, the std.windows.registry module is entirely class-based, as to do otherwise would be an incredible unusable mess, and little better than using the Win32 Reg* API directly.

> 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)

For std.loader, the class and free functions share the exact same implementation, except that the former throw exceptions on errors, and the latter return false/null/etc. Hence, there are virtually no additional maintenance considerations.

This is, in fact, one of my criteria for determining whether something is suitable for a dual approach. If the combined approach cannot be only, say, 110% or less of the effort of one alone, then I think long and hard about whether the benefits of the freedom of choice is worth the costs of the additional coding/maintenance.

It is only such similar modules that I'm advocating for option 3.

I agree, i honestly think the base library needs to be free functions only, then a supllemental library that wraps all the base in OO.

Write now its all sorts of mixed up, with seemingly no structure.  Maybe its time to start a phobos alternative.

C

On Sat, 08 May 2004 03:04:18 +0000, mike parker <mike@aldacron.com> wrote:

> 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.



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Unfortunately, because Walter and I've been arguing about the implementation of this, it may have been misunderstood by the community.

*All* it is is a platform-independent layer over LoadLibrary/GetProcAddress
(Win32) / dlopen/dlsym (Linux).

There is certainly a need for a class loader that builds upon this basic module, and I'd be happy to participate in that with others later on, but that's not what's addressed in this module.



"Eric Anderton" <ericanderton at yahoo dot comEric_member@pathlink.com> wrote in message news:c7gn61$1969$1@digitaldaemon.com...
> > 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.
>
>

> 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
>

Exactly how many functions are we talking about? Are there complex
interaction patterns, or is it simply 'loadModule( string )'?
If it's really trivial to write a wrapper class I'd go for 1, and perhaps
make a 'wrappers' module which contains helper classes for those who feel
they cannot do without (so essentially that's your option 4, but not in
std.c.loader.d but rather std.wrappers)

A class based approach would make most sense when there's a context needed to store some data while invoking different methods from the API. A class with only static methods makes less sense to me, since you already have a mechanism (the module) to group related functionality, using a class for that purpose seems wrong