www.digitalmars.com         C & C++   DMDScript  

D - I want string and bool

reply SpookyET <not4_u hotmail.com> writes:
Damn, D needs a bool type, and a string type. yeah you got a nice char[]  
but you still need to do string manipulation, so a string class is still  
needed for string.format(), string.split(), string.toUppercase() and stuff  
like that.  Might just well create the string type in the language. This  
is string in .NET  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemstringmemberstopic.asp

The types are under the System namespace.

Actually, thinking about it, there is no point in poluting the language  
with a lot of crap, you always need extensions so a good class library  
like the .net framework is better. do you really need associative arrays?  
You can have a class for that, and a string class and so on, and have  
"string" as an alias, just like the .net languages.  C# and other .net  
langs are just eye candy to MSIL (Microsoft Intermediate Language  
(assembler)).
System.Char (char) C#
System.String (string)
System.Int32 (int)
System.Int16 (short) and so on

The way the class library is designed in .NET (ripoff of Delphi's but  
better) is super cool. The best way is to create something like that,  
instead of creating all this ununited modules...

I'm thinking about making System.Console for console input output, but i  
haven't figured out how to access user32.dll from D yet.
There is no point in messing with printf and other old school stuff.

We need namespaces in D. What do you do if in 2 packages you have a class  
with the same name? Components based programming with namespaces is the  
best thing!

System.Console.WriteLine("Foobar");...
Feb 20 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
SpookyET wrote:
 Damn, D needs a bool type, and a string type. yeah you got a nice 
 char[]  but you still need to do string manipulation, so a string class 
 is still  needed for string.format(), string.split(), 
 string.toUppercase() and stuff  like that.  Might just well create the 
 string type in the language. This  is string in .NET  
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemst
ingmemberstopic.asp 

object module from Phobos is always implicitly imported. It contains the definition of bool, which is an alias to bit. And please, don't start a new discussion on whether it's good or bad, it's been talked to death. And current solution works well and everyone is more or less happy.
 The way the class library is designed in .NET (ripoff of Delphi's but  
 better) is super cool. The best way is to create something like that,  
 instead of creating all this ununited modules...

What do you mean by uninited modules???? They can be grouped. I don't know anything about C#, but i know C++ and its system of namespaces is a major trouble for every building process. And i know the Java system of packages, but D's modules are an extension of it.
 I'm thinking about making System.Console for console input output, but 
 i  haven't figured out how to access user32.dll from D yet.
 There is no point in messing with printf and other old school stuff.

When writing a console library, potability is a major consern. *please* use the C standard library or the already defined Phobos parts as the back-end. Or is there anything which you want in your library which cannot be done upon these? Besides, take a look at the libraries already written by Carlos and Vathix and others. You find them all at the Wiki. BTW, module names should be lowercase, to alleviate for filesystem issues and to avoid collision with class names.
 We need namespaces in D. What do you do if in 2 packages you have a 
 class  with the same name? Components based programming with namespaces 
 is the  best thing!

There is no problem. If you have: import a; import b; //both ambiguously define callMe() int main(){ callMe(); //Ambiguous! a.callMe(); //OK! b.callMe(); //OK! return 0; } The advantage is that a build system can determine all files to participate in compilation from the header part of the unit.
 System.Console.WriteLine("Foobar");...

This is possible already, like i've shown. Reading documentation really helps. ;) -eye
Feb 20 2004
parent reply SpookyET <not4_u hotmail.com> writes:
That is why I like namespaces, you can name them however you want since  
they have nothing to do with the file system.

In .NET everything is compiled into an assembly (dll, exe).

So consider this:

namespace MyCompany.MyProduct
{
   using System;

   class App
   {
     public static void Main(string[] args)
     {
	//System.Console.WriteLine("Hello World!");
       Console.WriteLine("Hello World!");
     }
   }
}

you compile it with csc.exe hello.cs /resources:System.dll
at the first glance you wouldn't know if System is a class or namespace  
(.net newbs)
but every type in .net describes itself, every field, property, method etc.
so in a good IDE you would know.  I can have as many namespaces as i want  
in a file/files in a project.  The convention is to use one class per file.
The assembly has metadata with all the types and namespaces, so things can  
be found easily no matter if it is linux or windows.  and i can name them  
however i want since they are not depened on the file system.  I believe  
that D can learn  a lot from .NET and C# in general.

As for System.Console in D
i was planning on doing it as portable as an interface
module system; (i want namespaces)
class Console
{
	writeLine(char[] text)
       {
		version (Linux)
             {
                 // linux code
             }

		version (Windows)
   		{
			//windows code
			if i only knew how to access user32.dll
		}
       }
}

in C# i use an [DllImport("user32.dll")] extern static int Method(int foo);

I saw something about std.windows.window but it makes no sense? can't i  
just access dlls?

On Sat, 21 Feb 2004 01:41:43 +0100, Ilya Minkov <minkov cs.tum.edu> wrote:

 SpookyET wrote:
 Damn, D needs a bool type, and a string type. yeah you got a nice  
 char[]  but you still need to do string manipulation, so a string class  
 is still  needed for string.format(), string.split(),  
 string.toUppercase() and stuff  like that.  Might just well create the  
 string type in the language. This  is string in .NET   
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemstringmemberstopic.asp

object module from Phobos is always implicitly imported. It contains the definition of bool, which is an alias to bit. And please, don't start a new discussion on whether it's good or bad, it's been talked to death. And current solution works well and everyone is more or less happy.
 The way the class library is designed in .NET (ripoff of Delphi's but   
 better) is super cool. The best way is to create something like that,   
 instead of creating all this ununited modules...

What do you mean by uninited modules???? They can be grouped. I don't know anything about C#, but i know C++ and its system of namespaces is a major trouble for every building process. And i know the Java system of packages, but D's modules are an extension of it.
 I'm thinking about making System.Console for console input output, but  
 i  haven't figured out how to access user32.dll from D yet.
 There is no point in messing with printf and other old school stuff.

When writing a console library, potability is a major consern. *please* use the C standard library or the already defined Phobos parts as the back-end. Or is there anything which you want in your library which cannot be done upon these? Besides, take a look at the libraries already written by Carlos and Vathix and others. You find them all at the Wiki. BTW, module names should be lowercase, to alleviate for filesystem issues and to avoid collision with class names.
 We need namespaces in D. What do you do if in 2 packages you have a  
 class  with the same name? Components based programming with namespaces  
 is the  best thing!

There is no problem. If you have: import a; import b; //both ambiguously define callMe() int main(){ callMe(); //Ambiguous! a.callMe(); //OK! b.callMe(); //OK! return 0; } The advantage is that a build system can determine all files to participate in compilation from the header part of the unit.
 System.Console.WriteLine("Foobar");...

This is possible already, like i've shown. Reading documentation really helps. ;) -eye

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 20 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
SpookyET wrote:

 The assembly has metadata with all the types and namespaces, so things 
 can  be found easily no matter if it is linux or windows.  and i can 
 name them  however i want since they are not depened on the file 
 system.  I believe  that D can learn  a lot from .NET and C# in general.

The thing is, Net uses a sort of intermediate representation. Since we don't want to force any databases or intermediate representations on our language, it would not be feasible to requiere separation between file structure and module hirarchy. Besides, i still fail to see any limitations of the current system. You can easily create shortcuts/links. We have digc (the dig compiler), the perfect example of a to-be build system. You only specify the root file of your application which contains main, and it recursively determines all modules which have to be built and builds them! Is anything like that possible with C#?
 in C# i use an [DllImport("user32.dll")] extern static int Method(int foo);

 I saw something about std.windows.window but it makes no sense? can't i  
 just access dlls?

HUH? You still don't understand? Learn to use DLLs from C, man! It's the same with D. In D you write, if this is a Windows DLL: extern(Windows) int function(int foo); This gives you a prototype. Its difference from a normal prototype is exactly this extern(Windows) which specifies a calling convention. BTW, you can group these extern to have less to type. Then, it is up to linker to find where you are importing this from. For that, when you want to import from mylib.dll, you must link with mylib.lib, which in turn you can create from a DLL using implib utility. This lib is only a stub library which contains "tails" by which Windows exe loader connects the executable to an actual DLL. -eye
Feb 21 2004
parent reply SpookyET <not4_u hotmail.com> writes:
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.

As for the DLLs, that works for functions, but what about Classes? and  
what about latebinding? loading dlls at startup (plugins). 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.   
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.


On Sat, 21 Feb 2004 19:26:48 +0100, Ilya Minkov <minkov cs.tum.edu> wrote:





-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 21 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Feb 21 2004
next sibling parent reply SpookyET <not4_u hotmail.com> writes:
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/
Feb 21 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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/

Feb 21 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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 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/
Feb 21 2004
prev sibling next sibling parent reply SpookyET <not4_u hotmail.com> writes:
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 8bit

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();
}
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Disposition: attachment; filename=Interfaces.cs
Content-Type: application/octet-stream; name=Interfaces.cs
Content-Transfer-Encoding: 8bit

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);
	}
}
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Disposition: attachment; filename=Main.cs
Content-Type: application/octet-stream; name=Main.cs
Content-Transfer-Encoding: 8bit

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);
		}
	}
}
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Disposition: attachment; filename=Plugin.cs
Content-Type: application/octet-stream; name=Plugin.cs
Content-Transfer-Encoding: 8bit

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;
		}
	}
}
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Disposition: attachment; filename=PluginServices.cs
Content-Type: application/octet-stream; name=PluginServices.cs
Content-Transfer-Encoding: 8bit

using 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;
		}
	}
}

------------X6GdKj0MKFEpsdf1V7BNYF--
Feb 21 2004
next sibling parent Juan C <Juan_member pathlink.com> writes:
<snip>
-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.

What you seem to not understand is that once someone else has done it, it's no longer "outside the box". Also, doing something simply because it's "outside the box" is bad. Walter has made his decisions based on many years of experience, not simply to be different. And putting in a feature simply because some other popular new language has it is also bad. Yes, if there were nothing different it wouldn't be a new language, so there must be some new stuff, and there is. D maintains a delicate balance between easily porting existing C code and fixing some of the "flaws" of C, while also adding "new" technology (most of which isn't actually new, just not in ANSI C). I, personally, would rather that more of the "flaws" of C were fixed or fixed differently, but that's not going to happen in D. So I stopped arguing my points and have shut up (hint hint). P.S. Poor grammar and spelling and profanity hurt your case.
Feb 21 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to me your posts smack of the former, despite being individually presented as the latter
 -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).

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and small P). Another aspect was, and I say this with some regret, to make programming more accessible to less competent people. I have witnessed this myself, whereby folks on C# and Java projects are happy to play with threads and other non-trivial concepts more than they would be in C/C++ because .NET/Java makes it easier for them to do so without making basic mistakes. However, the level of mistakes just moves to a higher level, evincing itself in bad design as opposed to broken code. To my mind, this barely represents a postive step. Writing software is the most complex activity man has undertaken. (It was quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?
  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found OO

You used functions once. ROFL. Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments. It's like someone who only speaks, say, Italian, saying that Italian is the only language worth knowing. "Oh sure, I learned a few phrases in French once, but you can't say as much in French as you can in Italian".
 -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

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO is superior, and I'm still waiting for you to offer some proof
 -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.

I don't understand the point you're making here.
 -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.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is an even balance between OO (including ADTs and runtime-polymorphism) and generics, with just a dash of procedural thrown in for good measure <ASIDE>C++ remains the best language at the moment because it ably supports *all* current programming paradigms (apart from functional, I guess, although some of the more abstruse meta techniques are moving in that direction). No other widely-used language can claim this, and the watered down attempts for generics in C# and Java are not going to come anywhere near allowing them to join the club. D aims to be the second one, and IMHO it stands a very good chance at doing so. If you would care to point out where this statement is wrong, I'll fry up my undies with a little extra virgin olive oil and eat them for dinner.</ASIDE>
 - D isn't perfect, but it can be close to perfect if you people think out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements. At this point I've exhausted my reserve of interest. Apologies if you have some good points further down. Cheers Matthew
 - 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();
 }

Feb 21 2004
parent reply SpookyET <not4_u hotmail.com> writes:
You just, stopped at reading the good part, features of C# that I want in  
D.
Did you look at those attachments, that asked for?
My target isn't you anyway, it is Mr. Walter Bright.
I appologize for any spelling mistakes.  As for why I haven't backed some  
of points like OO vs. procedural, those have already been backed up all  
over the net.

You have a right to state your opinion, just as I do.

On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat stlsoft.dot.org>  
wrote:

 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to me your posts smack of the former, despite being individually presented as the latter
 -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).

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and small P). Another aspect was, and I say this with some regret, to make programming more accessible to less competent people. I have witnessed this myself, whereby folks on C# and Java projects are happy to play with threads and other non-trivial concepts more than they would be in C/C++ because .NET/Java makes it easier for them to do so without making basic mistakes. However, the level of mistakes just moves to a higher level, evincing itself in bad design as opposed to broken code. To my mind, this barely represents a postive step. Writing software is the most complex activity man has undertaken. (It was quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?
  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found OO

You used functions once. ROFL. Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments. It's like someone who only speaks, say, Italian, saying that Italian is the only language worth knowing. "Oh sure, I learned a few phrases in French once, but you can't say as much in French as you can in Italian".
 -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

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO is superior, and I'm still waiting for you to offer some proof
 -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.

I don't understand the point you're making here.
 -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.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is an even balance between OO (including ADTs and runtime-polymorphism) and generics, with just a dash of procedural thrown in for good measure <ASIDE>C++ remains the best language at the moment because it ably supports *all* current programming paradigms (apart from functional, I guess, although some of the more abstruse meta techniques are moving in that direction). No other widely-used language can claim this, and the watered down attempts for generics in C# and Java are not going to come anywhere near allowing them to join the club. D aims to be the second one, and IMHO it stands a very good chance at doing so. If you would care to point out where this statement is wrong, I'll fry up my undies with a little extra virgin olive oil and eat them for dinner.</ASIDE>
 - D isn't perfect, but it can be close to perfect if you people think  
 out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements. At this point I've exhausted my reserve of interest. Apologies if you have some good points further down. Cheers Matthew
 - 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();
 }


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 21 2004
next sibling parent reply resistor mac.com writes:
There is no conclusive decision anywhere in the world that OO programming is
inherently better than procedural.  It is a lot more hyped, certainly, and it is
definitely better at representing some kinds of problems.  But for a large class
of problems, it is simply not necessary, and forcing it on those problems is a
horrible corruption of the whole idea of OO.

Point in case: public static void main (String[] args)

There is no reason in the world why the main function should be part of a class.
It makes absolutely no sense, and completely breaks the idea of OO being used to
represent OBJECTS.

The point is, then, that there is no need for any sensible language to be as
rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and some
problems are better off solved procedurally.

Another example:  I just today what a utility in procedural C to do some
statistical analysis on datasets.  There was no need for OO: it just read
values, did some math on them, and wrote them back out.  Now, in Java or another
rigidly OO system, I would have had to define a class just to stick my
procedural function in.  Where is the logic in that?

It is far more useful and flexible, especially for a language like D which
claims to be a systems language as well, NOT to rigidly OO.

-Owen

In article <opr3rbgpw61s9n15 saturn>, SpookyET says...
You just, stopped at reading the good part, features of C# that I want in  
D.
Did you look at those attachments, that asked for?
My target isn't you anyway, it is Mr. Walter Bright.
I appologize for any spelling mistakes.  As for why I haven't backed some  
of points like OO vs. procedural, those have already been backed up all  
over the net.

You have a right to state your opinion, just as I do.

On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat stlsoft.dot.org>  
wrote:

 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to me your posts smack of the former, despite being individually presented as the latter
 -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).

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and small P). Another aspect was, and I say this with some regret, to make programming more accessible to less competent people. I have witnessed this myself, whereby folks on C# and Java projects are happy to play with threads and other non-trivial concepts more than they would be in C/C++ because .NET/Java makes it easier for them to do so without making basic mistakes. However, the level of mistakes just moves to a higher level, evincing itself in bad design as opposed to broken code. To my mind, this barely represents a postive step. Writing software is the most complex activity man has undertaken. (It was quoted at the time that the Win2K os was the most complex machine ever created.) Do we really want less-talented people to be doing it?
  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found OO

You used functions once. ROFL. Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments. It's like someone who only speaks, say, Italian, saying that Italian is the only language worth knowing. "Oh sure, I learned a few phrases in French once, but you can't say as much in French as you can in Italian".
 -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

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO is superior, and I'm still waiting for you to offer some proof
 -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.

I don't understand the point you're making here.
 -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.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is an even balance between OO (including ADTs and runtime-polymorphism) and generics, with just a dash of procedural thrown in for good measure <ASIDE>C++ remains the best language at the moment because it ably supports *all* current programming paradigms (apart from functional, I guess, although some of the more abstruse meta techniques are moving in that direction). No other widely-used language can claim this, and the watered down attempts for generics in C# and Java are not going to come anywhere near allowing them to join the club. D aims to be the second one, and IMHO it stands a very good chance at doing so. If you would care to point out where this statement is wrong, I'll fry up my undies with a little extra virgin olive oil and eat them for dinner.</ASIDE>
 - D isn't perfect, but it can be close to perfect if you people think  
 out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements. At this point I've exhausted my reserve of interest. Apologies if you have some good points further down. Cheers Matthew
 - 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();
 }


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

Feb 21 2004
next sibling parent reply And <And_member pathlink.com> writes:
In article <c19hc7$1h72$1 digitaldaemon.com>, resistor mac.com says...
Point in case: public static void main (String[] args)

Here we go again. that not OO! That one language idea of starting an application. who told you it was a good idea?
There is no reason in the world why the main function should be part of a class.

"main function"? Sorry to say but your mind is already crippled. Why not call it entry point? or start something? Why not have a application object? Java System could be considered an application object. I wouldn't mind to see a language starting an application form a subclass of something like the java System class.
It makes absolutely no sense

Might not be ideal but it works. You are a bit radical aren't you?
 and completely breaks the idea of OO being used to represent OBJECTS.

"completely"? you are completely ...
The point is, then, that there is no need for any sensible language to be as
rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and some
problems are better off solved procedurally.

I would say supid is to use java if you are not going to do OO. Java is suppose to help you coding your OO solution for your problem.
Another example:  I just today what a utility in procedural C to do some
statistical analysis on datasets.  There was no need for OO: it just read
values, did some math on them, and wrote them back out.  Now, in Java or another
rigidly OO system, I would have had to define a class just to stick my
procedural function in.  Where is the logic in that?

What's your problem of having an extra set of {}? You don't have to create a hierarqui of objects to do a simple task. I don't get your point. Of course if you are using java for that you are completly...
It is far more useful and flexible, especially for a language like D which
claims to be a systems language as well, NOT to rigidly OO.

I'm using D rigidly OO, sorry for that... Ant
Feb 21 2004
parent reply "Phill" <phill pacific.net.au> writes:
Is that someone trying to pass themselves off
as "Ant" (antonio) ?
I think he speaks(and spells) a lot better than that.

Phill.

"And" <And_member pathlink.com> wrote in message
news:c19mas$1r6d$1 digitaldaemon.com...
 In article <c19hc7$1h72$1 digitaldaemon.com>, resistor mac.com says...
Point in case: public static void main (String[] args)

Here we go again. that not OO! That one language idea of starting an application. who told you it was a good idea?
There is no reason in the world why the main function should be part of a


 "main function"?
 Sorry to say but your mind is already crippled.
 Why not call it entry point? or start something?
 Why not have a application object?
 Java System could be considered an application object.
 I wouldn't mind to see a language starting an application
 form a subclass of something like the java System class.

It makes absolutely no sense

Might not be ideal but it works. You are a bit radical aren't you?
 and completely breaks the idea of OO being used to represent OBJECTS.

"completely"? you are completely ...
The point is, then, that there is no need for any sensible language to be


rigidly OO as, say, Java.  Forcing some things in OO is just stupid, and


problems are better off solved procedurally.

I would say supid is to use java if you are not going to do OO. Java is suppose to help you coding your OO solution for your problem.
Another example:  I just today what a utility in procedural C to do some
statistical analysis on datasets.  There was no need for OO: it just read
values, did some math on them, and wrote them back out.  Now, in Java or


rigidly OO system, I would have had to define a class just to stick my
procedural function in.  Where is the logic in that?

What's your problem of having an extra set of {}? You don't have to create a hierarqui of objects to do a simple task. I don't get your point. Of course if you are using java for that you are completly...
It is far more useful and flexible, especially for a language like D


claims to be a systems language as well, NOT to rigidly OO.

I'm using D rigidly OO, sorry for that... Ant

Feb 22 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
It seemed odd to me also.

"Phill" <phill pacific.net.au> wrote in message
news:c19pq6$22d5$1 digitaldaemon.com...
 Is that someone trying to pass themselves off
 as "Ant" (antonio) ?
 I think he speaks(and spells) a lot better than that.

 Phill.

 "And" <And_member pathlink.com> wrote in message
 news:c19mas$1r6d$1 digitaldaemon.com...
 In article <c19hc7$1h72$1 digitaldaemon.com>, resistor mac.com says...
Point in case: public static void main (String[] args)

Here we go again. that not OO! That one language idea of starting an application. who told you it was a good idea?
There is no reason in the world why the main function should be part of



 class.
 "main function"?
 Sorry to say but your mind is already crippled.
 Why not call it entry point? or start something?
 Why not have a application object?
 Java System could be considered an application object.
 I wouldn't mind to see a language starting an application
 form a subclass of something like the java System class.

It makes absolutely no sense

Might not be ideal but it works. You are a bit radical aren't you?
 and completely breaks the idea of OO being used to represent OBJECTS.

"completely"? you are completely ...
The point is, then, that there is no need for any sensible language to



 as
rigidly OO as, say, Java.  Forcing some things in OO is just stupid,



 some
problems are better off solved procedurally.

I would say supid is to use java if you are not going to do OO. Java is suppose to help you coding your OO solution for your problem.
Another example:  I just today what a utility in procedural C to do



statistical analysis on datasets.  There was no need for OO: it just



values, did some math on them, and wrote them back out.  Now, in Java



 another
rigidly OO system, I would have had to define a class just to stick my
procedural function in.  Where is the logic in that?

What's your problem of having an extra set of {}? You don't have to create a hierarqui of objects to do a simple task. I don't get your point. Of course if you are using java for that you are completly...
It is far more useful and flexible, especially for a language like D


claims to be a systems language as well, NOT to rigidly OO.

I'm using D rigidly OO, sorry for that... Ant


Feb 22 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c1a2ki$2gko$1 digitaldaemon.com>, Matthew says...
It seemed odd to me also.

"Phill" <phill pacific.net.au> wrote in message
news:c19pq6$22d5$1 digitaldaemon.com...
 Is that someone trying to pass themselves off
 as "Ant" (antonio) ?
 I think he speaks(and spells) a lot better than that.


I'm sorry to say that you are wrong ;( (This shows you how difficult is to communicate on my second language, as soon as I'm a bit tired...) I hope the general idea makes some sense. I had just 2 things to say: - One implementation of the OO paradigma (java) should not be taken as the whole OO - Some "open minded" guys can only see the start of an application as "main function" Ant PS some guys are too lazy even to scroll down to the bottom of the posts to see the answers so don't tell me to use a spell checker every time I post. I use it when it's incorporated on the tool I have to post.
Feb 22 2004
next sibling parent reply resistor mac.com writes:
But what's being advocated here is a completely-OO'd language like Java.  My
entire point is that there is a large class of problems in which OO is entire
unnecessary, and is just extra baggage.

I did not say that OO didn't have a place.  I always write OO when writing UI
code.  That's an instance where it really excels.

As to an "entry object", the whole point is that the object ISN'T USED for entry
other than the fact that this one method happens to be the main execution
branch.  Now, if you wanted to make a language where the "entry object" itself
was initialized with values reflective of the application's current state, you
might have had a better case.  But of the 3 OO languages I use in my daily
programming (Java, C#, and ObjC), none of them does so.  All require you to
access an external system object to obtain application status information.
Hence any purpose there might have been in having an "entry object" is lost,
cause it's not being used as such.

Also, I strongly suggest the phrase close-minded stop being thrown around.  To
me, YOU sound like the close-minded one.  I want to have the option of writing D
in whichever programming idiom I choose to solve the problem.  And you're
telling me I should have to do it your way?  Who's close-minded?

-Owen

In article <c1aipb$cd8$1 digitaldaemon.com>, Ant says...
In article <c1a2ki$2gko$1 digitaldaemon.com>, Matthew says...
It seemed odd to me also.

"Phill" <phill pacific.net.au> wrote in message
news:c19pq6$22d5$1 digitaldaemon.com...
 Is that someone trying to pass themselves off
 as "Ant" (antonio) ?
 I think he speaks(and spells) a lot better than that.


I'm sorry to say that you are wrong ;( (This shows you how difficult is to communicate on my second language, as soon as I'm a bit tired...) I hope the general idea makes some sense. I had just 2 things to say: - One implementation of the OO paradigma (java) should not be taken as the whole OO - Some "open minded" guys can only see the start of an application as "main function" Ant PS some guys are too lazy even to scroll down to the bottom of the posts to see the answers so don't tell me to use a spell checker every time I post. I use it when it's incorporated on the tool I have to post.

Feb 22 2004
next sibling parent reply SpookyET <not4_u hotmail.com> writes:
You people don't read, out of all the features i proposed, you are still  
stuck on the "main" function/method that i wrote in another thread.

On Sun, 22 Feb 2004 16:47:15 +0000 (UTC), <resistor mac.com> wrote:

 But what's being advocated here is a completely-OO'd language like  
 Java.  My
 entire point is that there is a large class of problems in which OO is  
 entire
 unnecessary, and is just extra baggage.

 I did not say that OO didn't have a place.  I always write OO when  
 writing UI
 code.  That's an instance where it really excels.

 As to an "entry object", the whole point is that the object ISN'T USED  
 for entry
 other than the fact that this one method happens to be the main execution
 branch.  Now, if you wanted to make a language where the "entry object"  
 itself
 was initialized with values reflective of the application's current  
 state, you
 might have had a better case.  But of the 3 OO languages I use in my  
 daily
 programming (Java, C#, and ObjC), none of them does so.  All require you  
 to
 access an external system object to obtain application status  
 information.
 Hence any purpose there might have been in having an "entry object" is  
 lost,
 cause it's not being used as such.

 Also, I strongly suggest the phrase close-minded stop being thrown  
 around.  To
 me, YOU sound like the close-minded one.  I want to have the option of  
 writing D
 in whichever programming idiom I choose to solve the problem.  And you're
 telling me I should have to do it your way?  Who's close-minded?

 -Owen

 In article <c1aipb$cd8$1 digitaldaemon.com>, Ant says...
 In article <c1a2ki$2gko$1 digitaldaemon.com>, Matthew says...
 It seemed odd to me also.

 "Phill" <phill pacific.net.au> wrote in message
 news:c19pq6$22d5$1 digitaldaemon.com...
 Is that someone trying to pass themselves off
 as "Ant" (antonio) ?
 I think he speaks(and spells) a lot better than that.


I'm sorry to say that you are wrong ;( (This shows you how difficult is to communicate on my second language, as soon as I'm a bit tired...) I hope the general idea makes some sense. I had just 2 things to say: - One implementation of the OO paradigma (java) should not be taken as the whole OO - Some "open minded" guys can only see the start of an application as "main function" Ant PS some guys are too lazy even to scroll down to the bottom of the posts to see the answers so don't tell me to use a spell checker every time I post. I use it when it's incorporated on the tool I have to post.


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
SpookyET wrote:

 You people don't read, out of all the features i proposed, you are 
 still  stuck on the "main" function/method that i wrote in another 
 thread.

Dam, you write allot. -- -Anderson: http://badmama.com.au/~anderson/
Feb 22 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <c1amei$iou$1 digitaldaemon.com>, resistor mac.com says...
But what's being advocated here is a completely-OO'd language like Java.  My
entire point is that there is a large class of problems in which OO is entire
unnecessary, and is just extra baggage.

I did not say that OO didn't have a place.  I always write OO when writing UI
code.  That's an instance where it really excels.

As to an "entry object", the whole point is that the object ISN'T USED for entry
other than the fact that this one method happens to be the main execution
branch.  Now, if you wanted to make a language where the "entry object" itself
was initialized with values reflective of the application's current state, you
might have had a better case.  But of the 3 OO languages I use in my daily
programming (Java, C#, and ObjC), none of them does so.  All require you to
access an external system object to obtain application status information.
Hence any purpose there might have been in having an "entry object" is lost,
cause it's not being used as such.

Also, I strongly suggest the phrase close-minded stop being thrown around.  To
me, YOU sound like the close-minded one.  I want to have the option of writing D
in whichever programming idiom I choose to solve the problem.  And you're
telling me I should have to do it your way?  Who's close-minded?

-Owen

I didn't try to tell you to do any thing, I'm sorry if it sounds like that. Seems that we agree on the rest, except:
 But what's being advocated here is a completely-OO'd language

I though that we are just arguing that a better support for OO is needed not much is missing but we could use an OO lib. ( and Partial implementation of Interfaces as discussed in: D/24406 ) The entry object would require a subclass of a singleton or something like that. I'm not interested now in thinking if that a good idea or not. I'm sure the creators of the languages you refer thought about that obvious idea. For sure it's not used for pratical reasons. Ant PS sorry for my style of writting. it's result of my limitations with english.
Feb 22 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <c1amei$iou$1 digitaldaemon.com>, resistor mac.com says...
Also, I strongly suggest the phrase close-minded stop being thrown around.

You are right. The fact that we are in a new language group already shows that we are open minded. Ant
Feb 22 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c1aipb$cd8$1 digitaldaemon.com...
 In article <c1a2ki$2gko$1 digitaldaemon.com>, Matthew says...
It seemed odd to me also.

"Phill" <phill pacific.net.au> wrote in message
news:c19pq6$22d5$1 digitaldaemon.com...
 Is that someone trying to pass themselves off
 as "Ant" (antonio) ?
 I think he speaks(and spells) a lot better than that.


I'm sorry to say that you are wrong ;( (This shows you how difficult is to communicate on my second language, as soon as I'm a bit tired...)

Its ok , I find it difficult to communicate in my first language when im tired :o)) Your spelling doesnt bother me at all, it just felt to me that it was a different person, especially when, in the "from" field it had "And" instead of "Ant". Phill.
Feb 22 2004
prev sibling parent Juan C <Juan_member pathlink.com> writes:
Yes, that's my biggest gripe about C# as well. Would that decision be political
with a big or small P?

<snip>
In article <c19hc7$1h72$1 digitaldaemon.com>, resistor mac.com says...
Point in case: public static void main (String[] args)
There is no reason in the world why the main function should be part of a class.
It makes absolutely no sense, and completely breaks the idea of OO being used to
represent OBJECTS.

Feb 22 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 You just, stopped at reading the good part, features of C# that I want in

Which illustrates the point that you've just lost your audience.
 Did you look at those attachments, that asked for?

Not yet.
 My target isn't you anyway, it is Mr. Walter Bright.

Oh really? And do you think Walter went to the trouble of creating a language and initiaiting, and participating in, this newsgroup only to pay it no heed. I can tell you the NG has been most influential with Walter on a number of important issues: structs, deterministic destruction (which, btw, neither Java/.NET have, despite the specious pretense of the using keyword), etc. etc.
 I appologize for any spelling mistakes.

I have no problem with spelling mistakes. :)
  As for why I haven't backed some
 of points like OO vs. procedural, those have already been backed up all
 over the net.

You've failed to address the point, *again*. *You* state that D should go all OO, and yet *you* can offer no evidence to back up your assertion. That's like me ringing up the folks at MS and telling them that they're OS is crap. They might, perhaps, enquire as to why I would think that. Were I then to say, "well everyone thinks so", I expect I'd hear a little click, and that would be that.
 You have a right to state your opinion, just as I do.

Indeed. But if you want anyone to listen to your opinion, you'd better offer more than just opinion and statements. Offer proof. Back up what you say. If you can't/won't, then get off the pot. You're just wasting everyone's time.
 On Sun, 22 Feb 2004 16:27:48 +1100, Matthew <matthew.hat stlsoft.dot.org>
 wrote:

 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to


 your posts smack of the former, despite being individually presented as
 the
 latter

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

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the smartest people in the industry on this NG.
  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and


 P).

 Another aspect was, and I say this with some regret, to make programming
 more accessible to less competent people. I have witnessed this myself,
 whereby folks on C# and Java projects are happy to play with threads and
 other non-trivial concepts more than they would be in C/C++ because
 .NET/Java makes it easier for them to do so without making basic
 mistakes.
 However, the level of mistakes just moves to a higher level, evincing
 itself
 in bad design as opposed to broken code. To my mind, this barely
 represents
 a postive step.

 Writing software is the most complex activity man has undertaken. (It


 quoted at the time that the Win2K os was the most complex machine ever
 created.) Do we really want less-talented people to be doing it?

  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found OO

You used functions once. ROFL. Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments. It's like someone who only speaks, say, Italian, saying that Italian is the only language worth knowing. "Oh sure, I learned a few phrases in French once, but you can't say as much in French as you can in Italian".
 -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

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO


 superior, and I'm still waiting for you to offer some proof

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

I don't understand the point you're making here.
 -Becaues C\C++ have been arround for a lot of time, it doesn't mean



 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.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is an even balance between OO (including ADTs and runtime-polymorphism) and generics, with just a dash of procedural thrown in for good measure <ASIDE>C++ remains the best language at the moment because it ably supports *all* current programming paradigms (apart from functional, I guess, although some of the more abstruse meta techniques are moving in that direction). No other widely-used language can claim this, and the


 down attempts for generics in C# and Java are not going to come anywhere
 near allowing them to join the club. D aims to be the second one, and
 IMHO
 it stands a very good chance at doing so. If you would care to point out
 where this statement is wrong, I'll fry up my undies with a little extra
 virgin olive oil and eat them for dinner.</ASIDE>

 - D isn't perfect, but it can be close to perfect if you people think
 out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements. At this point I've exhausted my reserve of interest. Apologies if you have some good points further down. Cheers Matthew
 - 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



 extend the language using attributes.
    Attributes in D should have a better syntax to show that those



 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



 in dll format.  It is very anoying that you have to use the file



 - 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



 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



 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



 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



 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



 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();
 }


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

Feb 21 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c19isc$1kqp$1 digitaldaemon.com>, Matthew says...
*You* state that D should go all OO, and yet *you* can offer no evidence to
back up your assertion.

of course we all know that D already went OO. There is no need to go anywhere. it's already there. (D also supports procedural BTW) What's missing is a OO lib. let's end this non discussion. nothing new is being said. SpookyET made some suggestions, obviously before having the sufficient contact with D and - seems to me - out of the enthusiasm for D. He also seems to be quite focused on C#, to me sounds like a limitation, maybe it's not... Ant
Feb 21 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Ant wrote:
 In article <c19isc$1kqp$1 digitaldaemon.com>, Matthew says...
 
*You* state that D should go all OO, and yet *you* can offer no evidence to
back up your assertion.

of course we all know that D already went OO. There is no need to go anywhere. it's already there. (D also supports procedural BTW) What's missing is a OO lib. .. Ant

No, no! What's missing are functional (partially present) and dataflow. OTOH, successful dataflow implementations are quite rare. Perhaps Prograf is the most notable one, and I believe that it's defunct. There doesn't seem to be an easy way to linearize the code. (I.e., to make the code printable.) All the implementations seem to need graphic front-ends, which not only makes the development heavy, but also makes listings huge, and prevents one from seeing much code at once. Perhaps it's a mistake to try to make a language which is all things to all people. D may be near the optimum point for the current technology.
Mar 03 2004
parent reply "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Wed, 03 Mar 2004 09:53:51 -0800, Charles Hixson  
<charleshixsn earthlink.net> wrote:

 OTOH, successful dataflow implementations are quite rare.  Perhaps  
 Prograf is the most notable one, and I believe that it's defunct.

What's this Prograf about? Do you have a link? I tried googling but no success... -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Mar 05 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Robert M. Münch wrote:
 On Wed, 03 Mar 2004 09:53:51 -0800, Charles Hixson  
 <charleshixsn earthlink.net> wrote:
 
 OTOH, successful dataflow implementations are quite rare.  Perhaps  
 Prograf is the most notable one, and I believe that it's defunct.

What's this Prograf about? Do you have a link? I tried googling but no success...

from the Mac to MSWind. (I.e., years ago, possibly decades.) Dataflow seems to be something that it's quite difficult to make work properly, though when it does work it gives you an automatic parallelism that no other technique matches. It's as if, e.g., a for loop had no implicit order of operations, so separate iterations could be swapped out to every available processor. (Well, it only ran on a single processor system, so who knows how that would have worked out really, but it was quite impressive...but the [user] code was so bulky that it was quite difficult to use.) Sorry. No links. I may have an old set of Mac floppies for system 7.5 though...somewhere...and they might still be readable.
Mar 06 2004
parent reply "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Sat, 06 Mar 2004 10:30:49 -0800, Charles Hixson  
<charleshixsn earthlink.net> wrote:

 Dataflow seems to be something that it's quite difficult to make work  
 properly, though when it does work it gives you an automatic parallelism  
 that no other technique matches.  It's as if, e.g., a for loop had no  
 implicit order of operations, so separate iterations could be swapped  
 out to every available processor.  (Well, it only ran on a single  
 processor system, so who knows how that would have worked out really,  
 but it was quite impressive...but the [user] code was so bulky that it  
 was quite difficult to use.)

Hi, I know, I'm an inventor of a reconfigurable parallel processor that uses dataflow concepts. That's why I'm interested in this stuff. I have gone thru some ups & downs while developing a progamming system for this thing.
 Sorry.  No links.  I may have an old set of Mac floppies for system 7.5  
 though...somewhere...and they might still be readable.

What was it about? Was it a code generator, a compiler, a graphical editor? -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Mar 07 2004
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Robert M. Münch wrote:
 On Sat, 06 Mar 2004 10:30:49 -0800, Charles Hixson  
 <charleshixsn earthlink.net> wrote:
 
 Dataflow seems to be something that it's quite difficult to make work  
 properly, though when it does work it gives you an automatic 
 parallelism  that no other technique matches.  It's as if, e.g., a for 
 loop had no  implicit order of operations, so separate iterations 
 could be swapped  out to every available processor.  (Well, it only 
 ran on a single  processor system, so who knows how that would have 
 worked out really,  but it was quite impressive...but the [user] code 
 was so bulky that it  was quite difficult to use.)

Hi, I know, I'm an inventor of a reconfigurable parallel processor that uses dataflow concepts. That's why I'm interested in this stuff. I have gone thru some ups & downs while developing a progamming system for this thing.
 Sorry.  No links.  I may have an old set of Mac floppies for system 
 7.5  though...somewhere...and they might still be readable.

What was it about? Was it a code generator, a compiler, a graphical editor?

to virtual machine code. It included a graphic editor, in fact no non-graphic way was devised that could display the code. This probably contributes to its eventual failure. It came out of Canada (Labrador? Newfoundland?). I first encountered it in Datamation, either an article, a product anouncement, or an ad...unless I first encountered it at a show (ComputerWorld?) in San Francisco.
Mar 07 2004
parent larry cowan <larry_member pathlink.com> writes:
Try Google for 'dataflow mac' (no quotes).  It will bring up some old stuff, but
you will have to look at cached versions, because most of the original websites
aren't there anymore or don't still have the stuff.  That's a start -
probably other 'dataflow + xxxxx' searches will find more.  


In article <c2fvr9$2vs1$1 digitaldaemon.com>, Charles Hixson says...
Robert M. Münch wrote:
 On Sat, 06 Mar 2004 10:30:49 -0800, Charles Hixson  
 <charleshixsn earthlink.net> wrote:


 What was it about? Was it a code generator, a compiler, a graphical editor?
 

to virtual machine code. It included a graphic editor, in fact no non-graphic way was devised that could display the code. This probably contributes to its eventual failure. It came out of Canada (Labrador? Newfoundland?). I first encountered it in Datamation, either an article, a product anouncement, or an ad...unless I first encountered it at a show (ComputerWorld?) in San Francisco.

Mar 08 2004
prev sibling parent reply C <dont respond.com> writes:
 I can tell you the NG has been most influential with Walter on a numbe=

 of
 important issues: structs, deterministic destruction (which, btw, neit=

 Java/.NET have, despite the specious pretense of the using keyword), e=

 etc.

We have deterministic destruction ? C On Sun, 22 Feb 2004 17:40:39 +1100, Matthew <matthew.hat stlsoft.dot.org=
 =

wrote:
 You just, stopped at reading the good part, features of C# that I wan=


 in

Which illustrates the point that you've just lost your audience.
 Did you look at those attachments, that asked for?

Not yet.
 My target isn't you anyway, it is Mr. Walter Bright.

Oh really? And do you think Walter went to the trouble of creating a language and initiaiting, and participating in, this newsgroup only to=

 pay
 it no heed.

 I can tell you the NG has been most influential with Walter on a numbe=

 of
 important issues: structs, deterministic destruction (which, btw, neit=

 Java/.NET have, despite the specious pretense of the using keyword), e=

 etc.

 I appologize for any spelling mistakes.

I have no problem with spelling mistakes. :)
  As for why I haven't backed some
 of points like OO vs. procedural, those have already been backed up a=


 over the net.

You've failed to address the point, *again*. *You* state that D should go all OO, and yet *you* can offer no eviden=

 to
 back up your assertion.

 That's like me ringing up the folks at MS and telling them that they'r=

 OS
 is crap. They might, perhaps, enquire as to why I would think that. We=

 I
 then to say, "well everyone thinks so", I expect I'd hear a little cli=

 and that would be that.

 You have a right to state your opinion, just as I do.

Indeed. But if you want anyone to listen to your opinion, you'd better=

 offer
 more than just opinion and statements. Offer proof. Back up what you =

 say. If
 you can't/won't, then get off the pot. You're just wasting everyone's =

 time.


 On Sun, 22 Feb 2004 16:27:48 +1100, Matthew =


 <matthew.hat stlsoft.dot.org>
 wrote:

 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since=



 me
 your posts smack of the former, despite being individually presente=



 as
 the
 latter

 -I want D to succeed, because I want a native C# (since I don't kn=




 what
 mono is going to be, and it always is 2 years behind Microsoft).

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the =



 smartest
 people in the industry on this NG.

  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and=



 small
 P).

 Another aspect was, and I say this with some regret, to make =



 programming
 more accessible to less competent people. I have witnessed this =



 myself,
 whereby folks on C# and Java projects are happy to play with thread=



 and
 other non-trivial concepts more than they would be in C/C++ because=



 .NET/Java makes it easier for them to do so without making basic
 mistakes.
 However, the level of mistakes just moves to a higher level, evinci=



 itself
 in bad design as opposed to broken code. To my mind, this barely
 represents
 a postive step.

 Writing software is the most complex activity man has undertaken. (=



 was
 quoted at the time that the Win2K os was the most complex machine e=



 created.) Do we really want less-talented people to be doing it?

  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found O=




 better.

 You used functions once. ROFL.

 Seriously, do you have any idea how that sounds? You just cut the l=



 out
 from any of your arguments.

 It's like someone who only speaks, say, Italian, saying that Italia=



 is
 the
 only language worth knowing. "Oh sure, I learned a few phrases in =



 French
 once, but you can't say as much in French as you can in Italian".


 -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

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully gene=



 approach, or whatever. But you are clearly making the point that an=



 is
 superior, and I'm still waiting for you to offer some proof

 -In .NET you can have classes in dlls, D can have them too, no one=




 forcing you to use the dll format dictated by MS before .NET was
 arround.

I don't understand the point you're making here.
 -Becaues C\C++ have been arround for a lot of time, it doesn't mea=




 that
 it is the best thing and stuff should still be done like that (tha=




 is
 why
 D has been invented).  Most people use Internet Explorer, is that =




 best
 browser? No.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use o=



 these
 languages forces one to adopt an entirely procedural approach? None=



 those
 are true. I have written object-oriented code in C, and modern C++ =



 an
 even balance between OO (including ADTs and runtime-polymorphism) a=



 generics, with just a dash of procedural thrown in for good measure=



 <ASIDE>C++ remains the best language at the moment because it ably
 supports
 *all* current programming paradigms (apart from functional, I guess=



 although some of the more abstruse meta techniques are moving in th=



 direction). No other widely-used language can claim this, and the


 down attempts for generics in C# and Java are not going to come =



 anywhere
 near allowing them to join the club. D aims to be the second one, a=



 IMHO
 it stands a very good chance at doing so. If you would care to poin=



 out
 where this statement is wrong, I'll fry up my undies with a little =



 extra
 virgin olive oil and eat them for dinner.</ASIDE>

 - D isn't perfect, but it can be close to perfect if you people th=




 out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanke=



 statements.

 At this point I've exhausted my reserve of interest. Apologies if y=



 have
 some good points further down.

 Cheers

 Matthew



 - The delegate/event model of C# should be included in D because, =




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




 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 !=3D null)
                  stories[index] =3D value;
          }
      }
 }

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

 - Operator overloading: It is easier to use the operators instead =




 functions (eg: opAdd()) when overloding.

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

 - Attributes: Attributes are super cool and developers should be a=




 to
 extend the language using attributes.
    Attributes in D should have a better syntax to show that those



 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



 in dll format.  It is very anoying that you have to use the file



 - No header files (assemblies with meta data that support classes)=




 - No more dozens of lines of ugly code to include a dll dynamicall=




 take
 a look at the examples  Assembly.Load("mydll.dll"), use the classe=




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




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




 thing, it is just as worse (eg hard to load dlls, no classes, stil=




 libs,
 headerfiles. ).


 I have attached those files that were posted, even though they loo=




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




 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 =3D new
 DigitalPlay.FoobarClient.Client();
       // or shortcut it since i sayed using...
       Client foo =3D 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 m=




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




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




 a
 full plugin system.  This also shows you the power of .NET types a=




 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, da=




 it. D
 has potential, but you have to create a nice class library like .N=




 and
 stop doing the C-way of doing things. D, a 21st century language w=




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




 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 =




 files.

 - This is for now, I'll post anything else that I forgot some othe=




 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 =3D
 ((System.IEnumerable)(collection)).GetEnumerator();
     try {
     while (enumerator.MoveNext()) {
        ElementType element =3D (ElementType)enumerator.Current;
        statement;
     }
    }
 finally {
     IDisposable disposable =3D enumerator as System.IDisposable;
     if (disposable !=3D null) disposable.Dispose();
 }


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



-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
We do: the auto keyword (used on the class and the declaration)


"C" <dont respond.com> wrote in message news:opr3sxzwr7ehmtou localhost...
 I can tell you the NG has been most influential with Walter on a number
 of
 important issues: structs, deterministic destruction (which, btw, neither
 Java/.NET have, despite the specious pretense of the using keyword), etc.
 etc.

We have deterministic destruction ? C On Sun, 22 Feb 2004 17:40:39 +1100, Matthew <matthew.hat stlsoft.dot.org> wrote:
 You just, stopped at reading the good part, features of C# that I want
 in

Which illustrates the point that you've just lost your audience.
 Did you look at those attachments, that asked for?

Not yet.
 My target isn't you anyway, it is Mr. Walter Bright.

Oh really? And do you think Walter went to the trouble of creating a language and initiaiting, and participating in, this newsgroup only to pay it no heed. I can tell you the NG has been most influential with Walter on a number of important issues: structs, deterministic destruction (which, btw, neither Java/.NET have, despite the specious pretense of the using keyword), etc. etc.
 I appologize for any spelling mistakes.

I have no problem with spelling mistakes. :)
  As for why I haven't backed some
 of points like OO vs. procedural, those have already been backed up all
 over the net.

You've failed to address the point, *again*. *You* state that D should go all OO, and yet *you* can offer no evidence to back up your assertion. That's like me ringing up the folks at MS and telling them that they're OS is crap. They might, perhaps, enquire as to why I would think that. Were I then to say, "well everyone thinks so", I expect I'd hear a little click, and that would be that.
 You have a right to state your opinion, just as I do.

Indeed. But if you want anyone to listen to your opinion, you'd better offer more than just opinion and statements. Offer proof. Back up what you say. If you can't/won't, then get off the pot. You're just wasting everyone's time.
 On Sun, 22 Feb 2004 16:27:48 +1100, Matthew
 <matthew.hat stlsoft.dot.org>
 wrote:

 You don't understand me.

I think I(/we) do.
  I don't evangelize .NET; I evangelize some
 features of C#/.NET that should be in D.

If that is true, you need to rethink your presentation style, since to


 your posts smack of the former, despite being individually presented

 the
 latter

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

Good. Here's some common ground.
 -I want you people to think out of the box!

Don't be ridiculous, not to say insulting. You have some of the

 people in the industry on this NG.

  C# was done by people
 thinking out of the box.

That's partly true. Another aspect was political (with both big and


 P).

 Another aspect was, and I say this with some regret, to make

 more accessible to less competent people. I have witnessed this

 whereby folks on C# and Java projects are happy to play with threads

 other non-trivial concepts more than they would be in C/C++ because
 .NET/Java makes it easier for them to do so without making basic
 mistakes.
 However, the level of mistakes just moves to a higher level, evincing
 itself
 in bad design as opposed to broken code. To my mind, this barely
 represents
 a postive step.

 Writing software is the most complex activity man has undertaken. (It


 quoted at the time that the Win2K os was the most complex machine ever
 created.) Do we really want less-talented people to be doing it?

  D has functions, so for those that want to use
 functions, let them. -I like OO (used functions once), but found OO

You used functions once. ROFL. Seriously, do you have any idea how that sounds? You just cut the legs out from any of your arguments. It's like someone who only speaks, say, Italian, saying that Italian

 the
 only language worth knowing. "Oh sure, I learned a few phrases in

 once, but you can't say as much in French as you can in Italian".


 -I want D to have a library like delphi/.net has, full OO and


 based (modern design of class libraries). For C++ you have
 vcf.sourceforge.net

Can you explain why OO is better? I'm not saying a free-functions approach is better, or a fully generic approach, or whatever. But you are clearly making the point that an OO


 superior, and I'm still waiting for you to offer some proof

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

I don't understand the point you're making here.
 -Becaues C\C++ have been arround for a lot of time, it doesn't mean



 it is the best thing and stuff should still be done like that (that


 why
 D has been invented).  Most people use Internet Explorer, is that the
 best
 browser? No.

What has C/C++ got to do with anything? Are you saying that an OO approach cannot be supported by either of these languages, and/or that use of these languages forces one to adopt an entirely procedural approach? None of those are true. I have written object-oriented code in C, and modern C++ is

 even balance between OO (including ADTs and runtime-polymorphism) and
 generics, with just a dash of procedural thrown in for good measure

 <ASIDE>C++ remains the best language at the moment because it ably
 supports
 *all* current programming paradigms (apart from functional, I guess,
 although some of the more abstruse meta techniques are moving in that
 direction). No other widely-used language can claim this, and the


 down attempts for generics in C# and Java are not going to come

 near allowing them to join the club. D aims to be the second one, and
 IMHO
 it stands a very good chance at doing so. If you would care to point

 where this statement is wrong, I'll fry up my undies with a little

 virgin olive oil and eat them for dinner.</ASIDE>

 - D isn't perfect, but it can be close to perfect if you people think
 out
 of the box for a minute.

Again, you're being ridiculous, insulting and making fatuous blanket statements. At this point I've exhausted my reserve of interest. Apologies if you have some good points further down. Cheers Matthew
 - 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


 _var m_var and other types of decoration.
 - Indexers are cool since they allow you to use a class/struct like


 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



 extend the language using attributes.
    Attributes in D should have a better syntax to show that those



 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


 they made it. So D should have them too.
 - Namespaces and strong named assemblies (with metadata about the



 in dll format.  It is very anoying that you have to use the file



 - 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


 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


 is
 another cool thing that another language has that isn't in C#,


 it
 too. But C# is perfect in a lot of ways.  Right now D is doing it


 way.
 - You can't build apps as fast in C++/C/D as you can do in .NET with



 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.


 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



 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


 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


 full plugin system.  This also shows you the power of .NET types and



 they describe themselves.  If you do this crap the same as it has


 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



 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



 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


 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();
 }


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


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
SpookyET wrote:

 My target isn't you anyway, it is Mr. Walter Bright.

Matthew is like this groups bouncer (except he can't kick anyone out). He knows what he's talking about. -- -Anderson: http://badmama.com.au/~anderson/
Feb 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c19n52$1rnd$1 digitaldaemon.com...
 SpookyET wrote:

 My target isn't you anyway, it is Mr. Walter Bright.

Matthew is like this groups bouncer (except he can't kick anyone out).

He he. :)
 He knows what he's talking about.

I think you must've mistaken me for someone else. ;)
Feb 22 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

Matthew is like this groups bouncer (except he can't kick anyone out).
    

He he. :)
He knows what he's talking about.
    

I think you must've mistaken me for someone else. ;)

about <g> -- -Anderson: http://badmama.com.au/~anderson/
Feb 22 2004
prev sibling next sibling parent Luke D <Luke_member pathlink.com> writes:
inline

Sorry about the long post, I'm just getting pretty annoyed by this (I've tried
to stay as calm as possible though.)

In article <opr3qywfq71s9n15 saturn>, SpookyET says...
------------X6GdKj0MKFEpsdf1V7BNYF
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 8bit

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

D isn't C#; it never will be
-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.

OO is a way of thinking, not a way of writing, you can write "OO" code without an OO-languge. Also, generic and functional code is often more reusable than OO code.
-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

It probably will in time. C# was made by a company that gave its employees a clear goal. Walter has no control over what the programmers working with/on D write, so D won't have such an extensive library immediately. Also, it probably won't be as object based because of the reusability factor.
-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.

Net however doesn't use true dll's. If D would make its own dll format, it probably wouldn't be usable by many other languages. Also, the language isn't Windows specific, and library format is operating system dependant.
-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.

I'd like to think that programs are more informed than the average computer user. :p but I know this is often not true.
- D isn't perfect, but it can be close to perfect if you people think out  
of the box for a minute.

Isn't that the point of making a new programming language: to think outside the box? If I'm not mistaken, the D community is based on thinking outside the box. Copying another language's features without good reason however is not thinking outside the box.
- The delegate/event model of C# should be included in D because, it makes  
it very easy to work with event based programming.

People are already working on modules that have similar functinality. C++ has the functionality too btw. And its really not as common a feature as C# would have you believe so why bloat the core language with something that should really be part of the library?
- Methods/Properties should be PascalCase, it doesn't force you to use  
_var m_var and other types of decoration.

What's your point? No one's forcing you to name your identifiers a certain way.
- Indexers are cool since they allow you to use a class/struct like an  
array:

D has this already. Only it's not called an indexer; it's just overloading the [] operator. (Whoever came up with indexers anyway? It's nothing different than overloading the [] operator. The way you overload the [] operator and the way foreach is done (both syntax and adding functionality to a class) are two things inconsistant with the rest of the C# language. They just seem horribly ugly and not well thought out to me.)
- Operator overloading: It is easier to use the operators instead of  
functions (eg: opAdd()) when overloding.

opX() is easier to parse for the compiler. It makes it a lot easier to write a D compiler.
- Attributes: Attributes are super cool and developers should be able to  
extend the language using attributes.

With my short use of C#, it seemed like attributes were nothing more than a workaround because C# doesn't have multiple inheritence and it didn't have templates. While D doesn't have multiple inheritence, it has extensive templates, and they seem to remove any need for the C# attributes.
- C# has nailed a lot of good stuff, they looked at many languages when  
they made it. So D should have them too.

In other words, you're saying that C# and D took many of the same things into consideration as both C# and D looked at other languages. D however has another added advantage of being able to look at C# as well. D also has a much different goal in mind than C# did, so the things the makers of C# looked for might be different than what the makers of D look for.
- 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.

I actually agree with you about the file system thing, but I understand its reason for the most part.
- 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. ).

Have you tried it much? It's really not complicated at all. I hear the same thing about how much harder something is to do and how it makes it not worth it from many Mac users (who, because of Macs' ease of use, are completely lost when everything isn't presented directly to them) And easy doesn't always mean good. Look at VB compared to C++.
Feb 21 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
SpookyET wrote:
 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:
 ...

I got it, I got it! MS found about D and they sent SpookyET here to put C# over! jk, btw ----------------------- Carlos Santander Bernal
Feb 26 2004
parent C <dont respond.com> writes:
 I got it, I got it! MS found about D and they sent SpookyET here to pu=

 C# over!

I thought it smelled like sabotage\conspiracy ;) On Thu, 26 Feb 2004 21:56:50 -0500, Carlos Santander B. = <carlos8294 msn.com> wrote:
 SpookyET wrote:
 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:
 ...

I got it, I got it! MS found about D and they sent SpookyET here to pu=

 C#
 over!
 jk, btw

 -----------------------
 Carlos Santander Bernal

-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mar 01 2004
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
Just some comments.

SpookyET wrote:
 -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.

But many times you'll want to interact with other languages/tools, and if D starts to use a different dll format, it won't be able to "talk" with those other tools. Take a look at my Apollo library (cheap plug, btw) at http://earth.prohosting.com/carlos3/Apollo.htm: the actual code is in Delphi, compiled in a dll, but it's used in D. If there was no standard dll format, that'd be impossible. Now, if there was also a standard lib format, that'd be awesome because Apollo could be statically linked if desired.
 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.

Sorry, there's nothing perfect in this universe.
 - 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. ).

Write some tool that helps D development faster. ----------------------- Carlos Santander Bernal
Feb 26 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
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

 be read. Just post a .CS, and we can read it (with highlighting, etc.) in

 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

 languages. I personnally tend to loose the capacity to listen to people

 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

 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,

 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

 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

 machine, using the recls .NET mapping (http://recls.org/), of course <g>.
 2.    I'm currently using Python to write some management utilities to

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

 <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

 think outside the constraints of one's mental box. For my part, I spent

 many years thinking entirely in C and C++ - the only languages I'm

 in - but I am thankful that I've evolved to become at least journeyman

 in C#, D, Java, Perl, Python and (with much chagrin) VB. This means that

 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

 be done in a fraction of the time it would take in C/C++/C#/Java. And so

 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

 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

 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

 my own shell extension templates. Out of interest I translated one to

 and it took vastly more time and LOCs.

 D is far from perfect, and there's plenty of scope for informed

 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

 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

 the challenge and implement some of the things you want to see; you might

 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

 the truth, it's that you're wrong.

 C# is indeed great for some things, but not for others. As for D. As for

 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

 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


 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,


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


 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


 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>


 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,




 is why visual  studio has intellisense, so when you type obj. (it




 all the  properties/methods/fields etc after the dot and




 that you put  in the source code about each argument).  It can be




 the same in D.

Yes, without changing anything. Runtime parsing is a good solution



 D, while it was not possible with most languages so far.

 As for the DLLs, that works for functions, but what about Classes?




 what about latebinding? loading dlls at startup (plugins).

Late binding is always late. ;> DLLs cannot legally export classes,



 can only export functions, but you can make such a function create a
 class. Someone was planning on a plug-in system implemented using



 facilities. It would use LoadLibrary and GetProcAdress from Windows,



   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



 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



 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




 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



 -eye

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


Feb 21 2004
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
SpookyET wrote:
 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.

 ... [code] ...

 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.

 ... [more code] ...

I will repeat what others have said: try to get those things done in D. You'll learn D and when they're done, you'll be able to use them just like you would in C#. Even better, by doing them, you'll discover that D has other ways to do the same, or similar but better, or ... ----------------------- Carlos Santander Bernal
Feb 26 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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

Feb 21 2004
parent reply Stephan Wienczny <wienczny web.de> writes:
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
Feb 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
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


 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

Feb 21 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
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
Feb 21 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
SpookyET wrote:
...
 D needs a bool type

If you really want to discuss this, I would invite you to review some of the former points to ensure that you don't simply re-hash all of the old arguments: http://www.wikiservice.at/d/wiki.cgi?BooleanNotEquBit The list at the bottom of the wiki page is mostly initial posts in the threads, so you can navigate in the thread by using the Prev and Next buttons at the top and bottom of the post pages. Many aspects of bit vs. bool have been discussed at length. The bit type already works fine for me, but Walter's one you need worry about convincing, so you might want to pay particular attention to his comments. -- Justin http://jcc_7.tripod.com/d/
Feb 20 2004
prev sibling next sibling parent reply The Lone Haranguer <The_member pathlink.com> writes:
Stick with C#, like I am.

In article <opr3o04lk11s9n15 saturn>, SpookyET says...
Damn, D needs a bool type, and a string type. yeah you got a nice char[]  
but you still need to do string manipulation, so a string class is still  
needed for string.format(), string.split(), string.toUppercase() and stuff  
like that.  Might just well create the string type in the language. This  
is string in .NET  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemstringmemberstopic.asp

The types are under the System namespace.

Actually, thinking about it, there is no point in poluting the language  
with a lot of crap, you always need extensions so a good class library  
like the .net framework is better. do you really need associative arrays?  
You can have a class for that, and a string class and so on, and have  
"string" as an alias, just like the .net languages.  C# and other .net  
langs are just eye candy to MSIL (Microsoft Intermediate Language  
(assembler)).
System.Char (char) C#
System.String (string)
System.Int32 (int)
System.Int16 (short) and so on

The way the class library is designed in .NET (ripoff of Delphi's but  
better) is super cool. The best way is to create something like that,  
instead of creating all this ununited modules...

I'm thinking about making System.Console for console input output, but i  
haven't figured out how to access user32.dll from D yet.
There is no point in messing with printf and other old school stuff.

We need namespaces in D. What do you do if in 2 packages you have a class  
with the same name? Components based programming with namespaces is the  
best thing!

System.Console.WriteLine("Foobar");...

Feb 20 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
C wrote:
 Posted by: The Lone Haranguer - August 1, 2003 (19:35)
 

 
 Youll forgive me if I dismiss everything you say as trash.

I think we might want to step back and put this discussion into perspective. I don't know C#, but if someone who is a fan of C# is inspired into giving us an idea for D then that's a good thing. By the way, if a C# fan wants D to turned into a native compiled version of C#, they're probably going to be disappointed (and they're probably wasting everyone's time including their own). On the other hand, if a person likes to write succinct messages (possibly to inflame our anger, possibly to goad us into writing nasty messages), it's more efficient to simply ignore that person.
 
 C

Justin http://jcc_7.tripod.com/d/
Feb 20 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
C wrote:
 Posted by: The Lone Haranguer - August 1, 2003 (19:35)

I wonder whether it's April coming too late almost by a year or just a couple of months too early? -eye
Feb 21 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
You should take a look at this URL:

http://www.digitalmars.com/d/

and for the string stuff, I reckon you should visit this URL:

http://www.digitalmars.com/d/phobos.html

Then click on the link :
std.string

You will find that almost everything you need(for strings) is represented
here and the ones that arent, are easily doable by using the functions that
are here, and making some adjustments.

Phill.
Feb 20 2004