SpookyET wrote:
> The way type description works in .NET is that an assembly (exe, dll) has  meta data, just like you have in an mp3 file that describes all the  classes (methods, properties, fields, etc.) and you have some classes in  System.Diagnostics; namespace that can read that data, that is why visual  studio has intellisense, so when you type obj. (it lists all the  properties/methods/fields etc after the dot and documentation that you put  in the source code about each argument).  It can be done the same in D.

Yes, without changing anything. Runtime parsing is a good solution with D, while it was not possible with most languages so far.

> As for the DLLs, that works for functions, but what about Classes? and  what about latebinding? loading dlls at startup (plugins). 

Late binding is always late. ;> DLLs cannot legally export classes, they can only export functions, but you can make such a function create a class. Someone was planning on a plug-in system implemented using these facilities. It would use LoadLibrary and GetProcAdress from Windows, and  similar facilities on other OSes.

I'm currently thinking of creating a Demo Editor, which is something very similar in structure and needs to a Delphi-like IDE. In particular, it needs to implement property editors and such! This is not gonna be easy, so i'll be asking others for advice soon. This involves parsing through D files (or separate description files), and automatically generating sophisticated access routines. Besides, we clearly need to mark published properties in some manner. I would suggest by using the pragma syntax, but perhaps we can move Walter to do something else. However, Java style reflection in compiler is not appropriate, since it would add too much weight to applications where they don't need it.

> Also D must
> also work with .NET, because Longhorn will have a managed API and from now  on everything will be managed, at least on the windows operating system. 

Someone may write a D compiler for .NET, it shouldn't be too hard. However, managed world is a paranoia. Longhorn has to stay compatible with software written for prior Windows versions, else noone needs it.

>  A language is very weak without a good class library and from
> what i'm  seeing is module projects ununited with the C style crap that
> has been  arround for years and you can't do RAD with them.

Ur, what? You should avoid using C standard library from D in applications, but wrap it into better libraries. RAD is a buzzword. D library currently simply lacks of too much, but i think the core is OK.

-eye

Dude, in .NET you can do all that. For example at compile time i can have a dll with objects in it.  For example DigitalPlay.dll.

namespace Test
{
	using DigitalPlay.FoobarClient;
	
	class Testing
	{
		DigitalPlay.FoobarClient.Client foo = new DigitalPlay.FoobarClient.Client();
		// or shortcut it since i sayed using...
		Client foo = new Client();
	}
}

csc.exe Test.cs /resources:DigitalPlay.dll

The compiler looks for types in the resources provided and links them, No *.lib, header files no nothing. For late binding, it is a little more complicated:

I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and how they describe themselves.  If you do this crap the same as it has been done before C-Like, that what is the point? Show some progress, damn it. D has potential, but you have to create a nice class library like .NET and stop doing the C-way of doing things. D, a 21st century language with the mentality of 1970s.


Main.cs

using System;
using System.IO;
using System.Reflection;
using PluginTest.Interfaces;

namespace PluginTest
{
	class Host : PluginTest.Interfaces.IHost
	{
		public static void Main()
		{
			PluginServices.Plugin[] plugins;
			Host app = new Host();

			Console.WriteLine("Searching for plugins...");
			plugins = PluginServices.FindPlugins(Environment.CurrentDirectory, "PluginTest.Interfaces.IPlugin");
			Console.WriteLine("Done.\n");

			foreach (PluginServices.Plugin plugin in plugins)
			{
				Console.WriteLine("Loading plugin: " + plugin.Name);
				IPlugin pluginInterface = (IPlugin) PluginServices.CreateInstance(plugin);
				Console.WriteLine("Initializing...");
				pluginInterface.Initialize(app);
				Console.WriteLine("Done.\n");
				Console.WriteLine("Value: " + pluginInterface.Calculate(54, 4));
				Console.WriteLine("\n");
			}
		}

		public void ShowFeedback(string feedback)
		{
			Console.WriteLine(feedback);
		}
	}
}

Interfaces.cs

using System;

namespace PluginTest.Interfaces
{
	public interface IPlugin
	{
		void Initialize(IHost host);
		
		string Name
		{
			get;
		}
		
		double Calculate(int a, int b);
	}

	public interface IHost
	{
		void ShowFeedback(string strFeedback);
	}
}

PluginService.cs

sing System;
using System.Collections;
using System.IO;
using System.Reflection;

namespace PluginTest
{
	internal class PluginServices
	{
		public struct Plugin
		{
			public string assemblyPath;
			public string name;

			public string AssemblyPath
			{
				get
				{
					return assemblyPath;
				}
				set
				{
					assemblyPath = value;
				}
			}
			public string Name
			{
				get
				{
					return name;
				}
				set
				{
					name = value;
				}
			}
		}

		public static Plugin[] FindPlugins(string path, string requiredInterfaceName)
		{
			ArrayList plugins = new ArrayList();
			int i;
			string[] assemblies;
			Assembly assembly;

			assemblies = Directory.GetFileSystemEntries(path, "*.dll");
			
			for (i = 0; i < assemblies.Length; i++)
			{
				try
				{
					assembly = Assembly.LoadFrom(assemblies[i]);
					ExamineAssembly(assembly, requiredInterfaceName, plugins);
				}
				catch
				{
					// error
				}
			}

			Plugin[] results = new Plugin[plugins.Count];

			if (plugins.Count != 0)
			{
				plugins.CopyTo(results);
				return results;
			}
			else
			{
				return null;
			}
		}

		private static void ExamineAssembly(Assembly assembly, string requiredInterfaceName, ArrayList plugins)
		{
			Type interfaceType;
			Plugin plugin;

			foreach (Type type in assembly.GetTypes())
			{
				if (type.IsPublic)
				{
					if (!((type.Attributes & TypeAttributes.Abstract) == TypeAttributes.Abstract))
					{
						interfaceType = type.GetInterface(requiredInterfaceName);

						if (interfaceType != null)
						{
							plugin = new Plugin();
							plugin.AssemblyPath = assembly.Location;
							plugin.Name = type.FullName;
							plugins.Add(plugin);
						}
					}
				}
			}
		}

		public static object CreateInstance(Plugin plugin)
		{
			Assembly assembly;
			object o;
			try
			{
				assembly = Assembly.LoadFrom(plugin.AssemblyPath);
				o = assembly.CreateInstance(plugin.Name);
			}
			catch
			{
				return null;
			}

			return (object) o;
		}
	}
}

Plugin.cs

using System;
using PluginTest.Interfaces;
namespace PluginTest
{
	public class Add : PluginTest.Interfaces.IPlugin
	{
		private IHost host;

		public void Initialize(IHost host)
		{
			this.host = host;
		}

		public string Name
		{
			get
			{
				return "Example Plugin 1 - Adds two numbers";
			}
		}

		public double Calculate(int a, int b)
		{
			return a + b;
		}
	}
}


For a system api call i'd use
namespace Testing
{
	using System.Runtime.InteropServices;

	public class Tester
	{
		[DllImport("kernel32.dll")]
		private static extern bool FreeConsole();
		public static void Main()
		{
			FreeConsole();
		}
	}
}

So yes, you can use CLASSES from DLLS and no shitty header files or lib files.

On Sat, 21 Feb 2004 21:06:28 +0100, Ilya Minkov <minkov@cs.tum.edu> wrote:

> SpookyET wrote:
>> The way type description works in .NET is that an assembly (exe, dll) has  meta data, just like you have in an mp3 file that describes all the  classes (methods, properties, fields, etc.) and you have some classes in  System.Diagnostics; namespace that can read that data, that is why visual  studio has intellisense, so when you type obj. (it lists all the  properties/methods/fields etc after the dot and documentation that you put  in the source code about each argument).  It can be done the same in D.
>
> Yes, without changing anything. Runtime parsing is a good solution with D, while it was not possible with most languages so far.
>
>> As for the DLLs, that works for functions, but what about Classes? and  what about latebinding? loading dlls at startup (plugins).
>
> Late binding is always late. ;> DLLs cannot legally export classes, they can only export functions, but you can make such a function create a class. Someone was planning on a plug-in system implemented using these facilities. It would use LoadLibrary and GetProcAdress from Windows, and   similar facilities on other OSes.
>
> I'm currently thinking of creating a Demo Editor, which is something very similar in structure and needs to a Delphi-like IDE. In particular, it needs to implement property editors and such! This is not gonna be easy, so i'll be asking others for advice soon. This involves parsing through D files (or separate description files), and automatically generating sophisticated access routines. Besides, we clearly need to mark published properties in some manner. I would suggest by using the pragma syntax, but perhaps we can move Walter to do something else. However, Java style reflection in compiler is not appropriate, since it would add too much weight to applications where they don't need it.
>
>  > Also D must
>> also work with .NET, because Longhorn will have a managed API and from now  on everything will be managed, at least on the windows operating system.
>
> Someone may write a D compiler for .NET, it shouldn't be too hard. However, managed world is a paranoia. Longhorn has to stay compatible with software written for prior Windows versions, else noone needs it.
>
>  >  A language is very weak without a good class library and from
>  > what i'm  seeing is module projects ununited with the C style crap that
>  > has been  arround for years and you can't do RAD with them.
>
> Ur, what? You should avoid using C standard library from D in applications, but wrap it into better libraries. RAD is a buzzword. D library currently simply lacks of too much, but i think the core is OK.
>
> -eye
>



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

In article <opr3qg1nu41s9n15@saturn>, SpookyET says...
>
>[...] visual studio has intellisense, so when you type obj. (it lists all the properties/methods/fields etc after the dot and documentation that you put in the source code about each argument).  It can be done the same in D.

That's already done in leds (although alpha quality and no docs (yet?))

http://leds.sourceforge.net

Ant

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c18dkd$2cka$1@digitaldaemon.com...
> SpookyET wrote:
> > The way type description works in .NET is that an assembly (exe, dll) has  meta data, just like you have in an mp3 file that describes all the  classes (methods, properties, fields, etc.) and you have some classes in  System.Diagnostics; namespace that can read that data, that is why visual  studio has intellisense, so when you type obj. (it lists all the  properties/methods/fields etc after the dot and documentation that you put  in the source code about each argument).  It can be done the same in D.
>
> Yes, without changing anything. Runtime parsing is a good solution with D, while it was not possible with most languages so far.
>
> > As for the DLLs, that works for functions, but what about Classes? and what about latebinding? loading dlls at startup (plugins).
>
> Late binding is always late. ;> DLLs cannot legally export classes, they
> can only export functions, but you can make such a function create a
> class. Someone was planning on a plug-in system implemented using these
> facilities. It would use LoadLibrary and GetProcAdress from Windows, and
>   similar facilities on other OSes.

The next version of Phobos will contain my std.loader module, which has a free-function API and the ExeModule auto class. See http://www.prowiki.org/wiki4d/wiki.cgi?Phobos

> I'm currently thinking of creating a Demo Editor, which is something very similar in structure and needs to a Delphi-like IDE. In particular, it needs to implement property editors and such! This is not gonna be easy, so i'll be asking others for advice soon. This involves parsing through D files (or separate description files), and automatically generating sophisticated access routines. Besides, we clearly need to mark published properties in some manner. I would suggest by using the pragma syntax, but perhaps we can move Walter to do something else. However, Java style reflection in compiler is not appropriate, since it would add too much weight to applications where they don't need it.
>
>  > Also D must
> > also work with .NET, because Longhorn will have a managed API and from now  on everything will be managed, at least on the windows operating system.
>
> Someone may write a D compiler for .NET, it shouldn't be too hard. However, managed world is a paranoia. Longhorn has to stay compatible with software written for prior Windows versions, else noone needs it.
>
>  >  A language is very weak without a good class library and from
>  > what i'm  seeing is module projects ununited with the C style crap that
>  > has been  arround for years and you can't do RAD with them.
>
> Ur, what? You should avoid using C standard library from D in applications, but wrap it into better libraries. RAD is a buzzword. D library currently simply lacks of too much, but i think the core is OK.
>
> -eye
>

Matthew wrote:

> 
> 
> The next version of Phobos will contain my std.loader module, which has a
> free-function API and the ExeModule auto class. See
> http://www.prowiki.org/wiki4d/wiki.cgi?Phobos
> 
> 

Will it be possible to load *.so using your class?

Stephan

Two things. First, If you want to post inline, you *must* convert tabs to space, otherwise you're post is unreadable, and won't be read.

Second, this post is way too large for inline. For this reason also it won't be read. Just post a .CS, and we can read it (with highlighting, etc.) in VS

Third (who said I could count!), I'm afraid I'm getting increasingly disinterested in your posts because you do nothing but evangelise .NET, without providing any substantive evidence to back your cause. In some cases, you don't even seem to read the post of the person to whom you're ostensibly responding.

I now assume that you have little experience in, and no time for, any other languages. I personnally tend to loose the capacity to listen to people who seem to think that there is only one way (language, paradigm, whatever); just look at the threads regarding D on c.l.c.m to see another kind of dogma at work.

You seem to think that C# is the perfect language, and that OO is the perfect paradigm. Both of these mark you out, in my personal estimation, as somewhat naive, and I question your motivation in this group.

You speak of "shitty header files or lib files" and "C style crap that has been arround for years" and " you can't do RAD with them", and it just makes you look like a goose. Almost all languages - VB excepted - have something positive to offer.

Consider:

1.    I am using C# right now to write a vacuum cleaner utility for my test
machine, using the recls .NET mapping (http://recls.org/), of course <g>.
2.    I'm currently using Python to write some management utilities to help
me do the next release of the STLSoft (C++/STL) libraries.
3.    I use Perl scripts (available at http://synsoft.org/perl.html) to
detabify, en bloc, directories of header files.
4.    I wrote the shell extensions (http://shellext.com/) in C & C++.

Do you really think the latter three should have been implemented in C#, and <stifles mirth>in an object-oriented way</stifles mirth>?

In "The Pragmatic Programmer", Hunt and Thomas recommend that every programmer, of every level of seniority, learn at least one new language each year. I couldn't agree more. It doesn't mean that one has to be a master of them - that's clearly impossible - but the exposure causes one to think outside the constraints of one's mental box. For my part, I spent too many years thinking entirely in C and C++ - the only languages I'm "expert" in - but I am thankful that I've evolved to become at least journeyman level in C#, D, Java, Perl, Python and (with much chagrin) VB. This means that the vacuum utility can be written in the language ideal for it - C# - in a fraction of the time it would take me in C++. The detabification scripts can be done in a fraction of the time it would take in C/C++/C#/Java. And so on and so forth.

There's another important factor you've apparently not considered. .NET comes with a runtime. C/C++/D do not. Consider the included file, that I wrote to print out the different entries in directories. It's entirely self contained, so there's no runtime. In compiled form it's only 90k (although the C programmer in me bristles that it's anything more than 20k)

(And before anyone "corrects" me, I know it is possible to compile .NET to native, but it doesn't exactly produce small executables!)

Consider the shell extensions (http://shellext.com/). They work with *any* version of Win32, even Windows 95. Can the same be said of .NET equivalents? Furthermore, they're around 50k each. Can the same be said of .NET equivalents? They're extremely simple to write with a combination of ATL and my own shell extension templates. Out of interest I translated one to .NET, and it took vastly more time and LOCs.

D is far from perfect, and there's plenty of scope for informed improvement. But the salient word there is "informed". If you don't even understand C/D library conventions, then how can you speak authoratively on whether the C# mechanisms are an improvement? You say that C is crap, and fail to see the contradiction in the fact that it's been the most successful language by a huge margin, and will continue to be so for at least the next 10-15 years, despite what the marketing gurus at MS or Sun would have us believe. This just makes you seem ignorant, and any valuable comments you make will be lost in people's shit filters.

I do hope you'll continue your interest in D, as D is enriched by a wide range of opinion. But I hope you'll (i) learn more about D, and (ii) take up the challenge and implement some of the things you want to see; you might be pleasantly surprised. If you continue to just tell all us poor fools how much better C#, no one will listen to you. It's not because we dare not hear the truth, it's that you're wrong.

C# is indeed great for some things, but not for others. As for D. As for all other languages (except VB <g>). The difference is that D is new, we have the ear of the designer, and we can contribute to the standard library. There is huge scope for influence, and that is the thing that interests the many diversely talented people involved.

Cheers

Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

-----------------------------------------------------


"SpookyET" <not4_u@hotmail.com> wrote in message news:opr3qm0fro1s9n15@saturn...
> Dude, in .NET you can do all that. For example at compile time i can have a dll with objects in it.  For example DigitalPlay.dll.
>
> namespace Test
> {
> using DigitalPlay.FoobarClient;
>
> class Testing
> {
> DigitalPlay.FoobarClient.Client foo = new
> DigitalPlay.FoobarClient.Client();
> // or shortcut it since i sayed using...
> Client foo = new Client();
> }
> }
>
> csc.exe Test.cs /resources:DigitalPlay.dll
>
> The compiler looks for types in the resources provided and links them, No *.lib, header files no nothing. For late binding, it is a little more complicated:
>
> I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and how they describe themselves.  If you do this crap the same as it has been done before C-Like, that what is the point? Show some progress, damn it. D has potential, but you have to create a nice class library like .NET and stop doing the C-way of doing things. D, a 21st century language with the mentality of 1970s.
>
>
> Main.cs
>
> using System;
> using System.IO;
> using System.Reflection;
> using PluginTest.Interfaces;
>
> namespace PluginTest
> {
> class Host : PluginTest.Interfaces.IHost
> {
> public static void Main()
> {
> PluginServices.Plugin[] plugins;
> Host app = new Host();
>
> Console.WriteLine("Searching for plugins...");
> plugins = PluginServices.FindPlugins(Environment.CurrentDirectory,
> "PluginTest.Interfaces.IPlugin");
> Console.WriteLine("Done.\n");
>
> foreach (PluginServices.Plugin plugin in plugins)
> {
> Console.WriteLine("Loading plugin: " + plugin.Name);
> IPlugin pluginInterface = (IPlugin)
> PluginServices.CreateInstance(plugin);
> Console.WriteLine("Initializing...");
> pluginInterface.Initialize(app);
> Console.WriteLine("Done.\n");
> Console.WriteLine("Value: " + pluginInterface.Calculate(54, 4));
> Console.WriteLine("\n");
> }
> }
>
> public void ShowFeedback(string feedback)
> {
> Console.WriteLine(feedback);
> }
> }
> }
>
> Interfaces.cs
>
> using System;
>
> namespace PluginTest.Interfaces
> {
> public interface IPlugin
> {
> void Initialize(IHost host);
>
> string Name
> {
> get;
> }
>
> double Calculate(int a, int b);
> }
>
> public interface IHost
> {
> void ShowFeedback(string strFeedback);
> }
> }
>
> PluginService.cs
>
> sing System;
> using System.Collections;
> using System.IO;
> using System.Reflection;
>
> namespace PluginTest
> {
> internal class PluginServices
> {
> public struct Plugin
> {
> public string assemblyPath;
> public string name;
>
> public string AssemblyPath
> {
> get
> {
> return assemblyPath;
> }
> set
> {
> assemblyPath = value;
> }
> }
> public string Name
> {
> get
> {
> return name;
> }
> set
> {
> name = value;
> }
> }
> }
>
> public static Plugin[] FindPlugins(string path, string
> requiredInterfaceName)
> {
> ArrayList plugins = new ArrayList();
> int i;
> string[] assemblies;
> Assembly assembly;
>
> assemblies = Directory.GetFileSystemEntries(path, "*.dll");
>
> for (i = 0; i < assemblies.Length; i++)
> {
> try
> {
> assembly = Assembly.LoadFrom(assemblies[i]);
> ExamineAssembly(assembly, requiredInterfaceName, plugins);
> }
> catch
> {
> // error
> }
> }
>
> Plugin[] results = new Plugin[plugins.Count];
>
> if (plugins.Count != 0)
> {
> plugins.CopyTo(results);
> return results;
> }
> else
> {
> return null;
> }
> }
>
> private static void ExamineAssembly(Assembly assembly, string
> requiredInterfaceName, ArrayList plugins)
> {
> Type interfaceType;
> Plugin plugin;
>
> foreach (Type type in assembly.GetTypes())
> {
> if (type.IsPublic)
> {
> if (!((type.Attributes & TypeAttributes.Abstract) ==
> TypeAttributes.Abstract))
> {
> interfaceType = type.GetInterface(requiredInterfaceName);
>
> if (interfaceType != null)
> {
> plugin = new Plugin();
> plugin.AssemblyPath = assembly.Location;
> plugin.Name = type.FullName;
> plugins.Add(plugin);
> }
> }
> }
> }
> }
>
> public static object CreateInstance(Plugin plugin)
> {
> Assembly assembly;
> object o;
> try
> {
> assembly = Assembly.LoadFrom(plugin.AssemblyPath);
> o = assembly.CreateInstance(plugin.Name);
> }
> catch
> {
> return null;
> }
>
> return (object) o;
> }
> }
> }
>
> Plugin.cs
>
> using System;
> using PluginTest.Interfaces;
> namespace PluginTest
> {
> public class Add : PluginTest.Interfaces.IPlugin
> {
> private IHost host;
>
> public void Initialize(IHost host)
> {
> this.host = host;
> }
>
> public string Name
> {
> get
> {
> return "Example Plugin 1 - Adds two numbers";
> }
> }
>
> public double Calculate(int a, int b)
> {
> return a + b;
> }
> }
> }
>
>
> For a system api call i'd use
> namespace Testing
> {
> using System.Runtime.InteropServices;
>
> public class Tester
> {
> [DllImport("kernel32.dll")]
> private static extern bool FreeConsole();
> public static void Main()
> {
> FreeConsole();
> }
> }
> }
>
> So yes, you can use CLASSES from DLLS and no shitty header files or lib files.
>
> On Sat, 21 Feb 2004 21:06:28 +0100, Ilya Minkov <minkov@cs.tum.edu> wrote:
>
> > SpookyET wrote:
> >> The way type description works in .NET is that an assembly (exe, dll) has  meta data, just like you have in an mp3 file that describes all the  classes (methods, properties, fields, etc.) and you have some classes in  System.Diagnostics; namespace that can read that data, that is why visual  studio has intellisense, so when you type obj. (it lists all the  properties/methods/fields etc after the dot and documentation that you put  in the source code about each argument).  It can be done the same in D.
> >
> > Yes, without changing anything. Runtime parsing is a good solution with D, while it was not possible with most languages so far.
> >
> >> As for the DLLs, that works for functions, but what about Classes? and what about latebinding? loading dlls at startup (plugins).
> >
> > Late binding is always late. ;> DLLs cannot legally export classes, they
> > can only export functions, but you can make such a function create a
> > class. Someone was planning on a plug-in system implemented using these
> > facilities. It would use LoadLibrary and GetProcAdress from Windows, and
> >   similar facilities on other OSes.
> >
> > I'm currently thinking of creating a Demo Editor, which is something very similar in structure and needs to a Delphi-like IDE. In particular, it needs to implement property editors and such! This is not gonna be easy, so i'll be asking others for advice soon. This involves parsing through D files (or separate description files), and automatically generating sophisticated access routines. Besides, we clearly need to mark published properties in some manner. I would suggest by using the pragma syntax, but perhaps we can move Walter to do something else. However, Java style reflection in compiler is not appropriate, since it would add too much weight to applications where they don't need it.
> >
> >  > Also D must
> >> also work with .NET, because Longhorn will have a managed API and from now  on everything will be managed, at least on the windows operating system.
> >
> > Someone may write a D compiler for .NET, it shouldn't be too hard. However, managed world is a paranoia. Longhorn has to stay compatible with software written for prior Windows versions, else noone needs it.
> >
> >  >  A language is very weak without a good class library and from
> >  > what i'm  seeing is module projects ununited with the C style crap
> > that
> >  > has been  arround for years and you can't do RAD with them.
> >
> > Ur, what? You should avoid using C standard library from D in applications, but wrap it into better libraries. RAD is a buzzword. D library currently simply lacks of too much, but i think the core is OK.
> >
> > -eye
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Indeed. It's implemented for both Win32 and Linux

"Stephan Wienczny" <wienczny@web.de> wrote in message news:c18op5$2vmq$1@digitaldaemon.com...
> Matthew wrote:
>
> >
> >
> > The next version of Phobos will contain my std.loader module, which has
a
> > free-function API and the ExeModule auto class. See http://www.prowiki.org/wiki4d/wiki.cgi?Phobos
> >
> >
>
> Will it be possible to load *.so using your class?
>
> Stephan
>

Matthew wrote:
> Two things. First, If you want to post inline, you *must* convert tabs to
> space, otherwise you're post is unreadable, and won't be read.

The tabs are visible in my newsreader (Mozilla Thunderbird) and in the web interface http://www.digitalmars.com/drn-bin/wwwnews?D/24356.

That said, I agree completely with the other 95% of your post. Spooky is obviously a fan of C#. I'm happy for him.

-- 
Justin
http://jcc_7.tripod.com/d/

You don't understand me.  I don't evangelize .NET; I evangelize some
features of C#/.NET that should be in D.
-I want D to succeed, because I want a native C# (since I don't know what
mono is going to be, and it always is 2 years behind Microsoft).
-I want you people to think out of the box!  C# was done by people
thinking out of the box.  D has functions, so for those that want to use
functions, let them. -I like OO (used functions once), but found OO better.
-I want D to have a library like delphi/.net has, full OO and component
based (modern design of class libraries). For C++ you have
vcf.sourceforge.net
-In .NET you can have classes in dlls, D can have them too, no one is
forcing you to use the dll format dictated by MS before .NET was arround.
-Becaues C\C++ have been arround for a lot of time, it doesn't mean that
it is the best thing and stuff should still be done like that (that is why
D has been invented).  Most people use Internet Explorer, is that the best
browser? No.
- D isn't perfect, but it can be close to perfect if you people think out
of the box for a minute.
- The delegate/event model of C# should be included in D because, it makes
it very easy to work with event based programming.
- Methods/Properties should be PascalCase, it doesn't force you to use
_var m_var and other types of decoration.
- Indexers are cool since they allow you to use a class/struct like an
array:

public class Building
{
     Story[] stories;

     public  Story this[int index] //doesn't have to be int eg: HashTable
     {
         get { return stories[index];
         set
         {
             if (value != null)
                 stories[index] = value;
         }
     }
}

public class Test
{
     public static void Main()
     {
         Building myHouse = new Building();
         myHouse[10] = new Story("The last story");
     }
}

- Operator overloading: It is easier to use the operators instead of functions (eg: opAdd()) when overloding.

  public static bool operator != (Bar x, Bar y) {
	return x.value != y.value;
  }

- Attributes: Attributes are super cool and developers should be able to
extend the language using attributes.
   Attributes in D should have a better syntax to show that those things
are different.  The reason why in C# they are [MyAttribute()] is
MyAttribute is a class and you can have [MyAttribute(argument1, argument2,
argument3)]
class MyAttribute : FoobarAttribute
{
   // extend it
}

[MyAttribute()]
  expression

- C# has nailed a lot of good stuff, they looked at many languages when
they made it. So D should have them too.
- Namespaces and strong named assemblies (with metadata about the types)
in dll format.  It is very anoying that you have to use the file system.
- No header files (assemblies with meta data that support classes).
- No more dozens of lines of ugly code to include a dll dynamically, take
a look at the examples  Assembly.Load("mydll.dll"), use the classes in it
with no problem.  A framework like that would be super cool in D.
- Take a look at this article
http://genamics.com/developer/csharp_comparative.htm and at the C#
Language Reference.  All that cool stuff should be included.  If there is
another cool thing that another language has that isn't in C#, included it
too. But C# is perfect in a lot of ways.  Right now D is doing it the C
way.
- You can't build apps as fast in C++/C/D as you can do in .NET with any
language (not as fast in Managed C++ since it has a lot of quircks).
- Learn from .NET, and make D development as easy as it is in .NET.  It
currently isn't. It is less complicated than C++ but with the library
thing, it is just as worse (eg hard to load dlls, no classes, still, libs,
headerfiles. ).


I have attached those files that were posted, even though they look fine in Opera 7.5.  How come you can't see the tabs?

This is the earlier post:

Dude, in .NET you can do all that. For example at compile time i can have a dll with objects in it.  For example DigitalPlay.dll.

namespace Test
{
using DigitalPlay.FoobarClient;

class Testing
{
     public static void Main() {
      DigitalPlay.FoobarClient.Client foo = new
DigitalPlay.FoobarClient.Client();
      // or shortcut it since i sayed using...
      Client foo = new Client();
}
}

csc.exe Test.cs /resources:DigitalPlay.dll

The compiler looks for types in the resources provided and links them, No *.lib, header files no nothing. For late binding, it is a little more complicated:

Interfaces.cs (dll)
PluginServices.cs (dll)
Plugin.cs (dll)
Main.cs (exe)
***Attachment***

Compilation
1) Interfaces.dll
2) PluginServices.dll (csc /target:library /resources:Interfaces.dll)
4) Plugin.dll (csc.exe /target:library
/resources:Interface.dll;Pluginservices.dll)
3) Main.exe (csc.exe Main.cs /resources:Interfaces.dll;PluginServices.dll)


The code is self explanatory.

I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and how they describe themselves.  If you do this crap the same as it has been done before C-Like, that what is the point? Show some progress, damn it. D has potential, but you have to create a nice class library like .NET and stop doing the C-way of doing things. D, a 21st century language with the mentality of 1970s.

For a system api call i'd use
namespace Testing
{
   // using isn't import, it is a shortcut so you won't have to type the
whole thing
   using System.Runtime.InteropServices;

   public class Tester
   {
     [DllImport("kernel32.dll")]
     private static extern bool FreeConsole();
     public static void Main()
     {
        FreeConsole();
     }
   }
}

So yes, you can use CLASSES in DLLS and no shitty header files or lib files.

- This is for now, I'll post anything else that I forgot some other time.
- I don't evangalize C# as something that should be used over D, I want C#
features to be in D.
- There is one feature in D, that i'd like in C#, so i'll use for instead:
   foreach (int i, char c; a)
   { ]
   In C# you don't have access to the index.

   C#
   foreach (ElementType element in collection) { // statement}

   translates into

   IEnumerator enumerator =
((System.IEnumerable)(collection)).GetEnumerator();
    try {
    while (enumerator.MoveNext()) {
       ElementType element = (ElementType)enumerator.Current;
       statement;
    }
   }
finally {
    IDisposable disposable = enumerator as System.IDisposable;
    if (disposable != null) disposable.Dispose();
}

Well said Mathew!

Phill.



"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c18qbr$r4$1@digitaldaemon.com...
> Two things. First, If you want to post inline, you *must* convert tabs to space, otherwise you're post is unreadable, and won't be read.
>
> Second, this post is way too large for inline. For this reason also it
won't
> be read. Just post a .CS, and we can read it (with highlighting, etc.) in
VS
>
> Third (who said I could count!), I'm afraid I'm getting increasingly disinterested in your posts because you do nothing but evangelise .NET, without providing any substantive evidence to back your cause. In some cases, you don't even seem to read the post of the person to whom you're ostensibly responding.
>
> I now assume that you have little experience in, and no time for, any
other
> languages. I personnally tend to loose the capacity to listen to people
who
> seem to think that there is only one way (language, paradigm, whatever); just look at the threads regarding D on c.l.c.m to see another kind of
dogma
> at work.
>
> You seem to think that C# is the perfect language, and that OO is the perfect paradigm. Both of these mark you out, in my personal estimation,
as
> somewhat naive, and I question your motivation in this group.
>
> You speak of "shitty header files or lib files" and "C style crap that has been arround for years" and " you can't do RAD with them", and it just
makes
> you look like a goose. Almost all languages - VB excepted - have something positive to offer.
>
> Consider:
>
> 1.    I am using C# right now to write a vacuum cleaner utility for my
test
> machine, using the recls .NET mapping (http://recls.org/), of course <g>. 2.    I'm currently using Python to write some management utilities to
help
> me do the next release of the STLSoft (C++/STL) libraries.
> 3.    I use Perl scripts (available at http://synsoft.org/perl.html) to
> detabify, en bloc, directories of header files.
> 4.    I wrote the shell extensions (http://shellext.com/) in C & C++.
>
> Do you really think the latter three should have been implemented in C#,
and
> <stifles mirth>in an object-oriented way</stifles mirth>?
>
> In "The Pragmatic Programmer", Hunt and Thomas recommend that every programmer, of every level of seniority, learn at least one new language each year. I couldn't agree more. It doesn't mean that one has to be a master of them - that's clearly impossible - but the exposure causes one
to
> think outside the constraints of one's mental box. For my part, I spent
too
> many years thinking entirely in C and C++ - the only languages I'm
"expert"
> in - but I am thankful that I've evolved to become at least journeyman
level
> in C#, D, Java, Perl, Python and (with much chagrin) VB. This means that
the
> vacuum utility can be written in the language ideal for it - C# - in a fraction of the time it would take me in C++. The detabification scripts
can
> be done in a fraction of the time it would take in C/C++/C#/Java. And so
on
> and so forth.
>
> There's another important factor you've apparently not considered. .NET comes with a runtime. C/C++/D do not. Consider the included file, that I wrote to print out the different entries in directories. It's entirely
self
> contained, so there's no runtime. In compiled form it's only 90k (although the C programmer in me bristles that it's anything more than 20k)
>
> (And before anyone "corrects" me, I know it is possible to compile .NET to native, but it doesn't exactly produce small executables!)
>
> Consider the shell extensions (http://shellext.com/). They work with *any* version of Win32, even Windows 95. Can the same be said of .NET
equivalents?
> Furthermore, they're around 50k each. Can the same be said of .NET equivalents? They're extremely simple to write with a combination of ATL
and
> my own shell extension templates. Out of interest I translated one to
.NET,
> and it took vastly more time and LOCs.
>
> D is far from perfect, and there's plenty of scope for informed
improvement.
> But the salient word there is "informed". If you don't even understand C/D library conventions, then how can you speak authoratively on whether the
C#
> mechanisms are an improvement? You say that C is crap, and fail to see the contradiction in the fact that it's been the most successful language by a huge margin, and will continue to be so for at least the next 10-15 years, despite what the marketing gurus at MS or Sun would have us believe. This just makes you seem ignorant, and any valuable comments you make will be lost in people's shit filters.
>
> I do hope you'll continue your interest in D, as D is enriched by a wide
> range of opinion. But I hope you'll (i) learn more about D, and (ii) take
up
> the challenge and implement some of the things you want to see; you might
be
> pleasantly surprised. If you continue to just tell all us poor fools how much better C#, no one will listen to you. It's not because we dare not
hear
> the truth, it's that you're wrong.
>
> C# is indeed great for some things, but not for others. As for D. As for
all
> other languages (except VB <g>). The difference is that D is new, we have the ear of the designer, and we can contribute to the standard library. There is huge scope for influence, and that is the thing that interests
the
> many diversely talented people involved.
>
> Cheers
>
> Matthew Wilson
>
> Director, Synesis Software
>     (www.synesis.com.au)
> STLSoft moderator
>     (http://www.stlsoft.org)
> Contributing editor, C/C++ Users Journal
>     (www.synesis.com.au/articles.html#columns)
>
> -----------------------------------------------------
>
>
> "SpookyET" <not4_u@hotmail.com> wrote in message news:opr3qm0fro1s9n15@saturn...
> > Dude, in .NET you can do all that. For example at compile time i can
have
> > a dll with objects in it.  For example DigitalPlay.dll.
> >
> > namespace Test
> > {
> > using DigitalPlay.FoobarClient;
> >
> > class Testing
> > {
> > DigitalPlay.FoobarClient.Client foo = new
> > DigitalPlay.FoobarClient.Client();
> > // or shortcut it since i sayed using...
> > Client foo = new Client();
> > }
> > }
> >
> > csc.exe Test.cs /resources:DigitalPlay.dll
> >
> > The compiler looks for types in the resources provided and links them,
No
> > *.lib, header files no nothing. For late binding, it is a little more complicated:
> >
> > I could have showed you this in a few lines, but insted I showed you a full plugin system.  This also shows you the power of .NET types and how they describe themselves.  If you do this crap the same as it has been done before C-Like, that what is the point? Show some progress, damn it.
D
> > has potential, but you have to create a nice class library like .NET and stop doing the C-way of doing things. D, a 21st century language with
the
> > mentality of 1970s.
> >
> >
> > Main.cs
> >
> > using System;
> > using System.IO;
> > using System.Reflection;
> > using PluginTest.Interfaces;
> >
> > namespace PluginTest
> > {
> > class Host : PluginTest.Interfaces.IHost
> > {
> > public static void Main()
> > {
> > PluginServices.Plugin[] plugins;
> > Host app = new Host();
> >
> > Console.WriteLine("Searching for plugins...");
> > plugins = PluginServices.FindPlugins(Environment.CurrentDirectory,
> > "PluginTest.Interfaces.IPlugin");
> > Console.WriteLine("Done.\n");
> >
> > foreach (PluginServices.Plugin plugin in plugins)
> > {
> > Console.WriteLine("Loading plugin: " + plugin.Name);
> > IPlugin pluginInterface = (IPlugin)
> > PluginServices.CreateInstance(plugin);
> > Console.WriteLine("Initializing...");
> > pluginInterface.Initialize(app);
> > Console.WriteLine("Done.\n");
> > Console.WriteLine("Value: " + pluginInterface.Calculate(54, 4));
> > Console.WriteLine("\n");
> > }
> > }
> >
> > public void ShowFeedback(string feedback)
> > {
> > Console.WriteLine(feedback);
> > }
> > }
> > }
> >
> > Interfaces.cs
> >
> > using System;
> >
> > namespace PluginTest.Interfaces
> > {
> > public interface IPlugin
> > {
> > void Initialize(IHost host);
> >
> > string Name
> > {
> > get;
> > }
> >
> > double Calculate(int a, int b);
> > }
> >
> > public interface IHost
> > {
> > void ShowFeedback(string strFeedback);
> > }
> > }
> >
> > PluginService.cs
> >
> > sing System;
> > using System.Collections;
> > using System.IO;
> > using System.Reflection;
> >
> > namespace PluginTest
> > {
> > internal class PluginServices
> > {
> > public struct Plugin
> > {
> > public string assemblyPath;
> > public string name;
> >
> > public string AssemblyPath
> > {
> > get
> > {
> > return assemblyPath;
> > }
> > set
> > {
> > assemblyPath = value;
> > }
> > }
> > public string Name
> > {
> > get
> > {
> > return name;
> > }
> > set
> > {
> > name = value;
> > }
> > }
> > }
> >
> > public static Plugin[] FindPlugins(string path, string
> > requiredInterfaceName)
> > {
> > ArrayList plugins = new ArrayList();
> > int i;
> > string[] assemblies;
> > Assembly assembly;
> >
> > assemblies = Directory.GetFileSystemEntries(path, "*.dll");
> >
> > for (i = 0; i < assemblies.Length; i++)
> > {
> > try
> > {
> > assembly = Assembly.LoadFrom(assemblies[i]);
> > ExamineAssembly(assembly, requiredInterfaceName, plugins);
> > }
> > catch
> > {
> > // error
> > }
> > }
> >
> > Plugin[] results = new Plugin[plugins.Count];
> >
> > if (plugins.Count != 0)
> > {
> > plugins.CopyTo(results);
> > return results;
> > }
> > else
> > {
> > return null;
> > }
> > }
> >
> > private static void ExamineAssembly(Assembly assembly, string
> > requiredInterfaceName, ArrayList plugins)
> > {
> > Type interfaceType;
> > Plugin plugin;
> >
> > foreach (Type type in assembly.GetTypes())
> > {
> > if (type.IsPublic)
> > {
> > if (!((type.Attributes & TypeAttributes.Abstract) ==
> > TypeAttributes.Abstract))
> > {
> > interfaceType = type.GetInterface(requiredInterfaceName);
> >
> > if (interfaceType != null)
> > {
> > plugin = new Plugin();
> > plugin.AssemblyPath = assembly.Location;
> > plugin.Name = type.FullName;
> > plugins.Add(plugin);
> > }
> > }
> > }
> > }
> > }
> >
> > public static object CreateInstance(Plugin plugin)
> > {
> > Assembly assembly;
> > object o;
> > try
> > {
> > assembly = Assembly.LoadFrom(plugin.AssemblyPath);
> > o = assembly.CreateInstance(plugin.Name);
> > }
> > catch
> > {
> > return null;
> > }
> >
> > return (object) o;
> > }
> > }
> > }
> >
> > Plugin.cs
> >
> > using System;
> > using PluginTest.Interfaces;
> > namespace PluginTest
> > {
> > public class Add : PluginTest.Interfaces.IPlugin
> > {
> > private IHost host;
> >
> > public void Initialize(IHost host)
> > {
> > this.host = host;
> > }
> >
> > public string Name
> > {
> > get
> > {
> > return "Example Plugin 1 - Adds two numbers";
> > }
> > }
> >
> > public double Calculate(int a, int b)
> > {
> > return a + b;
> > }
> > }
> > }
> >
> >
> > For a system api call i'd use
> > namespace Testing
> > {
> > using System.Runtime.InteropServices;
> >
> > public class Tester
> > {
> > [DllImport("kernel32.dll")]
> > private static extern bool FreeConsole();
> > public static void Main()
> > {
> > FreeConsole();
> > }
> > }
> > }
> >
> > So yes, you can use CLASSES from DLLS and no shitty header files or lib files.
> >
> > On Sat, 21 Feb 2004 21:06:28 +0100, Ilya Minkov <minkov@cs.tum.edu>
wrote:
> >
> > > SpookyET wrote:
> > >> The way type description works in .NET is that an assembly (exe, dll) has  meta data, just like you have in an mp3 file that describes all the  classes (methods, properties, fields, etc.) and you have some classes in  System.Diagnostics; namespace that can read that data,
that
> > >> is why visual  studio has intellisense, so when you type obj. (it
lists
> > >> all the  properties/methods/fields etc after the dot and
documentation
> > >> that you put  in the source code about each argument).  It can be
done
> > >> the same in D.
> > >
> > > Yes, without changing anything. Runtime parsing is a good solution
with
> > > D, while it was not possible with most languages so far.
> > >
> > >> As for the DLLs, that works for functions, but what about Classes?
and
> > >> what about latebinding? loading dlls at startup (plugins).
> > >
> > > Late binding is always late. ;> DLLs cannot legally export classes,
they
> > > can only export functions, but you can make such a function create a class. Someone was planning on a plug-in system implemented using
these
> > > facilities. It would use LoadLibrary and GetProcAdress from Windows,
and
> > >   similar facilities on other OSes.
> > >
> > > I'm currently thinking of creating a Demo Editor, which is something very similar in structure and needs to a Delphi-like IDE. In
particular,
> > > it needs to implement property editors and such! This is not gonna be easy, so i'll be asking others for advice soon. This involves parsing through D files (or separate description files), and automatically generating sophisticated access routines. Besides, we clearly need to mark published properties in some manner. I would suggest by using the pragma syntax, but perhaps we can move Walter to do something else. However, Java style reflection in compiler is not appropriate, since
it
> > > would add too much weight to applications where they don't need it.
> > >
> > >  > Also D must
> > >> also work with .NET, because Longhorn will have a managed API and
from
> > >> now  on everything will be managed, at least on the windows operating system.
> > >
> > > Someone may write a D compiler for .NET, it shouldn't be too hard. However, managed world is a paranoia. Longhorn has to stay compatible with software written for prior Windows versions, else noone needs it.
> > >
> > >  >  A language is very weak without a good class library and from
> > >  > what i'm  seeing is module projects ununited with the C style crap
> > > that
> > >  > has been  arround for years and you can't do RAD with them.
> > >
> > > Ur, what? You should avoid using C standard library from D in applications, but wrap it into better libraries. RAD is a buzzword. D library currently simply lacks of too much, but i think the core is
OK.
> > >
> > > -eye
> > >
> >
> >
> >
> > --
> > Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>
>