February 22, 2004
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.

> In C# 
> 
> using System;
> 
> namespace Foobar
> {
> public class HelloWorld
> {
> public static void Main()
> {
> // If you don't put using System you have
> // to type System.Console.WriteLine("Hello World!");
> Console.WriteLine("Hello World!");
> }
> }
> }
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 standard - MyFunction in C#/C++, myFunction in Java/D. This is a non-issue.

> I still don't get the point in keeping the char crap instead of a type "string"
> like in the most modern languages.
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.
It's really starting to sound like you want to use C#.

> 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.
Yes, it should be simple and fast, just like C#.

> 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
February 22, 2004
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/


February 22, 2004
> 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/
>
>


February 22, 2004
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/
> >
> >
>
>


February 22, 2004
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
February 23, 2004
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
February 23, 2004
<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.



February 24, 2004
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.

February 24, 2004
>The reason why i said that myMethod should be MyMethod and the same for properties is this:
>
>class Demo
>{
>    public int numbers;
>
>    public int Numbers
>    {
>      get { return numbers; }
>      set { numbers = value; }
>    }
>}
>
>Having methods/properties named in lowercase forces you to name your
>variables to
>ugly naming styles like _var m_var var_.

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

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

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


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


>class Demo
>{
>    public int _numbers;
>
>    public int numbers
>    {
>      get { return _numbers; }
>      set { _numbers = value; }
>    }
>}
>
>I still think that the properties style of C# is cleaner than having 2 methods.

That's your oppinion.


>What the language needs is indexers (makes classes/structs behave like arrays) and builtin support for events.

We already have opIndex()

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

We could write that on our own, if we'd like to.

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

No, but you could write it on your own.



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

only because something is inside of a class it isn't oo. I can code procedural in classes (in c#) without problems by only using static methods. main is something procedural, independend on where it's placed.



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

agreed



February 24, 2004
>One more thing, I don't like where the class library is going.  It is just
>like the old C.  D is 21st century language, and it should have 21st
>century library where you can do component based programming.  Basically,
>the .net framework (ripoff of Delphi's class library).  You have to think
>about more complicated stuff than basic console apps.
>starting with system.Object;
>system.io;
>system.xml;
>system.data;
>
>Int .NET it is easier since int, object, char and the rest point to System.Int32, System.Object, System.Char and so on.

Sorry, I don't get it. Could you please explain the point again? int is an alias for System.Int32? What's so amazing about it?



>D needs to allow the user to declare attributes and extend them like in C#.
>
>class MyAttribute : Attribute
>{
>   // code
>}
>
>[MyAttribute()] int Foobar()
>{
>}

Da has no real reflection abilities, so attributs aren't very usefull, are they?