On Sat, 8 May 2004 11:08:26 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> It just means that to use it in the way I want, I've now got to write my own free
> functions which will wrap the API, e.g.
>
>     HXModule MyExeModule_Load(in char[] moduleName)
>     {
>         try
>         {
>             ExeModule module = new ExeModule(moduleName);
>
>             return module.handle;
>         }
>         catch(ExeModuleException)
>         {
>             return null;
>         }
>     }
>
> In fact - <sickening realisation>arrgh!</sickening realisation> - I can't do that, because the ExeModule instance owns the loaded module, and when it gets GC'd, the module will be freed, leaving me holding a handle to nothing.
>
> The alternative it to provide a detach() method for ExeModule, but then that just encourages mixing programming modes for a given component, something I do *not* advocate .
>
> Oh man, this sucks hard. I guess I won' be using the Phobos module that I've contributed to Phobos. How's that for code bloat irony? :(

Have you considered the 'singleton' approach for your alternate API, eg.

ExeModule m;

HXModule MyExeModule_Load(in char[] moduleName)
{
	if(m is null) {
		try {
			m = new ExeModule(moduleName);
		}
		catch (ExeModuleException) {
			return null;
		}
	}
	return m->handle;
}

(I'm new to D so the above syntax may not be correct, by the idea is the important part)

I know there are threading issues with the singleton approach. But it appears to me a module load *is* a singleton, you only need one per execution.

Regan.

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

In article <c7gvgv$1log$1@digitaldaemon.com>, Unknown W. Brackets says...
>Yes, but you still have formatted_output in the sumbol table.  Before you had printf.  Big difference.

Well, printf, sprintf, snprintf, vsprintf, puts, etc.

>Yes, in many cases using classes can clean stuff up when you're too, frankly, lazy to establish a clean naming convention.  And again, classes have most certainly their place, but using them for no reason is like buying a new truck to transport a single piece of paper.
.
>The difference for me is that I've always seen OOP as a method to address issues that are caused by deeper problems anyway.  But I'm not arguing OOP here, just saying that there are clean reasons for using either.
>
>-[Unknown]

I agree - putting all those in one object, which contains no state, is not all that great.  You can solve the problem better with modules or some other namespace like mechanism, etc.

But if all a language has is classes, they get used as modules and namespaces
and delegates (ie operator() in C++), and a hundred other things.

It's important to solve the namespace crowding problem, but most of the techniques will look similar:  provide a grouping mechanism (classes with no non-static methods, or modules, or namespaces), then provide a "uses" mechanism so they don't have to type the wrapper name.

Kevin

Kevin Bealer wrote:

> It's important to solve the namespace crowding problem, but most of the
> techniques will look similar:  provide a grouping mechanism (classes with no
> non-static methods, or modules, or namespaces), then provide a "uses" mechanism
> so they don't have to type the wrapper name.
> 
> Kevin

I've always thought of this as a possible function for with.  That's basically how it's used in JavaScript, and it does make some amount of sense - assuming your class names, namespaces, and variable names are all separate.

Then you could also change it to something like:

	with (varName):

Just like with version, etc.  I like it better, personally, than the way .NET/etc. handles it where, at least to my recollection, you import namespaces per-file or something. (okay, again, I don't really like OOP generally so I may not be remembering properly.)  But this could get ugly... so I'm not going to argue for or against this syntax either.

But, yes, I agree with what you said entirely.

-[Unknown]

Derek wrote:
> 
> 
> It seems that I totally misunderstood Matthew's approach. I agree with
> Walter here. Functionality should be provided in either free functions *or*
> a class, but not both.
> 
> If a set of functionality is provided in one form, but the coder wishes to
> use the other form, she can write a new module that 'wraps' the supplied
> form to convert it's interface.
> 
> 

Although if there's enough people who want to do this, it's going to be a lot more error-prone to have everyone roll their own versus having one maintained API.

Chris

<tangent>
Actually, in an object oriented system that truely models the computer, the
isFile method would be a function of some sort of filesystem object.  There
is really no suck thing as a truely atomic function, however, in being
practical, one must sacrifice true modeling at times.
</tangent>

Perhaps I should change my handle to "thePurist"

Walter wrote:

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