www.digitalmars.com         C & C++   DMDScript  

D - Properties should be C# style and Packages should be Namespaces

reply SpookyET <SpookyET_member pathlink.com> writes:
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
Feb 20 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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
  

-- -Anderson: http://badmama.com.au/~anderson/
Feb 20 2004
prev sibling next sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
.. and 'D' should be spelled 'C', right?
Feb 20 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"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

 it would have been better if you would use obj.MyFunction(), it is easier

 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

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

 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

 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
Feb 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Embedded ...

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:c15ogr$ff7$1 digitaldaemon.com...
 "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

 it would have been better if you would use obj.MyFunction(), it is


 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 think the Phobos naming will be made conventional pretty soon. I'm swallowing my personal preference for MyFunction - about the only thing I agree with the OP about :-) - and I'm sure any others will do the same.
 I still don't get the point in keeping the char crap instead of a type

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.

The older I get, the more I hate slow, complex code, and the more I see strings a sequences of characters. Although I originally wanted D to have a string class, I'm becoming less and less convinced. In any case, slicing is just so good, that I'd be very sad to see the evil Java / .NET String type be foisted on us. (Please see http://www.windevnet.com/wdn/webextra/2003/0313/ if you think that C# efficiently manipulates strings.)
 like in the most modern languages.  You can create an Interface to C


 converts strings to char arrays and char arrays back to string like the

 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>

Hear, hear!
 a Hashtable class for key->value stuff is much bette rthan having that

 into arrays.

ever used perl or python? They have "easy to use" hashtables (ie - built

 and
 it makes a big difference.

Agreed
 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

Feb 20 2004
parent reply Sean Kelly <sean ffwd.cx> writes:
Matthew wrote:
 I think the Phobos naming will be made conventional pretty soon. I'm
 swallowing my personal preference for MyFunction - about the only thing I
 agree with the OP about :-) - and I'm sure any others will do the same.

Yup. The D naming scheme isn't my personal favorite but if I submit anything to Phobos you can bet I'll use it. It does make me feel a bit better that the D scheme is the one outlined in "Large Scale C++ Software Design" :).
 The older I get, the more I hate slow, complex code, and the more I see
 strings a sequences of characters. Although I originally wanted D to have a
 string class, I'm becoming less and less convinced.
 
 In any case, slicing is just so good, that I'd be very sad to see the evil
 Java / .NET String type be foisted on us.

It has always struck me as odd that vector and string in C++ are two separate classes when they server such similar purposes. I've been thinking of creating free functions to add the features that D arrays are lacking. There's no reason these need to be builtin methods. Sean
Feb 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c180ns$1ma2$1 digitaldaemon.com...
 Matthew wrote:
 I think the Phobos naming will be made conventional pretty soon. I'm
 swallowing my personal preference for MyFunction - about the only thing


 agree with the OP about :-) - and I'm sure any others will do the same.

Yup. The D naming scheme isn't my personal favorite but if I submit anything to Phobos you can bet I'll use it. It does make me feel a bit better that the D scheme is the one outlined in "Large Scale C++ Software Design" :).
 The older I get, the more I hate slow, complex code, and the more I see
 strings a sequences of characters. Although I originally wanted D to


 string class, I'm becoming less and less convinced.

 In any case, slicing is just so good, that I'd be very sad to see the


 Java / .NET String type be foisted on us.

It has always struck me as odd that vector and string in C++ are two separate classes when they server such similar purposes. I've been thinking of creating free functions to add the features that D arrays are lacking. There's no reason these need to be builtin methods.

I'd love to hear your thoughts on them. Feel free to post and/or email me about that, as it's of interest to me.
Feb 21 2004
prev sibling next sibling parent reply SpookyET <not4_u hotmail.com> writes:
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/
Feb 20 2004
next sibling parent reply Mik Mifflin <mik42 NOadelphiaSPAM.net> writes:
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
Feb 20 2004
parent reply SpookyET <not4_u hotmail.com> writes:
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/htm
/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/
Feb 20 2004
next sibling parent reply Mik Mifflin <mik42 NOadelphiaSPAM.net> writes:
SpookyET wrote:

 Take a look at this
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol

 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
Feb 20 2004
parent reply SpookyET <not4_u hotmail.com> writes:
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

 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/
Feb 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Spooky

Here's my challenge to you.

In accordance with mathematical tradition, I ask you to prove your
conjecture by attempting to disprove it. Specifically, I invite you to
create a multicast event architecture for D, and to use methods rather than
operators.

If you cannot do it, that will lend more weight to your argument. If you've
made a good fist of it, perhaps someone else in the D community might be
able to take it further. If no-one can do it, then you're right, and we all
eat crow pie.

If you can do it, then you're wrong, but you'll have learned a great deal
about D, and you'll have written something that will probably make its way
into the D standard library. I would think the kudos of having provided such
an important component to the core library would more than assuage any red
cheeks you might feel from being proved wrong (by yourself).

Are you up for it?

:)

Matthew




"SpookyET" <not4_u hotmail.com> wrote in message
news:opr3ovl9pj1s9n15 saturn...
 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



 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



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


 anyway.

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

Feb 20 2004
next sibling parent reply SpookyET <not4_u hotmail.com> writes:
Dude, the operators call functions.

MyClass.LogHandler lh = (MyClass.LogHandler)
          Delegate.Combine(new Delegate[]
             {new MyClass.LogHandler(Logger),
             new MyClass.LogHandler(fl.Logger)});

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

+= calls combine
-= calls remove
It is the same away as
int x = y + 2;
int x = y.Add(2);

On Sat, 21 Feb 2004 16:02:32 +1100, Matthew <matthew.hat stlsoft.dot.org>  
wrote:

 Spooky

 Here's my challenge to you.

 In accordance with mathematical tradition, I ask you to prove your
 conjecture by attempting to disprove it. Specifically, I invite you to
 create a multicast event architecture for D, and to use methods rather  
 than
 operators.

 If you cannot do it, that will lend more weight to your argument. If  
 you've
 made a good fist of it, perhaps someone else in the D community might be
 able to take it further. If no-one can do it, then you're right, and we  
 all
 eat crow pie.

 If you can do it, then you're wrong, but you'll have learned a great deal
 about D, and you'll have written something that will probably make its  
 way
 into the D standard library. I would think the kudos of having provided  
 such
 an important component to the core library would more than assuage any  
 red
 cheeks you might feel from being proved wrong (by yourself).

 Are you up for it?

 :)

 Matthew




 "SpookyET" <not4_u hotmail.com> wrote in message
 news:opr3ovl9pj1s9n15 saturn...
 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



 html/csharp04192001.asp
 which explains why there is a need for +/- and why you need event,  


 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



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

 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.   

 again, if you ask me, interfaces should be used here instead of


 anyway.

-- 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 21 2004
parent reply Mik Mifflin <mik42 NOadelphiaSPAM.net> writes:
SpookyET wrote:

 Dude, the operators call functions.
 
 MyClass.LogHandler lh = (MyClass.LogHandler)
           Delegate.Combine(new Delegate[]
              {new MyClass.LogHandler(Logger),
              new MyClass.LogHandler(fl.Logger)});
 
 MyClass.LogHandler lh = null;
        lh += new MyClass.LogHandler(Logger);
        lh += new MyClass.LogHandler(fl.Logger);
 
 += calls combine
 -= calls remove
 It is the same away as
 int x = y + 2;
 int x = y.Add(2);
 

You seem to be missing the point as to why most people here think that overloading the operators is a bad idea. It makes code hard to read and adds quite a large confusion factor. When you see += on a class, you have to think, what does += mean? In this case, the meaning is not exactly intuitive. Though, if you use a method with a meaningful name, even if you don't know the class well, you can probably know what the method does just from it's name. You have also seemed to have disproved your own point. If the overloaded operators simply call methods with meaningful names, why use the operators at all? They're not needed, and probably shouldn't be there, they only confuse matters. Also, and I think I said this before, D is not C#. D is also not .net. It has no reason to follow such confusing conventions. It sounds a awful lot like you want to use .net, and nothing else. In that case, you'd be better off using .net and C#... -- - Mik Mifflin
Feb 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 SpookyET wrote:

 Dude, the operators call functions.

 MyClass.LogHandler lh = (MyClass.LogHandler)
           Delegate.Combine(new Delegate[]
              {new MyClass.LogHandler(Logger),
              new MyClass.LogHandler(fl.Logger)});

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

 += calls combine
 -= calls remove
 It is the same away as
 int x = y + 2;
 int x = y.Add(2);

You seem to be missing the point as to why most people here think that overloading the operators is a bad idea. It makes code hard to read and adds quite a large confusion factor. When you see += on a class, you have to think, what does += mean? In this case, the meaning is not exactly intuitive. Though, if you use a method with a meaningful name, even if

 don't know the class well, you can probably know what the method does just
 from it's name.

Quite right <shameless plug> In Appendix B of my forthcoming book "Imperfect C++", I come clean on several crimes against programming that I made in my "C++ youth". One of the ones included is probably the worst string class ever written, with a host of interesting operator overloads. </shameless plug> The harder you learn, the better the lesson. ;)
 You have also seemed to have disproved your own point.  If the overloaded
 operators simply call methods with meaningful names, why use the operators
 at all?  They're not needed, and probably shouldn't be there, they only
 confuse matters.

Exactly! Operators are the zenith of maintainability when they follow expected (i.e. mathematical) semantics. When they do not, they represent a nadir.
Feb 21 2004
prev sibling parent reply SpookyET <not4_u hotmail.com> writes:
One more thing, I don't like where the class library is going.  It is just  
like the old C.  D is 21st century language, and it should have 21st  
century library where you can do component based programming.  Basically,  
the .net framework (ripoff of Delphi's class library).  You have to think  
about more complicated stuff than basic console apps.
starting with system.Object;
system.io;
system.xml;
system.data;

Int .NET it is easier since int, object, char and the rest point to  
System.Int32, System.Object, System.Char and so on.

D needs to allow the user to declare attributes and extend them like in C#.

class MyAttribute : Attribute
{
   // code
}

[MyAttribute()] int Foobar()
{
}
On Sat, 21 Feb 2004 16:02:32 +1100, Matthew <matthew.hat stlsoft.dot.org>  
wrote:

 Spooky

 Here's my challenge to you.

 In accordance with mathematical tradition, I ask you to prove your
 conjecture by attempting to disprove it. Specifically, I invite you to
 create a multicast event architecture for D, and to use methods rather  
 than
 operators.

 If you cannot do it, that will lend more weight to your argument. If  
 you've
 made a good fist of it, perhaps someone else in the D community might be
 able to take it further. If no-one can do it, then you're right, and we  
 all
 eat crow pie.

 If you can do it, then you're wrong, but you'll have learned a great deal
 about D, and you'll have written something that will probably make its  
 way
 into the D standard library. I would think the kudos of having provided  
 such
 an important component to the core library would more than assuage any  
 red
 cheeks you might feel from being proved wrong (by yourself).

 Are you up for it?

 :)

 Matthew




 "SpookyET" <not4_u hotmail.com> wrote in message
 news:opr3ovl9pj1s9n15 saturn...
 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



 html/csharp04192001.asp
 which explains why there is a need for +/- and why you need event,  


 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



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

 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.   

 again, if you ask me, interfaces should be used here instead of


 anyway.

-- 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 21 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
SpookyET wrote:
 One more thing, I don't like where the class library is going.  It is 

I'm curious. Is there anything about D that you do like? Did D get anything right in your opinion? -- Justin http://jcc_7.tripod.com/d/
Feb 21 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
One more thing, I don't like where the class library is going.  It is just  
like the old C.  D is 21st century language, and it should have 21st  
century library where you can do component based programming.  Basically,  
the .net framework (ripoff of Delphi's class library).  You have to think  
about more complicated stuff than basic console apps.
starting with system.Object;
system.io;
system.xml;
system.data;

Int .NET it is easier since int, object, char and the rest point to  
System.Int32, System.Object, System.Char and so on.

Sorry, I don't get it. Could you please explain the point again? int is an alias for System.Int32? What's so amazing about it?
D needs to allow the user to declare attributes and extend them like in C#.

class MyAttribute : Attribute
{
   // code
}

[MyAttribute()] int Foobar()
{
}

Da has no real reflection abilities, so attributs aren't very usefull, are they?
Feb 24 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"SpookyET" <not4_u hotmail.com> wrote in message
news:opr3osiidr1s9n15 saturn...
 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.

Correct point. I agree.
 The properties in C# are translated into 2 functions get_Property and
 set_Property on compilation.

Ah, so you do have two functions, then? <g>
 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.

I do, and have used it in anger. However, there's nothing in it that requires the use of obfuscatory operators instead of (somewhat) more readable methods. There are very few cases - and I can only think of C++ ones - where an operator can provide something that an overt method cannot. (Although I'd be interested in anyone proving me wrong in, say C# and/or D - that's something we can put in the first issue of The D Journal. Your prize is no cash, but smugness and deference to all your NG posts for 48 hrs.)
 Take a look at this

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

If it can be succinctly translated to operators, then why not to methods? Your reasoning is specious.
 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


 method having is name sharing.  Though that may be "cleaner", most


 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



 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


 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



 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/

Feb 20 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
SpookyET wrote:

 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.

I just use _member for the actual member, then use the property everywhere. (even internally) If you're worried about speed, make the properties final, so they can't be overridden. (and thus more likely to be inlined)
 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.

Events shouldn't have been in C# to begin with, but it didn't have generics at the time, so there was no other way. D does have generics, and they're pretty good; I implemented C#-styled events with them awhile ago: <http://ikagames.com/andy/d/Listener.d> By the way, the reason I chose to use += and -= instead of ~= or methods was because the syntax looks infinitely nicer when using function literals: Listener!(int, float) myListener; myListener += delegate(int i, float f) { ... }; Also, you could rationalize that listeners are theoretically unordered, so the idea of concatenation isn't quite right, thus forcing (sigh) the use of + and -. At least the mathematical notion of adding listeners doesn't make any sense, which frees up ambiguity. -- andy
Feb 21 2004
parent reply SpookyET <not4_u hotmail.com> writes:
Having event support in the language is way cooler, it forces developers  
to use one form of event handling instead of their own.

delegate OnFoobarEventHandler(object o, EventArgs e)
{
   add { //do some things here if you }
   remove { // do some things here }
};

event OnFoobarEventHandler FoobarEvent
{
   add { // ... }
   remove { // .... }
}


obj.FoobarEvent += new OnFoobarEventHandler(obj.Method);

how nice is that

i don't see the point why in D you have to use opAdd and crap like that ot  
override an operator what is wrong with
class Foobar {
public static Foobar operator +(Foobar c1, Foobar c2)
{
	
}
}

In C# events are delgates where you have to use +/- to assign to them,  
that is all.  If you assing directly, you will erase what was there  
before.  They only thing I don't like about C# is that it ties you in to  
the framework.  I guess I want D to become native C#.  My point is that  
when they designed this language, they looked at a ton of languages and  
took only the good things, D should be in the same way and take the nice  
stuff of C#.  A nice framework should be created for D istead of all this  
ununited module projects.
system.Event;
system.Delegate;
system.xml*;
system.data*;
system.foobar;
Camel Casing for Methods/Properties is better since you can have a field  
named something, the encapsulate it later and don't have to mess with _var  
m_var mVar, var_.  myArray.Length instead of myArray.length.  Microsoft  
has always seen the greater picture.

In there, i am using the "+" sign... it is better that way

On Sat, 21 Feb 2004 08:59:55 -0800, Andy Friesen <andy ikagames.com> wrote:

 SpookyET wrote:

 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.

I just use _member for the actual member, then use the property everywhere. (even internally) If you're worried about speed, make the properties final, so they can't be overridden. (and thus more likely to be inlined)
 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.

Events shouldn't have been in C# to begin with, but it didn't have generics at the time, so there was no other way. D does have generics, and they're pretty good; I implemented C#-styled events with them awhile ago: <http://ikagames.com/andy/d/Listener.d> By the way, the reason I chose to use += and -= instead of ~= or methods was because the syntax looks infinitely nicer when using function literals: Listener!(int, float) myListener; myListener += delegate(int i, float f) { ... }; Also, you could rationalize that listeners are theoretically unordered, so the idea of concatenation isn't quite right, thus forcing (sigh) the use of + and -. At least the mathematical notion of adding listeners doesn't make any sense, which frees up ambiguity. -- andy

-- Using 5YjWOpera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 21 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I would think that if event management is in the standard library, 
developers won't be thinking twice before using it!

SpookyET wrote:
 Having event support in the language is way cooler, it forces 
 developers  to use one form of event handling instead of their own.
 
 delegate OnFoobarEventHandler(object o, EventArgs e)
 {
   add { //do some things here if you }
   remove { // do some things here }
 };
 
 event OnFoobarEventHandler FoobarEvent
 {
   add { // ... }
   remove { // .... }
 }
 
 
 obj.FoobarEvent += new OnFoobarEventHandler(obj.Method);
 
 how nice is that
 
 i don't see the point why in D you have to use opAdd and crap like that 
 ot  override an operator what is wrong with
 class Foobar {
 public static Foobar operator +(Foobar c1, Foobar c2)
 {
     
 }
 }
 
 In C# events are delgates where you have to use +/- to assign to them,  
 that is all.  If you assing directly, you will erase what was there  
 before.  They only thing I don't like about C# is that it ties you in 
 to  the framework.  I guess I want D to become native C#.  My point is 
 that  when they designed this language, they looked at a ton of 
 languages and  took only the good things, D should be in the same way 
 and take the nice  stuff of C#.  A nice framework should be created for 
 D istead of all this  ununited module projects.
 system.Event;
 system.Delegate;
 system.xml*;
 system.data*;
 system.foobar;
 Camel Casing for Methods/Properties is better since you can have a 
 field  named something, the encapsulate it later and don't have to mess 
 with _var  m_var mVar, var_.  myArray.Length instead of myArray.length.  
 Microsoft  has always seen the greater picture.
 
 In there, i am using the "+" sign... it is better that way
 
 On Sat, 21 Feb 2004 08:59:55 -0800, Andy Friesen <andy ikagames.com> wrote:
 
 SpookyET wrote:

 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.

I just use _member for the actual member, then use the property everywhere. (even internally) If you're worried about speed, make the properties final, so they can't be overridden. (and thus more likely to be inlined)
 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.

Events shouldn't have been in C# to begin with, but it didn't have generics at the time, so there was no other way. D does have generics, and they're pretty good; I implemented C#-styled events with them awhile ago: <http://ikagames.com/andy/d/Listener.d> By the way, the reason I chose to use += and -= instead of ~= or methods was because the syntax looks infinitely nicer when using function literals: Listener!(int, float) myListener; myListener += delegate(int i, float f) { ... }; Also, you could rationalize that listeners are theoretically unordered, so the idea of concatenation isn't quite right, thus forcing (sigh) the use of + and -. At least the mathematical notion of adding listeners doesn't make any sense, which frees up ambiguity. -- andy


Feb 21 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
SpookyET wrote:

 Having event support in the language is way cooler, it forces 
 developers  to use one form of event handling instead of their own.

The general rule is that anything that can realistically be implemented outside the compiler is. This has the effect of maximizing the effectiveness of the language without making it overly difficult to implement correctly. (just look at how long it took for C++ compilers to implement the language correctly)
 i don't see the point why in D you have to use opAdd and crap 

This is a *really* small detail, don't you think? (FYI, it makes the language easier to implement. Additionally, opAdd is highly greppable)
 A nice framework should be created for 
 D istead of all this  ununited module projects.

meh. I'm a fan of diversity. I think it's more important that there be a convention set forth so that libraries can be packaged and imported into build systems without fuss.
 Camel Casing for Methods/Properties is better since you can have a 
 field  named something, the encapsulate it later and don't have to mess 
 with _var  m_var mVar, var_.  myArray.Length instead of myArray.length.  
 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra character. Who cares?
 In there, i am using the "+" sign... it is better that way

Why? I think you have problems identifying elements of a language that really matter, as opposed to miniscule syntactic nuances. None of the things you've mentioned so far would cost anybody more than five minutes of their time. -- andy
Feb 21 2004
parent reply "Phill" <phill pacific.net.au> writes:
 Camel Casing for Methods/Properties is better since you can have a
 field  named something, the encapsulate it later and don't have to mess
 with _var  m_var mVar, var_.  myArray.Length instead of myArray.length.
 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra character. Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that identifies the variable and appeals to your eye, then you dont have a very good imagination. I dont see what there is to winge about. Phill.
Feb 21 2004
parent reply SpookyET <not4_u hotmail.com> writes:
Why are you people so closed minded?  If the language was 1.0, I wouldn't  
bitch about it, but since it is under development, I do.

On Sun, 22 Feb 2004 13:43:29 +1100, Phill <phill pacific.net.au> wrote:

 Camel Casing for Methods/Properties is better since you can have a
 field  named something, the encapsulate it later and don't have to  

 with _var  m_var mVar, var_.  myArray.Length instead of  

 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra character. Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that identifies the variable and appeals to your eye, then you dont have a very good imagination. I dont see what there is to winge about. Phill.

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 21 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
SpookyET wrote:

 Why are you people so closed minded?  If the language was 1.0, I 
 wouldn't  bitch about it, but since it is under development, I do.
 

It's not about close mindedness, it's about trying to 'fix' a problem that dosen't exist! (believe me, the folks on this newsgroup are a lot more open minded than most) -- andy
Feb 21 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
SpookyET wrote:
 Why are you people so closed minded?  If the language was 1.0, I 
 wouldn't  bitch about it, but since it is under development, I do.

D is at 0.79. That rounds up to 1.0 as far as I'm concerned. Now is not the time to throw the spec away and break all of the code. Minor adjustments can be made, but the spec isn't going to be completely rewritten just to make it more similar to C#. I'm curious which other languages you might have some experience in since you seem to view everything as "Since C#, does this..." We're not close-minded, but communication is a two-way street. You have a strong ability to discover how D is different than C#, but D isn't intended to be a clone of C#. If you love everything about C#, I think you should consider just going back to C#. (If you actually want to try D, you need to give D a chance.) -- Justin http://jcc_7.tripod.com/d/
Feb 21 2004
prev sibling next sibling parent reply "Phill" <phill pacific.net.au> writes:
Actually this NG opened my mind to other
languages and there strengths and weaknesses.

For example, when I first came here, I thought that Java was the only way to
go, now I know thats
nowhere near the truth.

Phill.

"SpookyET" <not4_u hotmail.com> wrote in message
news:opr3q4wti81s9n15 saturn...
 Why are you people so closed minded?  If the language was 1.0, I wouldn't
 bitch about it, but since it is under development, I do.

 On Sun, 22 Feb 2004 13:43:29 +1100, Phill <phill pacific.net.au> wrote:

 Camel Casing for Methods/Properties is better since you can have a
 field  named something, the encapsulate it later and don't have to

 with _var  m_var mVar, var_.  myArray.Length instead of

 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra character. Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that identifies the variable and appeals to your eye, then you dont have a very good imagination. I dont see what there is to winge about. Phill.

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

Feb 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Actually this NG opened my mind to other
 languages and there strengths and weaknesses.

Spot on! I've taken up several new languages since joining D. The level of debate, informativeness (if that's a word) and helpfulness on this NG is second to none.
 For example, when I first came here, I thought that Java was the only way

 go, now I know thats
 nowhere near the truth.

Verily, though speaketh the truth. Just to really piss 'im off, IMO D is not a successor to C or C++, much though Walter will have it as such. Rather I think it will be the language used in preference to .NET and Java for all but a modest set of classes of applications. The only thing that will hold this up is the lack of libraries. But they're growing. I'd like to see new members backing up their just criticisms of the libraries put their skills where their mouths are and help out in filling the gaps that are most important to them. That way, they get to either prove/disprove their criticisms of the language, learn more things, and potentially add to the movement. Sound reasonable?
 Phill.

 "SpookyET" <not4_u hotmail.com> wrote in message
 news:opr3q4wti81s9n15 saturn...
 Why are you people so closed minded?  If the language was 1.0, I


 bitch about it, but since it is under development, I do.

 On Sun, 22 Feb 2004 13:43:29 +1100, Phill <phill pacific.net.au> wrote:

 Camel Casing for Methods/Properties is better since you can have a
 field  named something, the encapsulate it later and don't have to

 with _var  m_var mVar, var_.  myArray.Length instead of

 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra




   Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that



 the
 variable and
 appeals to your eye, then you dont have a very good imagination.

 I dont see what there is to winge about.


 Phill.

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


Feb 21 2004
next sibling parent "Phill" <phill pacific.net.au> writes:
Sounds reasonable to me :o))


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c19j89$1lc9$1 digitaldaemon.com...
 Actually this NG opened my mind to other
 languages and there strengths and weaknesses.

Spot on! I've taken up several new languages since joining D. The level of debate, informativeness (if that's a word) and helpfulness on this NG is second to none.
 For example, when I first came here, I thought that Java was the only


 to
 go, now I know thats
 nowhere near the truth.

Verily, though speaketh the truth. Just to really piss 'im off, IMO D is not a successor to C or C++, much though Walter will have it as such. Rather I think it will be the language used in preference to .NET and Java for all but a modest set of classes of applications. The only thing that will hold this up is the lack of libraries. But they're growing. I'd like to see new members backing up their just criticisms of the libraries put their skills where their mouths are and help out in filling the gaps that are most important to them. That way, they get to either prove/disprove their criticisms of the language, learn more things, and potentially add to the movement. Sound reasonable?
 Phill.

 "SpookyET" <not4_u hotmail.com> wrote in message
 news:opr3q4wti81s9n15 saturn...
 Why are you people so closed minded?  If the language was 1.0, I


 bitch about it, but since it is under development, I do.

 On Sun, 22 Feb 2004 13:43:29 +1100, Phill <phill pacific.net.au>



 Camel Casing for Methods/Properties is better since you can have






 field  named something, the encapsulate it later and don't have






 mess
 with _var  m_var mVar, var_.  myArray.Length instead of

 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra




   Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that



 the
 variable and
 appeals to your eye, then you dont have a very good imagination.

 I dont see what there is to winge about.


 Phill.

-- Using M2, Opera's revolutionary e-mail client:





Feb 22 2004
prev sibling parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Sun, 22 Feb 2004 17:47:01 +1100 (02/22/04 17:47:01)
, Matthew <matthew.hat stlsoft.dot.org> wrote:

 Actually this NG opened my mind to other
 languages and there strengths and weaknesses.

Spot on! I've taken up several new languages since joining D. The level of debate, informativeness (if that's a word) and helpfulness on this NG is second to none.

well....there is the very useful euforum at www.topica.com. This is primarily for the Euphoria language but it is also very helpful and informative in respect to all the other great languages out there.
 For example, when I first came here, I thought that Java was the only 
 way

 go, now I know thats
 nowhere near the truth.

Verily, though speaketh the truth.

Learning only one programming language is a form of colour blindness. You need to learn many to see the fuller spectrum.
 Just to really piss 'im off, IMO D is not a successor to C or C++, much
 though Walter will have it as such. Rather I think it will be the 
 language
 used in preference to .NET and Java for all but a modest set of classes 
 of
 applications. The only thing that will hold this up is the lack of
 libraries. But they're growing.

Yes, I can see this too. D does seem to be more of a new niche language than a replacement for one of the mainstream languages. And that is a valid thing too, as there are lots of niches that need filling ;-)
 I'd like to see new members backing up their just criticisms of the
 libraries put their skills where their mouths are and help out in filling
 the gaps that are most important to them. That way, they get to either
 prove/disprove their criticisms of the language, learn more things, and
 potentially add to the movement. Sound reasonable?

Yes, but not everyone is a library writer. Libraries need a certain skill set which is not universal in coders. However, anyone who wants to can still contribute in other ways - reviewing, testing, documenting, suggesting, ... -- Derek
Feb 22 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
<snip>

 I'd like to see new members backing up their just criticisms of the
 libraries put their skills where their mouths are and help out in


 the gaps that are most important to them. That way, they get to either
 prove/disprove their criticisms of the language, learn more things, and
 potentially add to the movement. Sound reasonable?

Yes, but not everyone is a library writer. Libraries need a certain skill set which is not universal in coders. However, anyone who wants to can still contribute in other ways - reviewing, testing, documenting, suggesting, ...

A fair point.
Feb 22 2004
prev sibling next sibling parent Chris Sauls <ibisbasenji yahoo.com> writes:
For my own take, I tend to use _var whenever said variable is for 
private only use.  Considering that, the _var convention for private 
members suits my style rather perfectly.  Also, its not like anybody is 
forcing your hand.  Name it mVar if you want, in classic Microsoft 
Hungarian style.

- Chris S.
- Invironz

SpookyET wrote:
 Why are you people so closed minded?  If the language was 1.0, I 
 wouldn't  bitch about it, but since it is under development, I do.
 
 On Sun, 22 Feb 2004 13:43:29 +1100, Phill <phill pacific.net.au> wrote:
 
 Camel Casing for Methods/Properties is better since you can have a
 field  named something, the encapsulate it later and don't have to  

 with _var  m_var mVar, var_.  myArray.Length instead of  

 Microsoft  has always seen the greater picture.

Another microscopic detail. _var means a whopping one extra character. Who cares?

Yea, I agree, that is a bunch of bullshit, you can give a variable (almost) any name you want. If you cant think of an appropriate name that identifies the variable and appeals to your eye, then you dont have a very good imagination. I dont see what there is to winge about. Phill.


Feb 24 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
Why are you people so closed minded?  If the language was 1.0, I wouldn't  
bitch about it, but since it is under development, I do.

OK, suggest something usefull. You want us to ad C# like properties, but we already have a easyer more flexible way. You want us to add a restrictive event system, but we want to be able to create our own more powerfull one. ...
Feb 24 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
SpookyET wrote:

 i don't see the point why in D you have to use opAdd and crap like that 
 ot  override an operator what is wrong with
 class Foobar {
 public static Foobar operator +(Foobar c1, Foobar c2)
 {
     
 }
 }

Just look at it: it's STATIC. It would break in almost any descendant class. Besides, having simple methods instead of a special syntax would make life *much* easier for analysis tools, not just for the compiler. -eye
Feb 22 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
Having event support in the language is way cooler, it forces developers  
to use one form of event handling instead of their own.

So coding is about coolness? Interesting. So you like being restricted? You are realy strange.
delegate OnFoobarEventHandler(object o, EventArgs e)
{
   add { //do some things here if you }
   remove { // do some things here }
};

event OnFoobarEventHandler FoobarEvent
{
   add { // ... }
   remove { // .... }
}


obj.FoobarEvent += new OnFoobarEventHandler(obj.Method);

how nice is that

???
i don't see the point why in D you have to use opAdd and crap like that ot  
override an operator what is wrong with
class Foobar {
public static Foobar operator +(Foobar c1, Foobar c2)
{
	
}
}

I ever got it. I'd prefere operator +, too.
In C# events are delgates where you have to use +/- to assign to them,  
that is all.  If you assing directly, you will erase what was there  
before.  They only thing I don't like about C# is that it ties you in to  
the framework.  I guess I want D to become native C#.  My point is that  
when they designed this language, they looked at a ton of languages and  
took only the good things, D should be in the same way and take the nice  
stuff of C#. 

But the stuff you suggest is defenetly not nice, but restrictive.
A nice framework should be created for D istead of all this  
ununited module projects.
system.Event;
system.Delegate;
system.xml*;
system.data*;
system.foobar;

In D we use std not system.
Camel Casing for Methods/Properties is better since you can have a field  
named something, the encapsulate it later and don't have to mess with _var  
m_var mVar, var_.  myArray.Length instead of myArray.length.  

thisIsCamelCase, ThisIsntCamelCase!!!
Microsoft  
has always seen the greater picture.

so the greater picture is money?
Feb 24 2004
prev sibling next sibling parent "Phill" <phill pacific.net.au> writes:
"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.
Feb 20 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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_.

Member variable decoration is a boon, not a bane. Please explain why you think the contrary.
 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.

Honk! There are two methods, just tailored syntax. FWIW, I have problems with the D properties implementation, but at a more fundamental level. I don't think it's reasonable for client code to decide whether a method should act as a property or not. That is something for the class designer to determine. Also, there are still practical, though eminently solvable, parsing problems with properties. I have no doubt these will be ironed out before 1.0
 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)?

Far out! This is bordering on the peurile. You can write a class to do whatever you want. Although D is designed to make such obfuscatory (and, IMHO, worthless) syntactical sugar harder to do, there's no doubt that you can do this if you wish.
 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
    }
 }

Why? There can only ever be one entry point for a process, so why on earth does it need to go as a class method? If you were to argue that it could optionally be a class method or a free function, then there's some merit in that. But you didn't. :(
 I'd like to say to the compiler that the entry point is Application.Main
 to get rid of no OO code.

What's wrong with non-OO code? I'm afraid that we're at the uncomfortable, but necessary, point at which I am compelled to ask you how long you've been programming, and what courses you were taught at University. If the answer to the latter is "lots of things, but they were all Object-Oriented oriented", then I'm afraid you've been done a great disservice by your educators. We might then surmise that the answer to the former is "a few years". There is no single answer in IT, and there never will be. If you think "OO is the way to go" 100% of the time, then you are (i) wrong, (ii) depriving yourself of learning, (iii) likely to be making the strategists at one or more friendly giant software corporation very happy indeed, since you'll be furthering their cause - as evinced by your postings - that there are but a few limited, and commercially intertwined, ways to go, and anything else is out-of-date and useless. It's a dream, and it's not yours! (Not that I'm trying to put you off posting, or involvement with D. Far from it. But you're wasting your time here if you think you can proselytise a single mindset on the people and ethos of D. That's one of the reasons most here are interested in it in the first place.)
 Also a module is a package, it forces you to make folders/subfolders.....

There is much wrong with the module concept. I think you'll hit a rich seam if you dig this way, rather than trying to tell us all that everything's an object. In the words of the great Alex Stepanov (http://www.stlport.org/resources/StepanovUSA.html): "Even if it is true [that everything is an object] it is not very interesting - saying that everything is an object is saying nothing at all"
 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


 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/

Feb 20 2004
parent Sean Kelly <sean ffwd.cx> writes:
Matthew wrote:
 There is much wrong with the module concept. I think you'll hit a rich seam
 if you dig this way, rather than trying to tell us all that everything's an
 object. In the words of the great Alex Stepanov
 (http://www.stlport.org/resources/StepanovUSA.html): "Even if it is true
 [that everything is an object] it is not very interesting - saying that
 everything is an object is saying nothing at all"

There was an interesting interview linked on Slashdot recently with Victoria Livschitz, who works at Sun (http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html). It's pretty interesting, and I do somewhat agree with her that not every concept can be accurately modeled as an object (unless perhaps if you're a huge fan of memes). It's not clear that she has a better solution, but it's a good interview nevertheless :) Sean
Feb 21 2004
prev sibling next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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_.

I hate methods/properties starting with an upercase letter. My rule is Types start with upper case letters, variables/functions with lower case letters. And I don't want to change this only to get a worse way of properties than the current D-properties. :confused: Instead of something stupid like this we should think about alternatives. E.g. we could add something like namespaces in C++ but on class level. class Foo { namepsace m { int var; } public int var () { return m.var; } public var (int value) { m.var = value; } } this is only an idea. Perhaps there are other better ideas.
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.

That's your oppinion.
What the language needs is indexers (makes classes/structs behave like  
arrays) and builtin support for events.

We already have opIndex()
Events are basically delegates but with some restrictions. It forces you  
to use +/- to add event handlers.
foo.MyEvent += new EventHandler(method);

We could write that on our own, if we'd like to.
I'm not sure, but does D allow supports multicast delegates (delegates  
that point to more than one function)?

No, but you could write it on your own.
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.

only because something is inside of a class it isn't oo. I can code procedural in classes (in c#) without problems by only using static methods. main is something procedural, independend on where it's placed.
Also a module is a package, it forces you to make folders/subfolders.....

agreed
Feb 24 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthias Becker wrote:

I hate methods/properties starting with an upercase letter. My rule is Types
start with upper case letters, variables/functions with lower case letters. And
I don't want to change this only to get a worse way of properties than the
current D-properties. :confused:

Instead of something stupid like this we should think about alternatives. E.g.
we could add something like namespaces in C++ but on class level.

class Foo {
namepsace m {
int var;
}
public int var ()
{
return m.var;
}
public var (int value)
{
m.var = value;
}
}


this is only an idea. Perhaps there are other better ideas.

  

class Foo { struct M { int var; }; M m; public int var () { return m.var; } public void var (int value) { m.var = value; } } In C++ you could go: class Foo { struct { int var; }m; //Not allowed in D ... } -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
prev sibling parent Sean Kelly <sean ffwd.cx> writes:
SpookyET wrote:

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

So you're saying you want to break the ability to distinguish between objects and functions because it forces you to use ugly variable names? This isn't a very convincing argument. And frankly, you should be distinguishing class member vars anyway. Read "Large Scale C++ Software Design."
 What the language needs is indexers (makes classes/structs behave like  
 arrays) and builtin support for events.

I agree about the indexers (ie. operator[]) but not events. Building support for a specific programming model into the language is a mistake, IMO. If a better model is developed later on, the language will be forced to continue to support the old model.
 Events are basically delegates but with some restrictions. It forces 
 you  to use +/- to add event handlers.
 foo.MyEvent += new EventHandler(method);

And to think I am normally a big supporter of operator overloading. This syntax is terrifying.
 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.


Modules ARE namespaces. As are classes. Sean
Feb 24 2004
prev sibling parent Sam McCall <tunah.d tunah.net> writes:
SpookyET 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

is a property". I can't see any reason that it should be possible to access a property using both function and variable syntax, and this causes errors as it's not fully implemented (can't convert int() to int and so on). There is a semantic difference too: D allows a property setter to take different types. This doesn't seem natural to me, sounding more like a case for an operEquals overload if it ever needs to be used at all. Anyone got a good example? Overall, agree with you here.
 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!");
 }
 }
 }

everything in one file, or use a thousand imports. An import foo.* would fix this nicely though. I prefer modules, one-to-one with source files is a good thing.
 No package crap, no includes no nothing.

 It searches the resources for that namespace and converts Console to
 System.Console. 

tell it where to find imports because of the module=file thing.
 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.

has been Java. I'm happy to use either - bottom line is use what's standard - MyFunction in C#/C++, myFunction in Java/D. This is a non-issue.
 I still don't get the point in keeping the char crap instead of a type "string"
 like in the most modern languages.

D strings are much more functional than char arrays in most languages with a String class. Still, I do think a class would be nice to give us some more functions - toLower and so on make more sense to me as member functions. But mutable or immutable? ;) I don't think this matters a great deal either way.
 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

it's builtin or library doesn't really matter apart from syntax (int [Object] versus Hashtable!(int,Object) ). Builtin possibly allows for better optimisation of this fundamental type. By the way, your one isn't typesafe :P. And you really have to have foobar[key]= as an overloadable operator for them to make sense. Since D supports both of these I think having it in phobos would have worked too.
 haven't made up my mind about the foobar[2..3] stuff, looks weird

Sam
Feb 21 2004