private string foobar;

public string Foobar
{
get
{
return foobar;
}
set
{
foobar = value;
}
}

If you don't have get, the property is write only.
If you don't have set, the property is read only

Dude, get rid of the package crap, namespaces are better. In C#

using System;

namespace Foobar
{
public class HelloWorld
{
public static void Main()
{
// If you don't put using System you have
// to type System.Console.WriteLine("Hello World!");
Console.WriteLine("Hello World!");
}
}
}

To compile you have to csc.exe hello.cs /resources:System.dll
No package crap, no includes no nothing.
It searches the resources for that namespace and converts Console to
System.Console. D looks promissing but please use namespaces.

Alot of the functions in the windows World are MyFunction instead of myFunction,
it would have been better if you would use obj.MyFunction(), it is easier to
read.
enum Foobar
{
Value1,
Value 2,
}

I still don't get the point in keeping the char crap instead of a type "string" like in the most modern languages.  You can create an Interface to C that converts strings to char arrays and char arrays back to string like the .NET framework has.

String foobar = "tododododod";
foobar.Length gives me the the length;
StringBuilder type class would be better though.
You shoul't make the language so complicated, and bloated.
a Hashtable class for key->value stuff is much bette rthan having that built in
into arrays.
Hashtable foobar = new Hashtable()

foobar.Add(key, value); key can be any type, value can be any type
foobar[key] returns value
haven't made up my mind about the foobar[2..3] stuff, looks weird

SpookyET wrote:

>private string foobar;
>
>public string Foobar
>{
>get
>{
>return foobar;
>}
>set
>{
>foobar = value;
>}
>}
>
>  
>

In D that would be:


public:

char[] Foobar()
{
  return foobar;
}

char[] Foobar(char[] value)
{
  return foobar = value;
}

private:
string foobar;


Hay, it's smaller!

>If you don't have get, the property is write only.
>If you don't have set, the property is read only
>  
>
This is supported.

-- 
-Anderson: http://badmama.com.au/~anderson/

.. and 'D' should be spelled 'C', right?

"SpookyET" <SpookyET_member@pathlink.com> wrote in message news:c15i6u$1si$1@digitaldaemon.com...
> private string foobar;
>
> public string Foobar
> {
> get
> {
> return foobar;
> }
> set
> {
> foobar = value;
> }
> }
>
> If you don't have get, the property is write only.
> If you don't have set, the property is read only
>
> Dude, get rid of the package crap, namespaces are better. In C#
>
> using System;
>
> namespace Foobar
> {
> public class HelloWorld
> {
> public static void Main()
> {
> // If you don't put using System you have
> // to type System.Console.WriteLine("Hello World!");
> Console.WriteLine("Hello World!");
> }
> }
> }
> To compile you have to csc.exe hello.cs /resources:System.dll
> No package crap, no includes no nothing.
> It searches the resources for that namespace and converts Console to
> System.Console. D looks promissing but please use namespaces.

Dude, the same thing works in D but replace "using" with "import" and
remove the "namespace Foobar" block.
Also, in D they are called "modules", not "packages".

>
> Alot of the functions in the windows World are MyFunction instead of
myFunction,
> it would have been better if you would use obj.MyFunction(), it is easier
to
> read.
> enum Foobar
> {
> Value1,
> Value 2,
> }

You are free to use whatever naming scheme you like. I don't even think the phobos library adheres to the style guidelines described in the D web pages (that might not be true any more, though).

> I still don't get the point in keeping the char crap instead of a type
"string"

Why invent a class when an array of char is a better model? Strings are
just a special kind of array - very natural and no extra class to
learn/worry
about.

> like in the most modern languages.  You can create an Interface to C that converts strings to char arrays and char arrays back to string like the
.NET
> framework has.
>
> String foobar = "tododododod";
> foobar.Length gives me the the length;

D arrays have a length property, so this is the same.

> StringBuilder type class would be better though.

Not needed with D. Arrays are mutable.

> You shoul't make the language so complicated, and bloated.

<rolls eyes>

> a Hashtable class for key->value stuff is much bette rthan having that
built in
> into arrays.

ever used perl or python? They have "easy to use" hashtables (ie - built in)
and
it makes a big difference.

> Hashtable foobar = new Hashtable()
>
> foobar.Add(key, value); key can be any type, value can be any type
> foobar[key] returns value
> haven't made up my mind about the foobar[2..3] stuff, looks weird

well, my advice is keep an open mind. I hope you find D useful.

-Ben

The reason why i said that myMethod should be MyMethod and the same for properties is this:

class Demo
{
   public int numbers;

   public int Numbers
   {
     get { return numbers; }
     set { numbers = value; }
   }
}

Having methods/properties named in lowercase forces you to name your variables to
ugly naming styles like _var m_var var_.

class Demo
{
   public int _numbers;

   public int numbers
   {
     get { return _numbers; }
     set { _numbers = value; }
   }
}

I still think that the properties style of C# is cleaner than having 2 methods.
What the language needs is indexers (makes classes/structs behave like arrays) and builtin support for events.
Events are basically delegates but with some restrictions. It forces you to use +/- to add event handlers.
foo.MyEvent += new EventHandler(method);

The reason for that is that if you do this (delegate style):
foo.MyEfnet = new EventHandler(method)
It deletes whatever event handlers you had before.

I'm not sure, but does D allow supports multicast delegates (delegates that point to more than one function)?

I would also like the D compiler to let you point where main is
instead of

void main(char[][] args)
{
	Application.Main(args);
}

class Application
{
  public static void Main(char args[][])
  {
    // my app code
  }
}

I'd like to say to the compiler that the entry point is Application.Main to get rid of no OO code.

Also a module is a package, it forces you to make folders/subfolders.....


On Fri, 20 Feb 2004 18:04:14 +0000 (UTC), SpookyET <SpookyET_member@pathlink.com> wrote:

> private string foobar;
>
> public string Foobar
> {
> get
> {
> return foobar;
> }
> set
> {
> foobar = value;
> }
> }
>
> If you don't have get, the property is write only.
> If you don't have set, the property is read only
>
> Dude, get rid of the package crap, namespaces are better.
> In C#
>
> using System;
>
> namespace Foobar
> {
> public class HelloWorld
> {
> public static void Main()
> {
> // If you don't put using System you have
> // to type System.Console.WriteLine("Hello World!");
> Console.WriteLine("Hello World!");
> }
> }
> }
>
> To compile you have to csc.exe hello.cs /resources:System.dll
> No package crap, no includes no nothing.
> It searches the resources for that namespace and converts Console to
> System.Console. D looks promissing but please use namespaces.
>
> Alot of the functions in the windows World are MyFunction instead of myFunction,
> it would have been better if you would use obj.MyFunction(), it is easier to
> read.
> enum Foobar
> {
> Value1,
> Value 2,
> }
>
> I still don't get the point in keeping the char crap instead of a type "string"
> like in the most modern languages.  You can create an Interface to C that
> converts strings to char arrays and char arrays back to string like the .NET
> framework has.
>
> String foobar = "tododododod";
> foobar.Length gives me the the length;
> StringBuilder type class would be better though.
> You shoul't make the language so complicated, and bloated.
> a Hashtable class for key->value stuff is much bette rthan having that built in
> into arrays.
> Hashtable foobar = new Hashtable()
>
> foobar.Add(key, value); key can be any type, value can be any type
> foobar[key] returns value
> haven't made up my mind about the foobar[2..3] stuff, looks weird
>
>



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

SpookyET wrote:

> The reason why i said that myMethod should be MyMethod and the same for properties is this:

Then name your methods as MyMethod.  The only advantage that I see the C# method having is name sharing.  Though that may be "cleaner", most people will see it as a minor gripe, as D provides the same methods for providing controlled access to private members.

class Demo {
   private int numbers;

   public int Numbers() { return numbers; }
   public void Numbers(int numbers) { this.numbers = numbers; }
}

What's so hard or different about this, besides the extra name?  Though, I suppose it would be possible for overloadInsert to share a name with a member variable, does it really need to be done?  After all, D is not a C# clone...

> I still think that the properties style of C# is cleaner than having 2
> methods.
> What the language needs is indexers (makes classes/structs behave like
> arrays) and builtin support for events.
> Events are basically delegates but with some restrictions. It forces you
> to use +/- to add event handlers.
> foo.MyEvent += new EventHandler(method);
> 
> The reason for that is that if you do this (delegate style):
> foo.MyEfnet = new EventHandler(method)
> It deletes whatever event handlers you had before.

This syntax is confusing and misleading.  Why use the +/-/= operators to add event handlers?  What's wrong with using a member function?  It should be a safe assumption that overloading the = operator will change something, not add something to a list.  I don't think operator overloads should be used for non-mathematical functions (except perhaps opCall), doing so makes code harder to read.

> I would also like the D compiler to let you point where main is instead of
> 
> void main(char[][] args)
> {
> Application.Main(args);
> }
> 
> class Application
> {
>    public static void Main(char args[][])
>    {
>      // my app code
>    }
> }
> 
> I'd like to say to the compiler that the entry point is Application.Main to get rid of no OO code.
> 

You would like to propose a change in the compiler to prevent you writing 4 lines of code?  D is not a pure-OO language, and D is not Java/C#/whatever. The entry point of D programs is main (or, at the object level, _Dmain). Is the extra 4 lines that bad?

-- 
 - Mik Mifflin

"SpookyET" <not4_u@hotmail.com> wrote in message news:opr3op57hh1s9n15@saturn...
> The reason why i said that myMethod should be MyMethod and the same for properties is this:
>
> class Demo
> {
>     public int numbers;
>
>     public int Numbers
>     {
>       get { return numbers; }
>       set { numbers = value; }
>     }
> }
>
> Having methods/properties named in lowercase forces you to name your
> variables to
> ugly naming styles like _var m_var var_.

Its so hard to be imaginative with variable names isnt it?  like cardNumber or phoneNumber.

You dont need "ugly" underscores if you dont want.


> Also a module is a package, it forces you to make folders/subfolders.....

a module is a source file, not a package.
It doesnt force you to make folders/subfolders or anything for that matter.

Phill.

Yes i could name methods as MyMethod but that would mean not using the coding style specified by the language creator and get a mix of camelCase and PascalCase since the builtin types are camelCase.

The properties in C# are translated into 2 functions get_Property and set_Property on compilation.
You don't understand the event handling model in .NET, and +/- are good there.  Buf if the language doesn't let you use multicast
delegates/events (one pointer to many functions), then there is no need for those.

Take a look at this http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp04192001.asp which explains why there is a need for +/- and why you need event, even though you have delegate.  Even for delegates you need +/-.

Here is a small part of that article:

MyClass.LogHandler lh = (MyClass.LogHandler)
         Delegate.Combine(new Delegate[]
            {new MyClass.LogHandler(Logger),
            new MyClass.LogHandler(fl.Logger)});
Wow, that's ugly! Rather than force this syntax on the user, C# provides a nicer syntax. Rather than calling Delegate.Combine(), you can simply use += to combine the two delegates:

MyClass.LogHandler lh = null;
      lh += new MyClass.LogHandler(Logger);
      lh += new MyClass.LogHandler(fl.Logger);


On Fri, 20 Feb 2004 15:33:25 -0500, Mik Mifflin <mik42@NOadelphiaSPAM.net> wrote:

> SpookyET wrote:
>
>> The reason why i said that myMethod should be MyMethod and the same for
>> properties is this:
>
> Then name your methods as MyMethod.  The only advantage that I see the C#
> method having is name sharing.  Though that may be "cleaner", most people
> will see it as a minor gripe, as D provides the same methods for providing
> controlled access to private members.
>
> class Demo {
>    private int numbers;
>
>    public int Numbers() { return numbers; }
>    public void Numbers(int numbers) { this.numbers = numbers; }
> }
>
> What's so hard or different about this, besides the extra name?  Though, I
> suppose it would be possible for overloadInsert to share a name with a
> member variable, does it really need to be done?  After all, D is not a C#
> clone...
>
>> I still think that the properties style of C# is cleaner than having 2
>> methods.
>> What the language needs is indexers (makes classes/structs behave like
>> arrays) and builtin support for events.
>> Events are basically delegates but with some restrictions. It forces you
>> to use +/- to add event handlers.
>> foo.MyEvent += new EventHandler(method);
>>
>> The reason for that is that if you do this (delegate style):
>> foo.MyEfnet = new EventHandler(method)
>> It deletes whatever event handlers you had before.
>
> This syntax is confusing and misleading.  Why use the +/-/= operators to add
> event handlers?  What's wrong with using a member function?  It should be a
> safe assumption that overloading the = operator will change something, not
> add something to a list.  I don't think operator overloads should be used
> for non-mathematical functions (except perhaps opCall), doing so makes code
> harder to read.
>
>> I would also like the D compiler to let you point where main is
>> instead of
>>
>> void main(char[][] args)
>> {
>> Application.Main(args);
>> }
>>
>> class Application
>> {
>>    public static void Main(char args[][])
>>    {
>>      // my app code
>>    }
>> }
>>
>> I'd like to say to the compiler that the entry point is Application.Main
>> to get rid of no OO code.
>>
>
> You would like to propose a change in the compiler to prevent you writing 4
> lines of code?  D is not a pure-OO language, and D is not Java/C#/whatever.
> The entry point of D programs is main (or, at the object level, _Dmain).
> Is the extra 4 lines that bad?
>



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

SpookyET wrote:

> Take a look at this http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol
html/csharp04192001.asp
> which explains why there is a need for +/- and why you need event, even though you have delegate.  Even for delegates you need +/-.
> 
> Here is a small part of that article:
> 
> MyClass.LogHandler lh = (MyClass.LogHandler)
>           Delegate.Combine(new Delegate[]
>              {new MyClass.LogHandler(Logger),
>              new MyClass.LogHandler(fl.Logger)});
> Wow, that's ugly! Rather than force this syntax on the user, C# provides a
> nicer syntax. Rather than calling Delegate.Combine(), you can simply use
> += to combine the two delegates:
> 
> MyClass.LogHandler lh = null;
>        lh += new MyClass.LogHandler(Logger);
>        lh += new MyClass.LogHandler(fl.Logger);

But why can't MyClass.LogHandler have an addHandler method?  Also, it's trivial to make a multicast delegate class, and you can overload the += operator if you _really_ want to..  Though, D does have the append operator, overloading ~= might make sense, just overload opAppend.  Then again, if you ask me, interfaces should be used here instead of delegates anyway.

-- 
 - Mik Mifflin

I don't think you understand event based programming, read that article. OK ~ operator?
~ adds, i need something that removes, thus +/- is still better.

On Fri, 20 Feb 2004 16:42:52 -0500, Mik Mifflin <mik42@NOadelphiaSPAM.net> wrote:

> SpookyET wrote:
>
>> Take a look at this
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol
> html/csharp04192001.asp
>> which explains why there is a need for +/- and why you need event, even
>> though you have delegate.  Even for delegates you need +/-.
>>
>> Here is a small part of that article:
>>
>> MyClass.LogHandler lh = (MyClass.LogHandler)
>>           Delegate.Combine(new Delegate[]
>>              {new MyClass.LogHandler(Logger),
>>              new MyClass.LogHandler(fl.Logger)});
>> Wow, that's ugly! Rather than force this syntax on the user, C# provides a
>> nicer syntax. Rather than calling Delegate.Combine(), you can simply use
>> += to combine the two delegates:
>>
>> MyClass.LogHandler lh = null;
>>        lh += new MyClass.LogHandler(Logger);
>>        lh += new MyClass.LogHandler(fl.Logger);
>
> But why can't MyClass.LogHandler have an addHandler method?  Also, it's
> trivial to make a multicast delegate class, and you can overload the +=
> operator if you _really_ want to..  Though, D does have the append
> operator, overloading ~= might make sense, just overload opAppend.  Then
> again, if you ask me, interfaces should be used here instead of delegates
> anyway.
>



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