View mode: basic / threaded / horizontal-split · Log in · Help
May 10, 2008
Re: Safer casts
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
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
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
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
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
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
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
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
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
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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home