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

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/

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

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

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

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

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

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/

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

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/