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  

langs are just eye candy to MSIL (Microsoft Intermediate Language  
(assembler)).

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 

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  


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



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  

 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 



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 







 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.


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:


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


<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


fraction of the time it would take me in C++. The detabification scripts can

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

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

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


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/



begin 666 dirdiff-detabified.d



M97)E;F-E(%5T:6QI='E<;EQN("!54T%'13H 9&ER9&EF9B \9&ER,3X 6SQD
M:7(R/EU<;EQN("!,:7-T<R!T:&4 9FEL92!I;B \9&ER,3X ;F]T(&EN(#QD


M<F5C;'-?="  ("!H4W)C:#L-"B  ("!R96-L<U]R8U]T("!R8R  /2  (%-E


M>PT*("  ("  ("!P<FEN=&8H(E-E87)C:"!F86EL960Z("4N*G-<;B(L(%-E


M9F]R*#L

M:&%R6UT (&9I;&5.86UE("  (#T ("!396%R8VA?1V5T16YT<GE&:6QE*&5N
M=')Y*3L-"B  ("  ("  ("  (&-H87);72  9FEL95!A=&  ("  /2  (%-E

M9FEL94YA;65=(#T



M87)G<RYL96YG=&  /" R*0T*("  ('L-"B  ("  ("  =7-A9V4H*3L-"B  




M("!C:&%R6UU;8VAA<EM=72  ;6%P,B  (" ]("  ;6%P7V1I<BAP871H,BD[

M:&5S92P 86YD('-E92 -"B  ("  ("  <')I;G1F*")&:6QE<R!O;FQY(&EN


M:V5Y<RD-"B  ("  ("  >PT*("  ("  ("  ("  :68H(2AF:6QE,2!I;B!M
M87 R*2D-"B  ("  ("  ("  ('L-"B  ("  ("  ("  ("  ("!P<FEN=&8H

M=#L-"B  ("  ("  ("  ('T-"B  ("  ("  ?0T*("  ("  ("!I9B P("$]

M;&4H<RD 9F]U;F1<;B(L(&-O=6YT*3L-"B  ("  ("  ?0T*("  ('T-" T*
2("  (')E='5R;B P.PT*?0T*
`
end
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 http://www.digitalmars.com/drn-bin/wwwnews?D/24356.

That said, I agree completely with the other 95% of your post. Spooky is 


-- 
Justin
http://jcc_7.tripod.com/d/
Feb 21 2004
prev sibling next sibling parent reply SpookyET <not4_u hotmail.com> writes:
You don't understand me.  I don't evangelize .NET; I evangelize some  


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

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.

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  

MyAttribute is a class and you can have [MyAttribute(argument1, argument2,  
argument3)]
class MyAttribute : FoobarAttribute
{
   // extend it
}

[MyAttribute()]
  expression


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  

Language Reference.  All that cool stuff should be included.  If there is  


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.

features to be in D.

   foreach (int i, char c; a)
   { ]



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


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.


</snip>

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



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



 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.



 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,

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


better.

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

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





 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

 MyAttribute is a class and you can have [MyAttribute(argument1, argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression


 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

 Language Reference.  All that cool stuff should be included.  If there is


 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.

 features to be in D.

    foreach (int i, char c; a)
    { ]



    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:

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



 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



 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.



 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,

 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


 better.

 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

 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





 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

 MyAttribute is a class and you can have [MyAttribute(argument1,  
 argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression


 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

 Language Reference.  All that cool stuff should be included.  If there  
 is

 it

 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.


 features to be in D.

 instead:
    foreach (int i, char c; a)
    { ]



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


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



 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



 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.



 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,

 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


 better.

 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

 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





 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

 MyAttribute is a class and you can have [MyAttribute(argument1,  
 argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression


 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

 Language Reference.  All that cool stuff should be included.  If there  
 is

 it

 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.


 features to be in D.

 instead:
    foreach (int i, char c; a)
    { ]



    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




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






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

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

 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

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:
  http://www.digitalmars.com/drn-bin/wwwnews?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:

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.


</snip>
Feb 22 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:



D.

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



 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



 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.



 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,

 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


 better.

 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


 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





 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


 MyAttribute is a class and you can have [MyAttribute(argument1,
 argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression


 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

 Language Reference.  All that cool stuff should be included.  If there
 is

 it

 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.


 features to be in D.

 instead:
    foreach (int i, char c; a)
    { ]



    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

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


I think that they've gone out of business while attempting to transition 
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?
 


It was a program development system on the Mac.  It compiled, probably 
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?
 


It was a program development system on the Mac.  It compiled, probably 
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=


r =


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


her

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


tc.

 etc.


We have deterministic destruction ?

C


On Sun, 22 Feb 2004 17:40:39 +1100, Matthew <matthew.hat stlsoft.dot.org=

 =


wrote:







t =


 in


 D.

 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=


r =


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


her

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


tc.

 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=




ll

 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=


ce =


 to
 back up your assertion.

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


e =


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


re =


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


ck,

 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



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






 to

 me

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






d =


 as

 the
 latter











ow

 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.



 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,








s =


 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=






ng

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






ver

 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=








O

 better.

 You used functions once. ROFL.

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






egs

 out
 from any of your arguments.

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






n =


 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=






ric

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








n

 that

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








t =


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






f

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






nd

 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=






at

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




 watered









 anywhere

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






nd

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






t =


 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=








ink

 out
 of the box for a minute.


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






t

 statements.

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






ou

 have
 some good points further down.

 Cheers

 Matthew













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








e =


 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 =








of

 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=








ble

 to

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






 things


 MyAttribute is a class and you can have [MyAttribute(argument1,
 argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression










 =


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








y,

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








s =


 in

 it
 with no problem.  A framework like that would be super cool in D.
 - Take a look at this article










 Language Reference.  All that cool stuff should be included.  If =









 there

 is










 included

 it










 the C

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








th

 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=








ary

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








l,

 libs,
 headerfiles. ).


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








k

 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=








an

 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=








ore

 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=








ll)

 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=








ou =


 a

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








nd

 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=








mn

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








ET

 and

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








ith

 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=








pe

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








r

 time.









 =


 want


 features to be in D.

 instead:
    foreach (int i, char c; a)
    { ]



    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=




2/




-- =

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:



 in


 D.

 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



 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



 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.



 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,




 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


 better.

 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




 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





 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


 MyAttribute is a class and you can have [MyAttribute(argument1,
 argument2,
 argument3)]
 class MyAttribute : FoobarAttribute
 {
    // extend it
 }

 [MyAttribute()]
   expression






 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

 Language Reference.  All that cool stuff should be included.  If




 there

 is





 included

 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.





 want


 features to be in D.

 instead:
    foreach (int i, char c; a)
    { ]



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


If people are going to buy your book you'd better know what your talking 
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


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






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



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.



it very easy to work with event based programming.


People are already working on modules that have similar functinality.  C++ has

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

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.




templates.  While D doesn't have multiple inheritence, it has extensive




they made it. So D should have them too.






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


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

 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.

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



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=


t =





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


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






 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.

 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=


t =



 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

 Language Reference.  All that cool stuff should be included.  If
 there is another cool thing that another language has that isn't in

 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


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.


 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:




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




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




the


 fraction of the time it would take me in C++. The detabification scripts


can




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




 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



hear

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




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



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

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




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



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:




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  

langs are just eye candy to MSIL (Microsoft Intermediate Language  
(assembler)).

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.




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