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

The types are under the System namespace.

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

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

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

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

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

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

object module from Phobos is always implicitly imported. It contains the definition of bool, which is an alias to bit. And please, don't start a new discussion on whether it's good or bad, it's been talked to death. And current solution works well and everyone is more or less happy.

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

What do you mean by uninited modules???? They can be grouped. I don't know anything about C#, but i know C++ and its system of namespaces is a major trouble for every building process. And i know the Java system of packages, but D's modules are an extension of it.

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

When writing a console library, potability is a major consern. *please* use the C standard library or the already defined Phobos parts as the back-end. Or is there anything which you want in your library which cannot be done upon these? Besides, take a look at the libraries already written by Carlos and Vathix and others. You find them all at the Wiki.

BTW, module names should be lowercase, to alleviate for filesystem issues and to avoid collision with class names.

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

There is no problem. If you have:

import a;
import b; //both ambiguously define callMe()

int main(){
    callMe(); //Ambiguous!
    a.callMe(); //OK!
    b.callMe(); //OK!
    return 0;
}

The advantage is that a build system can determine all files to participate in compilation from the header part of the unit.

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

This is possible already, like i've shown.

Reading documentation really helps. ;)

-eye

That is why I like namespaces, you can name them however you want since they have nothing to do with the file system.

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

So consider this:

namespace MyCompany.MyProduct
{
  using System;

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

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

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

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

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

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

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

> SpookyET wrote:
>> Damn, D needs a bool type, and a string type. yeah you got a nice char[]  but you still need to do string manipulation, so a string class is still  needed for string.format(), string.split(), string.toUppercase() and stuff  like that.  Might just well create the string type in the language. This  is string in .NET  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemstringmemberstopic.asp
>
> object module from Phobos is always implicitly imported. It contains the definition of bool, which is an alias to bit. And please, don't start a new discussion on whether it's good or bad, it's been talked to death. And current solution works well and everyone is more or less happy.
>
>> The way the class library is designed in .NET (ripoff of Delphi's but  better) is super cool. The best way is to create something like that,  instead of creating all this ununited modules...
>
> What do you mean by uninited modules???? They can be grouped. I don't know anything about C#, but i know C++ and its system of namespaces is a major trouble for every building process. And i know the Java system of packages, but D's modules are an extension of it.
>
>> I'm thinking about making System.Console for console input output, but i  haven't figured out how to access user32.dll from D yet.
>> There is no point in messing with printf and other old school stuff.
>
> When writing a console library, potability is a major consern. *please* use the C standard library or the already defined Phobos parts as the back-end. Or is there anything which you want in your library which cannot be done upon these? Besides, take a look at the libraries already written by Carlos and Vathix and others. You find them all at the Wiki.
>
> BTW, module names should be lowercase, to alleviate for filesystem issues and to avoid collision with class names.
>
>> We need namespaces in D. What do you do if in 2 packages you have a class  with the same name? Components based programming with namespaces is the  best thing!
>
> There is no problem. If you have:
>
> import a;
> import b; //both ambiguously define callMe()
>
> int main(){
>      callMe(); //Ambiguous!
>      a.callMe(); //OK!
>      b.callMe(); //OK!
>      return 0;
> }
>
> The advantage is that a build system can determine all files to participate in compilation from the header part of the unit.
>
>> System.Console.WriteLine("Foobar");...
>
> This is possible already, like i've shown.
>
> Reading documentation really helps. ;)
>
> -eye
>



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

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/

Stick with C#, like I am.

In article <opr3o04lk11s9n15@saturn>, SpookyET says...
>
>Damn, D needs a bool type, and a string type. yeah you got a nice char[] but you still need to do string manipulation, so a string class is still needed for string.format(), string.split(), string.toUppercase() and stuff like that.  Might just well create the string type in the language. This is string in .NET http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemstringmemberstopic.asp
>
>The types are under the System namespace.
>
>Actually, thinking about it, there is no point in poluting the language
>with a lot of crap, you always need extensions so a good class library
>like the .net framework is better. do you really need associative arrays?
>You can have a class for that, and a string class and so on, and have
>"string" as an alias, just like the .net languages.  C# and other .net
>langs are just eye candy to MSIL (Microsoft Intermediate Language
>(assembler)).
>System.Char (char) C#
>System.String (string)
>System.Int32 (int)
>System.Int16 (short) and so on
>
>The way the class library is designed in .NET (ripoff of Delphi's but better) is super cool. The best way is to create something like that, instead of creating all this ununited modules...
>
>I'm thinking about making System.Console for console input output, but i
>haven't figured out how to access user32.dll from D yet.
>There is no point in messing with printf and other old school stuff.
>
>We need namespaces in D. What do you do if in 2 packages you have a class with the same name? Components based programming with namespaces is the best thing!
>
>System.Console.WriteLine("Foobar");...

C wrote:
> Posted by: The Lone Haranguer - August 1, 2003 (19:35)
> 
[...]
> 
> Youll forgive me if I dismiss everything you say as trash.


I think we might want to step back and put this discussion into perspective.

I don't know C#, but if someone who is a fan of C# is inspired into giving us an idea for D then that's a good thing. By the way, if a C# fan wants D to turned into a native compiled version of C#, they're probably going to be disappointed (and they're probably wasting everyone's time including their own).

On the other hand, if a person likes to write succinct messages (possibly to inflame our anger, possibly to goad us into writing nasty messages), it's more efficient to simply ignore that person.

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

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.

SpookyET wrote:

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

The thing is, Net uses a sort of intermediate representation. Since we don't want to force any databases or intermediate representations on our language, it would not be feasible to requiere separation between file structure and module hirarchy. Besides, i still fail to see any limitations of the current system. You can easily create shortcuts/links.

We have digc (the dig compiler), the perfect example of a to-be build system. You only specify the root file of your application which contains main, and it recursively determines all modules which have to be built and builds them! Is anything like that possible with C#?

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

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

HUH? You still don't understand? Learn to use DLLs from C, man! It's the same with D.

In D you write, if this is a Windows DLL:

extern(Windows) int function(int foo);

This gives you a prototype. Its difference from a normal prototype is exactly this extern(Windows) which specifies a calling convention. BTW, you can group these extern to have less to type.

Then, it is up to linker to find where you are importing this from. For that, when you want to import from mylib.dll, you must link with mylib.lib, which in turn you can create from a DLL using implib utility. This lib is only a stub library which contains "tails" by which Windows exe loader connects the executable to an actual DLL.

-eye

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

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/