Embedded ...

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c15ogr$ff7$1@digitaldaemon.com...
>
> "SpookyET" <SpookyET_member@pathlink.com> wrote in message news:c15i6u$1si$1@digitaldaemon.com...
> > private string foobar;
> >
> > public string Foobar
> > {
> > get
> > {
> > return foobar;
> > }
> > set
> > {
> > foobar = value;
> > }
> > }
> >
> > If you don't have get, the property is write only.
> > If you don't have set, the property is read only
> >
> > Dude, get rid of the package crap, namespaces are better. In C#
> >
> > using System;
> >
> > namespace Foobar
> > {
> > public class HelloWorld
> > {
> > public static void Main()
> > {
> > // If you don't put using System you have
> > // to type System.Console.WriteLine("Hello World!");
> > Console.WriteLine("Hello World!");
> > }
> > }
> > }
> > To compile you have to csc.exe hello.cs /resources:System.dll
> > No package crap, no includes no nothing.
> > It searches the resources for that namespace and converts Console to
> > System.Console. D looks promissing but please use namespaces.
>
> Dude, the same thing works in D but replace "using" with "import" and
> remove the "namespace Foobar" block.
> Also, in D they are called "modules", not "packages".
>
> >
> > Alot of the functions in the windows World are MyFunction instead of
> 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 http://www.windevnet.com/wdn/webextra/2003/0313/ if you think that C# efficiently manipulates strings.)

> > like in the most modern languages.  You can create an Interface to C
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
>
>

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

Member variable decoration is a boon, not a bane. Please explain why you think the contrary.

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

Honk! There are two methods, just tailored syntax.

FWIW, I have problems with the D properties implementation, but at a more fundamental level. I don't think it's reasonable for client code to decide whether a method should act as a property or not. That is something for the class designer to determine.

Also, there are still practical, though eminently solvable, parsing problems with properties. I have no doubt these will be ironed out before 1.0

> What the language needs is indexers (makes classes/structs behave like
> arrays) and builtin support for events.
> Events are basically delegates but with some restrictions. It forces you
> to use +/- to add event handlers.
> foo.MyEvent += new EventHandler(method);
>
> The reason for that is that if you do this (delegate style):
> foo.MyEfnet = new EventHandler(method)
> It deletes whatever event handlers you had before.
>
> I'm not sure, but does D allow supports multicast delegates (delegates that point to more than one function)?

Far out! This is bordering on the peurile.

You can write a class to do whatever you want. Although D is designed to make such obfuscatory (and, IMHO, worthless) syntactical sugar harder to do, there's no doubt that you can do this if you wish.

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

Why? There can only ever be one entry point for a process, so why on earth does it need to go as a class method?

If you were to argue that it could optionally be a class method or a free function, then there's some merit in that. But you didn't. :(

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

What's wrong with non-OO code?

I'm afraid that we're at the uncomfortable, but necessary, point at which I am compelled to ask you how long you've been programming, and what courses you were taught at University.

If the answer to the latter is "lots of things, but they were all Object-Oriented oriented", then I'm afraid you've been done a great disservice by your educators. We might then surmise that the answer to the former is "a few years".

There is no single answer in IT, and there never will be. If you think "OO is the way to go" 100% of the time, then you are (i) wrong, (ii) depriving yourself of learning, (iii) likely to be making the strategists at one or more friendly giant software corporation very happy indeed, since you'll be furthering their cause - as evinced by your postings - that there are but a few limited, and commercially intertwined, ways to go, and anything else is out-of-date and useless. It's a dream, and it's not yours!

(Not that I'm trying to put you off posting, or involvement with D. Far from it. But you're wasting your time here if you think you can proselytise a single mindset on the people and ethos of D. That's one of the reasons most here are interested in it in the first place.)

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

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



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

"SpookyET" <not4_u@hotmail.com> wrote in message news:opr3osiidr1s9n15@saturn...
> Yes i could name methods as MyMethod but that would mean not using the coding style specified by the language creator and get a mix of camelCase and PascalCase since the builtin types are camelCase.

Correct point. I agree.

> The properties in C# are translated into 2 functions get_Property and set_Property on compilation.

Ah, so you do have two functions, then? <g>

> You don't understand the event handling model in .NET, and +/- are good there.  Buf if the language doesn't let you use multicast delegates/events (one pointer to many functions), then there is no need for those.

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

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

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

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)});
> >> Wow, that's ugly! Rather than force this syntax on the user, C#
> >> provides a
> >> nicer syntax. Rather than calling Delegate.Combine(), you can simply
use
> >> += to combine the two delegates:
> >>
> >> MyClass.LogHandler lh = null;
> >>        lh += new MyClass.LogHandler(Logger);
> >>        lh += new MyClass.LogHandler(fl.Logger);
> >
> > But why can't MyClass.LogHandler have an addHandler method?  Also, it's trivial to make a multicast delegate class, and you can overload the += operator if you _really_ want to..  Though, D does have the append operator, overloading ~= might make sense, just overload opAppend.  Then again, if you ask me, interfaces should be used here instead of
delegates
> > anyway.
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

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)});
>> >> Wow, that's ugly! Rather than force this syntax on the user, C#
>> >> provides a
>> >> nicer syntax. Rather than calling Delegate.Combine(), you can simply
> use
>> >> += to combine the two delegates:
>> >>
>> >> MyClass.LogHandler lh = null;
>> >>        lh += new MyClass.LogHandler(Logger);
>> >>        lh += new MyClass.LogHandler(fl.Logger);
>> >
>> > But why can't MyClass.LogHandler have an addHandler method?  Also,  
>> it's
>> > trivial to make a multicast delegate class, and you can overload the  
>> +=
>> > operator if you _really_ want to..  Though, D does have the append
>> > operator, overloading ~= might make sense, just overload opAppend.   
>> Then
>> > again, if you ask me, interfaces should be used here instead of
> delegates
>> > anyway.
>> >
>>
>>
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>



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

One more thing, I don't like where the class library is going.  It is just like the old C.  D is 21st century language, and it should have 21st century library where you can do component based programming.  Basically, the .net framework (ripoff of Delphi's class library).  You have to think about more complicated stuff than basic console apps.
starting with system.Object;
system.io;
system.xml;
system.data;

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

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

class MyAttribute : Attribute
{
  // code
}

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

> Spooky
>
> Here's my challenge to you.
>
> In accordance with mathematical tradition, I ask you to prove your
> conjecture by attempting to disprove it. Specifically, I invite you to
> create a multicast event architecture for D, and to use methods rather than
> operators.
>
> If you cannot do it, that will lend more weight to your argument. If you've
> made a good fist of it, perhaps someone else in the D community might be
> able to take it further. If no-one can do it, then you're right, and we all
> eat crow pie.
>
> If you can do it, then you're wrong, but you'll have learned a great deal
> about D, and you'll have written something that will probably make its way
> into the D standard library. I would think the kudos of having provided such
> an important component to the core library would more than assuage any red
> cheeks you might feel from being proved wrong (by yourself).
>
> Are you up for it?
>
> :)
>
> Matthew
>
>
>
>
> "SpookyET" <not4_u@hotmail.com> wrote in message
> news:opr3ovl9pj1s9n15@saturn...
>> I don't think you understand event based programming, read that article.
>> OK ~ operator?
>> ~ adds, i need something that removes, thus +/- is still better.
>>
>> On Fri, 20 Feb 2004 16:42:52 -0500, Mik Mifflin <mik42@NOadelphiaSPAM.net>
>> wrote:
>>
>> > SpookyET wrote:
>> >
>> >> Take a look at this
>> >>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol
>> > html/csharp04192001.asp
>> >> which explains why there is a need for +/- and why you need event,  
>> even
>> >> though you have delegate.  Even for delegates you need +/-.
>> >>
>> >> Here is a small part of that article:
>> >>
>> >> MyClass.LogHandler lh = (MyClass.LogHandler)
>> >>           Delegate.Combine(new Delegate[]
>> >>              {new MyClass.LogHandler(Logger),
>> >>              new MyClass.LogHandler(fl.Logger)});
>> >> Wow, that's ugly! Rather than force this syntax on the user, C#
>> >> provides a
>> >> nicer syntax. Rather than calling Delegate.Combine(), you can simply
> use
>> >> += to combine the two delegates:
>> >>
>> >> MyClass.LogHandler lh = null;
>> >>        lh += new MyClass.LogHandler(Logger);
>> >>        lh += new MyClass.LogHandler(fl.Logger);
>> >
>> > But why can't MyClass.LogHandler have an addHandler method?  Also,  
>> it's
>> > trivial to make a multicast delegate class, and you can overload the  
>> +=
>> > operator if you _really_ want to..  Though, D does have the append
>> > operator, overloading ~= might make sense, just overload opAppend.   
>> Then
>> > again, if you ask me, interfaces should be used here instead of
> delegates
>> > anyway.
>> >
>>
>>
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>



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

SpookyET wrote:

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

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

You have also seemed to have disproved your own point.  If the overloaded operators simply call methods with meaningful names, why use the operators at all?  They're not needed, and probably shouldn't be there, they only confuse matters.

Also, and I think I said this before, D is not C#.  D is also not .net.  It has no reason to follow such confusing conventions.  It sounds a awful lot like you want to use .net, and nothing else.  In that case, you'd be better off using .net and C#...

-- 
 - Mik Mifflin

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/

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

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