On Wed, 2 Mar 2005 22:43:35 -0800, Walter <newshound@digitalmars.com> wrote:
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message
> news:d0651s$1mgp$1@digitaldaemon.com...
>> >
>> > will change enough to cause any D source today to undergo major
> rewrites?
>> > I can answer the latter concern - it isn't going to happen.
>> >
>>
>> Walter, for the Mars sake and other mebers of Panteon, could you shed
>> a light on future of "external-methods"?
>>
>> I mean this was supported last time I checked it
>> char[][] split(char[] s, char c) { ... }
>> char[] s = "a b c";
>> char[][] sv = s.split(' ');
>>
>> May I rely on this trick?
>
> I don't see any reason to take it out.

Ahh.. but is it in the spec? Will you add it to the spec? So other D compilers will also support it?

Regan

Ben Hinkle wrote:

>>Too bad that none of them really works OK on Mac OS X,
> 
> I just need to get off my butt and work that out. I think you sent me some ideas on what I need to change to get it working on the mac. Just the other day I started compiling gdc on a mac at work but I haven't gotten to the point of trying out my stuff. Thanks for reminding me to get that done. Without reminders it's too easy to let it slide.

Actually none of MinTL, MinWin, Mango nor DUI works right now. :-(

But with more eyes looking at it, there's better chances of
fixing it. And it does get a fair share of compiler segfaults
and "thunk not defined" and other compiler errors, so there's
probably a few bug reports on DMD waiting to be sent in too...

I just updated the Mac GDC installer, so now it's a lot smaller
than what it used to be and C and C++ are separate RPM packages.
But I really don't have a good place to host it, at the moment ?
(the packages are around 20 MB, and the source code around 20 MB)*

Meta-package: http://www.algonet.se/~afb/d/gdc-installer.png

--anders

* Breakdown of binary package:
> 2.9M    gdc-0.10-6.ppc.rpm
> 4.5M    gdc-c-0.10-6.ppc.rpm
>  12M    gdc-c++-0.10-6.ppc.rpm

* Breakdown of source code:
>  20K    gdc-0.10-6.nosrc.rpm
> 736K    gdc-0.10.tar.bz2
>  12M    gcc-core-3.4.3.tar.bz2
> 2.4M    gcc-g++-3.4.3.tar.bz2
> 4.5M    gcc-java-3.4.3.tar.bz2

Source RPM: http://www.algonet.se/~afb/d/gdc-0.10-6.nosrc.rpm

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm2yxbvj23k2f5@ally...
> Ahh.. but is it in the spec? Will you add it to the spec? So other D compilers will also support it?

I put it in so that arrays and basic types could be extended by the programmer to have generic 'property' like features. It should go in the spec, you're right.

Walter wrote:
> "Mike Parker" <aldacron71@yahoo.com> wrote in message
> news:d07dbj$24e$1@digitaldaemon.com...
> 
>>For the C++ types, I think an STL equivalent is the big thing. To this
>>end, I really believe either DTL or MinTL needs to be integrated into
>>core Phobos as part of a 1.0 release. This will make people in both
>>camps happy (Java developers love their Collections).
> 
> 
> I understand that, but a DTL is probably going to be a D 2.0 feature. But
> part of the problem is a perception issue. D handles already, in the core
> language, much of the functionality of STL. (For an example, see
> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder
> where the 'string class' is. It takes a bit more in depth look at D to
> realize that a string class for D would be redundant, as would be vector
> classes, slice classes, for_each kludges, hash collections, etc. One other
> large reason for the existence of STL is memory management. D does automatic
> memory management.
> 
> DTL needs go at least one or two conceptual steps beyond STL, because D
> already handles much of the core point of STL.
> 
> 
On the other hand, you still want to provide a standard string class.

1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on.
2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions.
3. It provides a consistent way to access functions that work on strings.

There are probably more things that a string class could provide.
Some of the functions can be just global functions, but I think
a lot of people are used access them as methods.

Here an example:

D right now:

char[] s;
s.length <- property
toUTF32(s) <- global function

D with a standardized string class

string s;

s.length()  <- method
s.toUTF32() <- method

This is much more consistent.

Since strings are so fundamental, there should be a single standardized
string interface. It needs to be powerful enough so that there is no reason for anyone to develop a second string class for purpose x.


Jan-Eric

In article <d056ph$lnj$1@digitaldaemon.com>, Matthew says...
>
>
>"Walter" <newshound@digitalmars.com> wrote in message
>>
>> I've found myself wondering over the last few months what "1.0"
>> actually is.
>> Since D will undergo continuous improvement regardless, why don't we
>> just
>> drive a stake in the ground and call what we have "1.0"?
>
>Is it a commercially viable language yet? IMO it is not.
>
>I think 1.0 should be whenever it is.
>
>The crux of that is how do we determine when it becomes so.
>
>Any ideas on criteria?
>
>Another one might be when it can stand up to criticism from people who have an inclination to dislike it, rather than from those (like me) who are inclined to like it. I mean, if the people who are biased towards it think it's not ready, surely it's not ready?

For a 1.0 release I think correctness of the design (which to a significant extent can never be changed after "1.0") is more important than solidity of implementation (which can be continually improved forever).

The point just before 1.0 is a magic moment where you know far more than you did when you first made your design decisions and yet you are still completely free to change anything.

For this reason, I think that before 1.0 is declared, every effort should be made by Walter to gather feedback on his design decisions from as broad an audience as possible and to reconsider those decisions while there is still an opportunity to change.

The points that cause the most controversy and criticism should be identified, the arguments for each alternative laid out, with no bias toward the existing design, and the pros and cons of each identified as clearly as possible.

Then Walter should put his past decisions and arguments out of his mind and reconsider each of these controversial points de novo, asking himself what choices he would make if he were making them now for the first time, trying to avoid the urge to defend previous positions or protect existing code. (This is his last chance to make changes without legacy constraints, and I think he should exploit it fully.)

Even done with a completely open mind, my guess is that only a very small number of issues would end up as serious candidates for change, but that a few sensible changes would significantly close the gap between D's existing design and perfection in the eyes of its future market.

Walter wrote:
> 
> I put it in so that arrays and basic types could be extended by the
> programmer to have generic 'property' like features. It should go in the
> spec, you're right.
> 
> 

I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Also, right now, it only works with arrays, not basic types, classes, structs, unions or enums.

_______________________
Carlos Santander Bernal

Ant wrote:
> In article <d07f6a$3pt$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
> 
>>Forgive my ignorance, but wasn't both of STL and Collections
>>added long after the initial releases of those two languages ?
>>
> 
> 
> It doesn't matter. What counts it's what D is up against now,
> not some years ago.
> 
> Ant
> 
> 

I agree.

_______________________
Carlos Santander Bernal

On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
> Walter wrote:
>> "Mike Parker" <aldacron71@yahoo.com> wrote in message
>> news:d07dbj$24e$1@digitaldaemon.com...
>>
>>> For the C++ types, I think an STL equivalent is the big thing. To this
>>> end, I really believe either DTL or MinTL needs to be integrated into
>>> core Phobos as part of a 1.0 release. This will make people in both
>>> camps happy (Java developers love their Collections).
>>   I understand that, but a DTL is probably going to be a D 2.0 feature. But
>> part of the problem is a perception issue. D handles already, in the core
>> language, much of the functionality of STL. (For an example, see
>> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and wonder
>> where the 'string class' is. It takes a bit more in depth look at D to
>> realize that a string class for D would be redundant, as would be vector
>> classes, slice classes, for_each kludges, hash collections, etc. One other
>> large reason for the existence of STL is memory management. D does automatic
>> memory management.
>>  DTL needs go at least one or two conceptual steps beyond STL, because D
>> already handles much of the core point of STL.
>>
> On the other hand, you still want to provide a standard string class.
>
> 1. A string class comes handy with the methods like toUpper,toLower,replaceChar,findNextToken and so on.
> 2. A string class can abstract from the actual encoding UTF-8, UTF-16,UTF-32 and can provide automatic conversions.
> 3. It provides a consistent way to access functions that work on strings.
>
> There are probably more things that a string class could provide.
> Some of the functions can be just global functions, but I think
> a lot of people are used access them as methods.
>
> Here an example:
>
> D right now:
>
> char[] s;
> s.length <- property
> toUTF32(s) <- global function
>
> D with a standardized string class
>
> string s;
>
> s.length()  <- method
> s.toUTF32() <- method
>
> This is much more consistent.

You can already use the syntax above. D allows you to call a function which takes an array as it's first parameter as if it was a method/property of the array.

eg.

char[] s,p;
p = s.toTUF32();

> Since strings are so fundamental, there should be a single standardized
> string interface. It needs to be powerful enough so that there is no reason for anyone to develop a second string class for purpose x.

I reckon what we have in D is better than a class, it's extensible, you can pretty much write your own 'methods' for the char[] type.

Regan

I very much dislike choice of having JAVA-like functionNames... That might
even come to turning back to D. :( I thought pretty much about resons
behind using that naming convention and there was none good reason i could
come to. Seriously.
Someone pointed out that people use it to distinct from class-names. Well,
if i have dot (".") before it, it cannot be the class! :)
Anyway it's up to D developers and they made their decision - this is just a
personal note.
I prefer MethodNames() or method_names() . methodNames() are unacceptable
for my projects. :)
IMHO it would be good if D doesn't make difference between those somehow. :)

Kind regards

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
> Walter wrote:
>>  I put it in so that arrays and basic types could be extended by the
>> programmer to have generic 'property' like features. It should go in the
>> spec, you're right.
>>
>
> I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?

Assuming:

path.module1.foo(char[] a, int i);
path.module2.foo(char[] a, int i);

char[] a;
a.path.module1.foo(1);
a.path.module2.foo(2);

perhaps?

or maybe it's better to force the user to revert to:

path.module1.foo(a,1);
path.module2.foo(a,2);

> Also, right now, it only works with arrays, not basic types, classes, structs, unions or enums.

It would be kewl if it worked with all types, if so, how should it handle:

class A {
  void foo() {
  }
}

void foo(A a) {
}

A a = new A();
a.foo(); //which do we call?

The same applies to struct, union, and when the function clashes with a property of a basic type or array.

Regan