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.


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
  


This is supported.

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


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


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


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


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

efficiently manipulates strings.)


 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>


Hear, hear!


 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.


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




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.


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


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.


 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:



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

clone...



 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

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.


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

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:



 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  

 clone...



 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  

 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


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

 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


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

 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






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

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






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

 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/






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


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


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


you

 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.



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






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

 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/






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






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.



 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.

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


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

 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




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

 clone...



 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

 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)



 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.



generics at the time, so there was no other way.


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


that is all.  If you assing directly, you will erase what was there  


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  

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)



 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.



 generics at the time, so there was no other way.


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

 that is all.  If you assing directly, you will erase what was there  


 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 

 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)



 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.




 generics at the time, so there was no other way.

 D does have generics, and they're pretty good; I implemented 

 <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  


 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.




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

languages you might have some experience in since you seem to view 


We're not close-minded, but communication is a two-way street. You have 




(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


 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.




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


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




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


 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.




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




way

 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




 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

 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.




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






http://www.opera.com/m2/







 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


 to

 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




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


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  


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



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.




that is all.  If you assing directly, you will erase what was there  


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  



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


 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.


 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



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


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

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.

  


You can almost do that with a struct:

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


Yes, D lets you do the same thing, but there's no way to indicate "this 
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.


You can't expect to be taken seriously saying things like that.



 
 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!");
 }
 }
 }


One thing that irritates me about D's modules is you have to put 
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.


No includes? Oh right, you call them "using" :-P


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


D does this as well, but you don't (I think, I haven't checked) have to 
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.


Depends who's reading it. I prefer myFunction, a lot of my background 
has been Java. I'm happy to use either - bottom line is use what's 



 I still don't get the point in keeping the char crap instead of a type "string"
 like in the most modern languages.


alias char[] string; :-P
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;


How long have you been using D?


 StringBuilder type class would be better though.


Better than a String?


 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 important to have a standard way of doing these things, whether 
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


It works.

Sam



 Feb 21 2004