May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dee Girl | On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> Nice example! How did you do it? Did Tango change the compiler and added more methods to arrays? Thank you, Dee Girl
Yeah, but look what you can do with Phobos.
import std.algorithm;
int[] array = [ 1, 2, 3, 4 ];
// sort in descending order
sort!("a > b")(array);
assert(array == [ 4, 3, 2, 1 ]);
// sort in ascending order
sort(array);
assert(array == [ 1, 2, 3, 4 ]);
// sort with a delegate
bool myComp(int x, int y) { return x > y; }
sort!(myComp)(array);
assert(array == [ 4, 3, 2, 1 ]);
// Showcase stable sorting
string[] words = [ "aBc", "a", "abc", "b", "ABC", "c" ];
sort!("toupper(a) < toupper(b)", SwapStrategy.stable)(words);
assert(words == [ "a", "aBc", "abc", "ABC", "b", "c" ]);
|
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dee Girl | Disclaimer: this post reflects my personal opinion only and should not start yet another flame war about tango vs phobos. feel free to disagree with everything I say. based on what I know: phobos uses the C IO. this is both bad for performance (yet another layer) and the interface is ugly. Tango's IO much more powerful, more efficient, and more flexible. the cost of it is that it's more complex (compared to the C-like functions phobos provides). phobos is ill organized mixing the run-time library (which you as a user should never touch) with the user code. Why is the GC internals in the same library as the string manipulation functions?? also the namespace in tango is much better organized into packages and modules (although, sometimes it's too much, like the collections being nested in utils). I prefer Tango's tango.io.Stdout vs std.stdio. I think Stdout is lame but at least it's inside an IO package. what's the deal with using 8-letter acronyms that are hard to remember anyway? we are not limited by DOS' 8 chars length for file names anymore. Tango has much more functionality, is optimized for performance, has less bugs and more maintainers than phobos. Walter is a genius compiler writer but he can't spend all his time on phobos, And I really dislike the C++ smell from all of the code Andrei added to phobos. He's a C++ Wizard, But that C++ mindset that templates solve everything is bad IMO. sometimes, the language does need to provide proper syntax. D needs a good tuple support and not a template Tuple!(...) for example. another example would be all the templates in std.algorithm. I'd prefer a reduce function that takes a delegate rather than a reduce template. Regarding C++ and STL: it is useful for C++, however it is designed in a way to take into account all the deficiencies of C++ (which D doesn't have). an error in your c++ code that uses STL will produce a screen full of text which is unrelated to the problem, making it useless. STL does not use polymorphism in any way so that if i used an iterator and decided to reverse the iteration I need to make sure I change the Iterator type, which is lame (had this bug, once). this complete lack of polymorphism is plain wrong. simple example: I use a vector to go over series of values and then decide to use a linked-list instead. I need to go and change my code everywhere, since there are no common interfaces like Java's List or collection for that matter. in java i can have: List<C> list = new ArrayList<C> (); changed to: List<C> list = new LinkedList<C> (); and that's it! no need to search and replace all my functions (since they use the general List<C> anyway. Isn't that so much more productive? C++ needs to add language extensions (i.e. concepts) to make that work. My point is that I do not want that design of the STL. also, C++ uses iterators extensively, and this design can be replaced by more advanced concepts like generators and HOF. I prefer smalltalk and ruby way of collection.each { code } vs. C++ more primitive: for (collection::iterator i = collection.begin(); i != collection.end() ; ++i) { code } which one of those is better? smalltalk has map:, select: inject:into: etc, built into the collections classes, which is SO much better than using C++ iterators. STL does provide similar constructs but they are so verbose that no one ever uses them. D needs to become a compiled efficient ruby-like language more than a slightly more readable C++. Those are my rumblings, If somebody got offended, than I'm truly sorry for that. I just wish for a better D future. --Yigal |
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | Janice Caron wrote:
> On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
>> Nice example! How did you do it? Did Tango change the compiler and added more methods to arrays? Thank you, Dee Girl
>
> Yeah, but look what you can do with Phobos.
>
> import std.algorithm;
>
> int[] array = [ 1, 2, 3, 4 ];
>
> // sort in descending order
> sort!("a > b")(array);
> assert(array == [ 4, 3, 2, 1 ]);
>
> // sort in ascending order
> sort(array);
> assert(array == [ 1, 2, 3, 4 ]);
>
> // sort with a delegate
> bool myComp(int x, int y) { return x > y; }
> sort!(myComp)(array);
> assert(array == [ 4, 3, 2, 1 ]);
>
> // Showcase stable sorting
> string[] words = [ "aBc", "a", "abc", "b", "ABC", "c" ];
> sort!("toupper(a) < toupper(b)", SwapStrategy.stable)(words);
> assert(words == [ "a", "aBc", "abc", "ABC", "b", "c" ]);
here comes my personal emotional response: I hate the above code! it
smells to much like C++.
I really dislike the use of templates here, which is unnecessary, and
even more so the use of those strings. a Much better way would be to use:
sort(array, (int a, int b){ return x > y; });
I wish D would add the syntax sugar proposed by downs so that could be
written as:
sort(array, (int a, int b)) { return x > y; }
also, you can rewrite it as:
array.sort(...);
which is even better IMO.
-- Yigal
|
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to terranium | Reply to terranium,
> BCS Wrote:
>
>> The major issue I have with this is that the construct that actually
>> does the downcast MUST also do the type check. Therefor it gets done
>> twice and this is a bit of a performance issue.
>>
> current implementation of cast already does the typecheck, so there
> will be no performance issue.
>
but the proposal would requier *two* checks in the "use this as a B if it's a B" case. One for the code to "if" on and one in the actual conversion (to be safe).
|
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | Janice Caron Wrote:
> If you want to talk Unicode
I'll let others to have the pleasure to discover this themselves :)))
|
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | Yigal Chripun wrote: > D needs to become a compiled efficient ruby-like language more than a slightly more readable C++. D'accord. -- |
May 10, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | Yigal Chripun Wrote:
> Janice Caron wrote:
> > On 10/05/2008, Dee Girl <deegirl@noreply.com> wrote:
> >> Nice example! How did you do it? Did Tango change the compiler and added more methods to arrays? Thank you, Dee Girl
> >
> > Yeah, but look what you can do with Phobos.
> >
> > import std.algorithm;
> >
> > int[] array = [ 1, 2, 3, 4 ];
> >
> > // sort in descending order
> > sort!("a > b")(array);
> > assert(array == [ 4, 3, 2, 1 ]);
> >
> > // sort in ascending order
> > sort(array);
> > assert(array == [ 1, 2, 3, 4 ]);
> >
> > // sort with a delegate
> > bool myComp(int x, int y) { return x > y; }
> > sort!(myComp)(array);
> > assert(array == [ 4, 3, 2, 1 ]);
> >
> > // Showcase stable sorting
> > string[] words = [ "aBc", "a", "abc", "b", "ABC", "c" ];
> > sort!("toupper(a) < toupper(b)", SwapStrategy.stable)(words);
> > assert(words == [ "a", "aBc", "abc", "ABC", "b", "c" ]);
>
> here comes my personal emotional response: I hate the above code! it
> smells to much like C++.
> I really dislike the use of templates here, which is unnecessary, and
> even more so the use of those strings. a Much better way would be to use:
> sort(array, (int a, int b){ return x > y; });
> I wish D would add the syntax sugar proposed by downs so that could be
> written as:
> sort(array, (int a, int b)) { return x > y; }
> also, you can rewrite it as:
> array.sort(...);
> which is even better IMO.
I agree! Strings and aliases are much less powerful than delegates and closures because they are static and can not have state.
But I am confused about something. I compiled this with phobos:
sort!(function bool(int a, int b) { return a > b; })(array);
There is clear difference in syntax from your examples. But my question is: what are the differences in semantics? Thank you, Dee Girl
|
May 11, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dee Girl | Dee Girl wrote:
> I agree! Strings and aliases are much less powerful than delegates
> and closures because they are static and can not have state.
> But I am confused about something. I compiled this with phobos:
>
> sort!(function bool(int a, int b) { return a > b; })(array);
>
> There is clear difference in syntax from your examples. But my question is: what are the differences in semantics? Thank you, Dee Girl
I'm not sure what exactly are you asking. are you asking what's the
difference between a delegate and a function?
--Yigal
|
May 11, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | Yigal Chripun Wrote:
> Dee Girl wrote:
> > I agree! Strings and aliases are much less powerful than delegates
> > and closures because they are static and can not have state.
> > But I am confused about something. I compiled this with phobos:
> >
> > sort!(function bool(int a, int b) { return a > b; })(array);
> >
> > There is clear difference in syntax from your examples. But my question is: what are the differences in semantics? Thank you, Dee Girl
>
> I'm not sure what exactly are you asking. are you asking what's the difference between a delegate and a function?
Please let me rephrase. What is the difference between a function passed as an alias, and a delegate? You hate one and you like the other so the difference must be big. But I do not find it. Thank you, Dee Girl
|
May 11, 2008 Re: Safer casts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dee Girl | Reply to Dee,
> Yigal Chripun Wrote:
>
>> Dee Girl wrote:
>>
>>> I agree! Strings and aliases are much less powerful than delegates
>>> and closures because they are static and can not have state.
>>> But I am confused about something. I compiled this with phobos:
>>> sort!(function bool(int a, int b) { return a > b; })(array);
>>>
>>> There is clear difference in syntax from your examples. But my
>>> question is: what are the differences in semantics? Thank you, Dee
>>> Girl
>>>
>> I'm not sure what exactly are you asking. are you asking what's the
>> difference between a delegate and a function?
>>
> Please let me rephrase. What is the difference between a function
> passed as an alias, and a delegate? You hate one and you like the
> other so the difference must be big. But I do not find it. Thank you,
> Dee Girl
>
a function is just a free function or a static class function or the like. A delegate is both a function and a context. Generally the context is another function's scope or an object or struct.
|
Copyright © 1999-2021 by the D Language Foundation