Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
March 02, 2005 Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
I know that D is primarily in a bug fix phase, but it still couldn't hurt to list some open concerns from everyone and see where the bits fall. Feel free to add to the list to keep everything in one place. 1) Can't overload opCmp for both array .sort and <> operators (also opEquals). I still am not sure if overloading the .sort(opCmp) function for arrays is legal (from the lang. spec. POV), but you have to declare the function in a different way than if you want to overload the <> operators. Humph, maybe Walter wants it that way to make it obvious as to what you're doing. But it'd be nice to hear if that's a supported feature of the language or if it's bad practice. If it is supported, can we get one way to define opCmp and opEquals. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/16535 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2642 2) DMD should be able to accept spaces in directory paths. I haven't been able to use spaces in my paths for imports. (I have not tried with the latest release). 3) I can't seem to find the posting, but I thought there was some discussion on having the compiler create a symbol table for imports so you didn't always have to have the source available when importing. (I think I got that right. /Please/ correct me if I didn't). -Kramer |
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kramer | Kramer wrote: > I know that D is primarily in a bug fix phase, but it still couldn't hurt to > list some open concerns from everyone and see where the bits fall. Feel free to > add to the list to keep everything in one place. > > 1) Can't overload opCmp for both array .sort and <> operators (also opEquals). > I still am not sure if overloading the .sort(opCmp) function for arrays is legal > (from the lang. spec. POV), but you have to declare the function in a different > way than if you want to overload the <> operators. Humph, maybe Walter wants it > that way to make it obvious as to what you're doing. But it'd be nice to hear > if that's a supported feature of the language or if it's bad practice. If it is > supported, can we get one way to define opCmp and opEquals. > http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/16535 > http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2642 > I don't understand. You can override opCmp and opEquals. Now, if you want this to work: MyClass [] foo; ... foo.sort; You have to define opCmp like this: class MyClass { ... int opCmp(Object o) { ... } ... } It should take an Object so it works. The problem with .sort is that you can't override it, e.g.: what if you want a different sorting algorithm? > 2) DMD should be able to accept spaces in directory paths. I haven't been able > to use spaces in my paths for imports. (I have not tried with the latest > release). > > 3) I can't seem to find the posting, but I thought there was some discussion on > having the compiler create a symbol table for imports so you didn't always have > to have the source available when importing. (I think I got that right. > /Please/ correct me if I didn't). What you can do is this: // foo.d module foo; int bar() { return 3; } Compile it and (optionally) put it in a library. Then, you can distribute the library and a stripped version of your file(s): // foo.d module foo; int bar(); And then just use it: // baz.d module baz; import foo; void main(){ int f=bar(); } And then do this: dmd baz foo.lib (or dmd baz libfoo.a) And it'll work. > > -Kramer > > _______________________ Carlos Santander Bernal |
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | Carlos Santander B. wrote: > Kramer wrote: <snip> >> 1) Can't overload opCmp for both array .sort and <> operators (also opEquals). <snip> > I don't understand. You can override opCmp and opEquals. Now, if you want this to work: <snip> > class MyClass <snip> The OP and both the referenced posts were talking about structs (and unions), not classes. > The problem with .sort is that you can't override it, e.g.: what if you want a different sorting algorithm? Write a function to implement the algorithm of your choice and call it instead of sort. >> 2) DMD should be able to accept spaces in directory paths. I haven't been able to use spaces in my paths for imports. (I have not tried with the latest >> release). <snip> Do you mean be able to use spaces in the -I switch? I imagine you have to use quotation marks - or is this what you're trying? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | In article <d07aad$2v2q$1@digitaldaemon.com>, Stewart Gordon says... > >Carlos Santander B. wrote: >> Kramer wrote: ><snip> >>> 1) Can't overload opCmp for both array .sort and <> operators (also opEquals). ><snip> >> I don't understand. You can override opCmp and opEquals. Now, if you want this to work: ><snip> >> class MyClass ><snip> > >The OP and both the referenced posts were talking about structs (and unions), not classes. I thought that my one post referenced a class ex., guess I'm wrong. Well, it still holds though. I guess I was just getting at one way of defining the function declaration. One takes an a reference, another takes a pointer. It's not the biggest deal; just hoping for some consistency, or at least an explanation as to why the difference. > >> The problem with .sort is that you can't override it, e.g.: what if you want a different sorting algorithm? > >Write a function to implement the algorithm of your choice and call it instead of sort. I was hoping for something more elegant and that looked more natural to the way the language is defined. It would be cool to write your own sort and then override/register the new sort function with an array. Again, cool, not show stopper. Although, I do think elegance (and this may not be the best ex.) adds to the appeal of a language. > >>> 2) DMD should be able to accept spaces in directory paths. I haven't >>> been able to use spaces in my paths for imports. (I have not tried with the latest >>> release). ><snip> > >Do you mean be able to use spaces in the -I switch? I imagine you have to use quotation marks - or is this what you're trying? Yeah. I couldn't find the other posts, but I've tried it all which ways. Quotation marks, environment variables... around the world and back. I finally just took out the spaces. > >Stewart. > >-- >My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kramer | On Thu, 3 Mar 2005 16:05:20 +0000 (UTC), Kramer <Kramer_member@pathlink.com> wrote:
>>> The problem with .sort is that you can't override it, e.g.: what if you
>>> want a different sorting algorithm?
>>
>> Write a function to implement the algorithm of your choice and call it
>> instead of sort.
>
> I was hoping for something more elegant and that looked more natural to the way
> the language is defined. It would be cool to write your own sort and then
> override/register the new sort function with an array. Again, cool, not show
> stopper. Although, I do think elegance (and this may not be the best ex.) adds
> to the appeal of a language.
A little known "feature" is that if you have:
void quicksort(char[] arr) {
}
you can call it with:
char[] bob;
bob.quicksort;
I'm not 100% positive it's an intended feature, or that it's going to stay (can someone clarify this?). I sicerely hope it stays, it's kewl.
I'm not sure whether this holds true if you use templates, but it would be really nifty if it did as you could then write a templated quicksort for sorting anything with an opCmp (including also basic types). eg.
template quicksort(Type:Type[]) { void quicksort(Type[] arr) {
..etc..
}}
Regan
|
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | In article <opsm2xy0hn23k2f5@ally>, Regan Heath says... > >A little known "feature" is that if you have: > >void quicksort(char[] arr) { >} > >you can call it with: > >char[] bob; >bob.quicksort; One concern I have is that although this is a very useful feature in the language, it *only* applies to array types (unless that changed post v0.97). It'd be nice to get this to work with scalars too. > void foobar(int i){} > int x; > x.foobar(); // etc Its a nice half-step between writing a full-blown struct and doing things the old-fashioned way, plus it makes the language more consistent. - EricAnderton at yahoo |
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | Nice. Thanks for the info!
In article <opsm2xy0hn23k2f5@ally>, Regan Heath says...
>
>On Thu, 3 Mar 2005 16:05:20 +0000 (UTC), Kramer <Kramer_member@pathlink.com> wrote:
>>>> The problem with .sort is that you can't override it, e.g.: what if you want a different sorting algorithm?
>>>
>>> Write a function to implement the algorithm of your choice and call it instead of sort.
>>
>> I was hoping for something more elegant and that looked more natural to
>> the way
>> the language is defined. It would be cool to write your own sort and
>> then
>> override/register the new sort function with an array. Again, cool, not
>> show
>> stopper. Although, I do think elegance (and this may not be the best
>> ex.) adds
>> to the appeal of a language.
>
>A little known "feature" is that if you have:
>
>void quicksort(char[] arr) {
>}
>
>you can call it with:
>
>char[] bob;
>bob.quicksort;
>
>I'm not 100% positive it's an intended feature, or that it's going to stay (can someone clarify this?). I sicerely hope it stays, it's kewl.
>
>I'm not sure whether this holds true if you use templates, but it would be really nifty if it did as you could then write a templated quicksort for sorting anything with an opCmp (including also basic types). eg.
>
>template quicksort(Type:Type[]) { void quicksort(Type[] arr) {
> ..etc..
>}}
>
>Regan
|
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kramer | Kramer wrote:
> In article <d07aad$2v2q$1@digitaldaemon.com>, Stewart Gordon says...
>
>>Carlos Santander B. wrote:
>>>The problem with .sort is that you can't override it, e.g.: what if you want a different sorting algorithm?
>>
>>Write a function to implement the algorithm of your choice and call it instead of sort.
>
>
> I was hoping for something more elegant and that looked more natural to the way
> the language is defined. It would be cool to write your own sort and then
> override/register the new sort function with an array. Again, cool, not show
> stopper. Although, I do think elegance (and this may not be the best ex.) adds
> to the appeal of a language.
>
What I wanted to say, just actually using words :D
_______________________
Carlos Santander Bernal
|
March 03, 2005 Re: Open concerns for D before 1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | On Thu, 3 Mar 2005 21:36:46 +0000 (UTC), pragma <pragma_member@pathlink.com> wrote:
> In article <opsm2xy0hn23k2f5@ally>, Regan Heath says...
>>
>> A little known "feature" is that if you have:
>>
>> void quicksort(char[] arr) {
>> }
>>
>> you can call it with:
>>
>> char[] bob;
>> bob.quicksort;
>
> One concern I have is that although this is a very useful feature in the
> language, it *only* applies to array types (unless that changed post v0.97).
> It'd be nice to get this to work with scalars too.
Everything except class, struct and union, due to possible collision problems, eg.
class A {
void foo() {
}
}
void foo(A a) {
}
A a = new A();
a.foo(); //which do we call?
Although we could detect and make the above an error, it probably shouldn't ever occur, right?
Regan
|
Copyright © 1999-2021 by the D Language Foundation